Multicast DNS
Extracted elements (31)
mDNS uses a fixed multicast address (224.0.0.251) rather than a range of hashed addresses because all devices on the link must receive all mDNS traffic to enable passive cache sharing, conflict detection, duplicate suppression, and Known-Answer Suppression across hosts (see Appendix B).
Negative responses in mDNS repurpose NSEC records (from DNSSEC) rather than using NXDOMAIN, because NXDOMAIN in Unicast DNS asserts the entire name does not exist, whereas in mDNS a host can only authoritatively assert the nonexistence of records it exclusively owns, not all records for a name (Appendix E).
The '.local.' top-level domain is designated as link-local, analogous to IPv4 169.254/16 and IPv6 FE80::/10 addresses. This allows any user to self-assign link-local host names without DNS infrastructure, registration fees, or delegation.
UDP port 5353 was chosen as a dedicated well-known port rather than reusing port 53 because mDNS responders need to receive unsolicited multicast messages without interfering with normal DNS operation, and to allow both compliant mDNS and legacy one-shot resolvers to coexist on the same host (Appendix A).
Legacy DNS resolvers that send queries from a source port other than 5353 are handled by sending a conventional unicast response with TTL capped at 10 seconds and the cache-flush bit unset, preventing stale data retention by resolvers that do not implement mDNS cache coherency mechanisms.
A compliant Multicast DNS querier MUST send its queries from UDP source port 5353 and MUST listen for replies sent to UDP destination port 5353 at the mDNS link-local multicast address (224.0.0.251 and/or FF02::FB).
A Multicast DNS querier sending its initial batch of questions immediately on wake from sleep or interface activation SHOULD set the unicast-response bit (QU) in those questions. On retransmission, the unicast-response bit SHOULD NOT be set.
A Multicast DNS responder MUST NOT answer a query if the answer it would give is already in the query's Answer Section with an RR TTL at least half the correct value (Known-Answer Suppression). If the TTL is less than half, the responder MUST send an answer to refresh the querier's cache.
A Multicast DNS responder MUST NOT (except when answering probe queries) multicast a record on a given interface until at least one second has elapsed since the last time that record was multicast on that interface, to protect against excessive packet flooding.
A Multicast DNS responder MUST NOT place records from its cache (learned from other responders) in the Resource Record Sections of outgoing response messages. Only an authoritative source for a given record is allowed to issue responses containing that record.
A responder that has verified exclusive ownership of a name MUST respond to queries for record types that do not exist for that name by sending a negative answer (NSEC record) asserting the nonexistence of that record. For shared records, NXDOMAIN and other error responses MUST NOT be sent.
After successful probing, a Multicast DNS responder MUST send at least two unsolicited Multicast DNS response announcements one second apart. Unique records are placed in the Answer Section with the cache-flush bit (MSB of rrclass) set to one.
Any DNS query for a name ending with '.local.' MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 or its IPv6 equivalent FF02::FB. Implementers MAY also look up such names concurrently via Unicast DNS.
Before claiming ownership of a unique resource record set, a Multicast DNS responder MUST send three probe queries (qtype ANY) 250 ms apart, preceded by an initial random delay of 0-250 ms. If fifteen conflicts occur within any ten-second period, the host MUST wait at least five seconds before each successive probe attempt.
DNS queries for names ending with '254.169.in-addr.arpa.' and the IPv6 link-local reverse mapping domains (8.e.f.ip6.arpa., 9.e.f.ip6.arpa., a.e.f.ip6.arpa., b.e.f.ip6.arpa.) MUST be sent to the mDNS multicast address.
If the source UDP port in a received query is not 5353 (indicating a legacy resolver), the responder MUST send a conventional unicast DNS response directly to the querier. This legacy unicast response MUST repeat the query ID and question, MUST NOT set the cache-flush bit, and SHOULD NOT give a TTL greater than ten seconds.
One-shot Multicast DNS queries MUST NOT be sent using UDP source port 5353, since using source port 5353 signals the presence of a fully compliant mDNS querier.
The source UDP port in all Multicast DNS responses MUST be 5353. The destination port MUST be 5353 and the destination address MUST be 224.0.0.251 or FF02::FB, except when replying to QU questions, legacy queries, or direct unicast queries.
When Known-Answer records overflow a single query packet, the querier MUST set the TC (Truncated) bit and MUST immediately follow with additional packets containing more Known-Answer records. A responder seeing TC set MUST defer its response for 400-500 ms to collect all Known-Answer packets.
When responding to wildcard queries with qtype 'ANY' (255) or qclass 'ANY' (255), a Multicast DNS responder MUST respond with ALL of its records that match the query, unlike Unicast DNS which may return any subset.
When retransmitting queries for continuous monitoring, the interval between the first two queries MUST be at least one second, intervals between successive queries MUST increase by at least a factor of two, and the querier MUST implement Known-Answer Suppression. The interval MAY be capped at 60 minutes.
Whenever a Multicast DNS responder receives a Multicast DNS response containing a conflicting resource record (same name/rrtype/rrclass but inconsistent rdata) for any of its unique records, it MUST immediately reset that record to probing state and repeat the full startup sequence.
mDNS responses are sent to the link-local multicast address, making all mDNS traffic visible to every device on the local network. Device names, service types, and other advertised metadata can reveal information about the device and its owner to any local observer.
Goodbye packets are Multicast DNS responses with the RR TTL set to zero, signaling that a record is no longer valid and should be removed from peer caches. Queriers receiving a TTL-0 record SHOULD delete it from cache within one second.
Negative responses in mDNS are encoded using DNS NSEC records. The restricted mDNS NSEC format requires the 'Next Domain Name' field to equal the record's own name, a Type Bit Map block number of 0, and a block length of 1-32 bytes. The NSEC bit MUST NOT be set in synthesized mDNS NSEC records.
Simultaneous probe tiebreaking places proposed resource records in the Authority Section of probe queries. When two hosts probe for the same name concurrently, the host with lexicographically later rdata wins, where comparison is by class, then rrtype, then raw binary rdata bytes treated as unsigned values.
The cache-flush bit is the most significant bit of the rrclass field in resource records within the Answer Section of a response. When set, it instructs neighboring caches to flush all records with the same name, rrtype, and rrclass that were received more than one second ago.
The top bit of the class field in a DNS question is defined as the 'unicast-response bit'. When set, the question is a 'QU' question indicating the querier will accept unicast replies; without this bit set it is a 'QM' question requesting multicast responses.
IANA has assigned UDP port 5353 for Multicast DNS, IPv4 multicast group address 224.0.0.251, and IPv6 multicast address FF02::FB. The '.local.' domain and the reverse-mapping domains for link-local addresses are registered as special-use domains.
Multicast DNS is substantially less secure than Unicast DNS because it relies on all responders on the local link being trustworthy. An attacker on the local network can poison mDNS caches by sending fraudulent responses. When resolving global names via local multicast, DNSSEC or other security mechanisms MUST be used.
Multicast DNS uses UDP port 5353 for both queries and responses. The IPv4 link-local multicast group address is 224.0.0.251 and the IPv6 equivalent is FF02::FB. Messages use the standard DNS message format with no new opcodes or response codes.