unintentionally) set so that local names don't work is just one more way of frustrating the user's ability to perform the tasks they want, perpetuating the view that, "IP networking is too complicated to configure and too hard to use". IEEE.802.11] wireless connection active at the same time. What the software on the laptop computer can't easily tell is whether the wireless connection is in fact bridged onto the same network segment as its Ethernet connection. If the two networks are bridged together, then packets the host sends on one interface will arrive on the other interface a few milliseconds later, and care must be taken to ensure that this bridging does not cause problems:
When the host announces its host name (i.e., its address records) on its wireless interface, those announcement records are sent with the cache-flush bit set, so when they arrive on the Ethernet segment, they will cause all the peers on the Ethernet to flush the host's Ethernet address records from their caches. The Multicast DNS protocol has a safeguard to protect against this situation: when records are received with the cache-flush bit set, other records are not deleted from peer caches immediately, but are marked for deletion in one second. When the host sees its own wireless address records arrive on its Ethernet interface, with the cache-flush bit set, this one-second grace period gives the host time to respond and re- announce its Ethernet address records, to reinstate those records in peer caches before they are deleted. As described, this solves one problem, but creates another, because when those Ethernet announcement records arrive back on the wireless interface, the host would again respond defensively to reinstate its wireless records, and this process would continue forever, continuously flooding the network with traffic. The Multicast DNS protocol has a second safeguard, to solve this problem: the cache- flush bit does not apply to records received very recently, within the last second. This means that when the host sees its own Ethernet address records arrive on its wireless interface, with the cache- flush bit set, it knows there's no need to re-announce its wireless address records again because it already sent them less than a second ago, and this makes them immune from deletion from peer caches. (See Section 10.2.)
partially mitigated if Multicast DNS implementations detect when they are not the first to bind to port 5353, and in that case they do not request "QU" responses. One way to detect if there is another Multicast DNS implementation already running is to attempt binding to port 5353 without using SO_REUSEPORT and/or SO_REUSEADDR, and if that fails it indicates that some other socket is already bound to this port.
RFC2181] directly discusses the subject of allowable character set in Section 11 ("Name syntax"), and explicitly states that DNS names may contain arbitrary eight-bit data. However, the old rules for ARPANET host names back in the 1980s required host names to be just letters, digits, and hyphens [RFC1034], and since the predominant use of DNS is to store host address records, many have assumed that the DNS protocol itself suffers from the same limitation. It might be accurate to say that there could be hypothetical bad implementations that do not handle eight-bit data correctly, but it would not be accurate to say that the protocol doesn't allow names containing eight-bit data. Multicast DNS is a new protocol and doesn't (yet) have old buggy legacy implementations to constrain the design choices. Accordingly, it adopts the simple obvious elegant solution: all names in Multicast DNS MUST be encoded as precomposed UTF-8 [RFC3629] "Net-Unicode" [RFC5198] text. Some users of 16-bit Unicode have taken to stuffing a "zero-width nonbreaking space" character (U+FEFF) at the start of each UTF-16 file, as a hint to identify whether the data is big-endian or little- endian, and calling it a "Byte Order Mark" (BOM). Since there is only one possible byte order for UTF-8 data, a BOM is neither necessary nor permitted. Multicast DNS names MUST NOT contain a "Byte Order Mark". Any occurrence of the Unicode character U+FEFF at the start or anywhere else in a Multicast DNS name MUST be interpreted as being an actual intended part of the name, representing (just as for any other legal unicode value) an actual literal instance of that character (in this case a zero-width non- breaking space character). For names that are restricted to US-ASCII [RFC0020] letters, digits, and hyphens, the UTF-8 encoding is identical to the US-ASCII encoding, so this is entirely compatible with existing host names. For characters outside the US-ASCII range, UTF-8 encoding is used.
Multicast DNS implementations MUST NOT use any other encodings apart from precomposed UTF-8 (US-ASCII being considered a compatible subset of UTF-8). The reasons for selecting UTF-8 instead of Punycode [RFC3492] are discussed further in Appendix F. The simple rules for case-insensitivity in Unicast DNS [RFC1034] [RFC1035] also apply in Multicast DNS; that is to say, in name comparisons, the lowercase letters "a" to "z" (0x61 to 0x7A) match their uppercase equivalents "A" to "Z" (0x41 to 0x5A). Hence, if a querier issues a query for an address record with the name "myprinter.local.", then a responder having an address record with the name "MyPrinter.local." should issue a response. No other automatic equivalences should be assumed. In particular, all UTF-8 multibyte characters (codes 0x80 and higher) are compared by simple binary comparison of the raw byte values. Accented characters are *not* defined to be automatically equivalent to their unaccented counterparts. Where automatic equivalences are desired, this may be achieved through the use of programmatically generated CNAME records. For example, if a responder has an address record for an accented name Y, and a querier issues a query for a name X, where X is the same as Y with all the accents removed, then the responder may issue a response containing two resource records: a CNAME record "X CNAME Y", asserting that the requested name X (unaccented) is an alias for the true (accented) name Y, followed by the address record for Y. RFC1035] restricts DNS messages carried by UDP to no more than 512 bytes (not counting the IP or UDP headers). For UDP packets carried over the wide-area Internet in 1987, this was appropriate. For link-local multicast packets on today's networks, there is no reason to retain this restriction. Given that the packets are by definition link-local, there are no Path MTU issues to consider. Multicast DNS messages carried by UDP may be up to the IP MTU of the physical interface, less the space required for the IP header (20 bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes). In the case of a single Multicast DNS resource record that is too large to fit in a single MTU-sized multicast response packet, a Multicast DNS responder SHOULD send the resource record alone, in a single IP datagram, using multiple IP fragments. Resource records this large SHOULD be avoided, except in the very rare cases where they really are the appropriate solution to the problem at hand. Implementers should be aware that many simple devices do not reassemble fragmented IP datagrams, so large resource records SHOULD NOT be used except in specialized cases where the implementer knows
that all receivers implement reassembly, or where the large resource record contains optional data which is not essential for correct operation of the client. A Multicast DNS packet larger than the interface MTU, which is sent using fragments, MUST NOT contain more than one resource record. Even when fragmentation is used, a Multicast DNS packet, including IP and UDP headers, MUST NOT exceed 9000 bytes. Note that 9000 bytes is also the maximum payload size of an Ethernet "Jumbo" packet [Jumbo]. However, in practice Ethernet "Jumbo" packets are not widely used, so it is advantageous to keep packets under 1500 bytes whenever possible. Even on hosts that normally handle Ethernet "Jumbo" packets and IP fragment reassembly, it is becoming more common for these hosts to implement power-saving modes where the main CPU goes to sleep and hands off packet reception tasks to a more limited processor in the network interface hardware, which may not support Ethernet "Jumbo" packets or IP fragment reassembly.
In multicast responses, including unsolicited multicast responses, the Query Identifier MUST be set to zero on transmission, and MUST be ignored on reception. In legacy unicast response messages generated specifically in response to a particular (unicast or multicast) query, the Query Identifier MUST match the ID from the query message.
RFC2535] MUST be zero on transmission, and MUST be ignored on reception. RFC2535] MUST be zero on transmission, and MUST be ignored on reception. Section 5.4.) Section 10.2.)
RFC1035]. This applies not only to Multicast DNS responses, but also to queries. When a query contains more than one question, successive questions in the same message often contain similar names, and consequently name compression SHOULD be used, to save bytes. In addition, queries may also contain Known Answers in the Answer Section, or probe tiebreaking data in the Authority Section, and these names SHOULD similarly be compressed for network efficiency. In addition to compressing the *names* of resource records, names that appear within the *rdata* of the following rrtypes SHOULD also be compressed in all Multicast DNS messages: NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC Until future IETF Standards Action [RFC5226] specifying that names in the rdata of other types should be compressed, names that appear within the rdata of any type not listed above MUST NOT be compressed. Implementations receiving Multicast DNS messages MUST correctly decode compressed names appearing in the Question Section, and compressed names of resource records appearing in other sections. In addition, implementations MUST correctly decode compressed names appearing within the *rdata* of the rrtypes listed above. Where possible, implementations SHOULD also correctly decode compressed names appearing within the *rdata* of other rrtypes known to the implementers at the time of implementation, because such forward- thinking planning helps facilitate the deployment of future implementations that may have reason to compress those rrtypes. It is possible that no future IETF Standards Action [RFC5226] will be created that mandates or permits the compression of rdata in new types, but having implementations designed such that they are capable of decompressing all known types helps keep future options open. One specific difference between Unicast DNS and Multicast DNS is that Unicast DNS does not allow name compression for the target host in an SRV record, because Unicast DNS implementations before the first SRV specification in 1996 [RFC2052] may not decode these compressed
records properly. Since all Multicast DNS implementations were created after 1996, all Multicast DNS implementations are REQUIRED to decode compressed SRV records correctly. In legacy unicast responses generated to answer legacy queries, name compression MUST NOT be performed on SRV records.
RFC4033] signatures so that they can distinguish Multicast DNS messages from trusted participants (which they process as usual) from Multicast DNS messages from untrusted participants (which they silently discard).
If DNS queries for *global* DNS names are sent to the mDNS multicast address (during network outages which disrupt communication with the greater Internet) it is *especially* important to use DNSSEC, because the user may have the impression that he or she is communicating with some authentic host, when in fact he or she is really communicating with some local host that is merely masquerading as that name. This is less critical for names ending with ".local.", because the user should be aware that those names have only local significance and no global authority is implied. Most computer users neglect to type the trailing dot at the end of a fully qualified domain name, making it a relative domain name (e.g., "www.example.com"). In the event of network outage, attempts to positively resolve the name as entered will fail, resulting in application of the search list, including ".local.", if present. A malicious host could masquerade as "www.example.com." by answering the resulting Multicast DNS query for "www.example.com.local.". To avoid this, a host MUST NOT append the search suffix ".local.", if present, to any relative (partially qualified) host name containing two or more labels. Appending ".local." to single-label relative host names is acceptable, since the user should have no expectation that a single-label host name will resolve as is. However, users who have both "example.com" and "local" in their search lists should be aware that if they type "www" into their web browser, it may not be immediately clear to them whether the page that appears is "www.example.com" or "www.local". Multicast DNS uses UDP port 5353. On operating systems where only privileged processes are allowed to use ports below 1024, no such privilege is required to use port 5353. SN]. IANA has allocated the IPv4 link-local multicast address 22.214.171.124 for the use described in this document [MC4]. IANA has allocated the IPv6 multicast address set FF0X::FB (where "X" indicates any hexadecimal digit from '1' to 'F') for the use described in this document [MC6]. Only address FF02::FB (link-local scope) is currently in use by deployed software, but it is possible that in the future implementers may experiment with Multicast DNS using larger-scoped addresses, such as FF05::FB (site-local scope) [RFC4291].
IANA has implemented the following DNS records: MDNS.MCAST.NET. IN A 126.96.36.199 251.0.0.224.IN-ADDR.ARPA. IN PTR MDNS.MCAST.NET. Entries for the AAAA and corresponding PTR records have not been made as there is not yet an RFC providing direction for the management of the IP6.ARPA domain relating to the IPv6 multicast address space. The reuse of the top bit of the rrclass field in the Question and Resource Record Sections means that Multicast DNS can only carry DNS records with classes in the range 0-32767. Classes in the range 32768 to 65535 are incompatible with Multicast DNS. IANA has noted this fact, and if IANA receives a request to allocate a DNS class value above 32767, IANA will make sure the requester is aware of this implication before proceeding. This does not mean that allocations of DNS class values above 32767 should be denied, only that they should not be allowed until the requester has indicated that they are aware of how this allocation will interact with Multicast DNS. However, to date, only three DNS classes have been assigned by IANA (1, 3, and 4), and only one (1, "Internet") is actually in widespread use, so this issue is likely to remain a purely theoretical one. IANA has recorded the list of domains below as being Special-Use Domain Names [RFC6761]: .local. .254.169.in-addr.arpa. .8.e.f.ip6.arpa. .9.e.f.ip6.arpa. .a.e.f.ip6.arpa. .b.e.f.ip6.arpa. RFC6761] in the following ways: 1. Users may use these names as they would other DNS names, entering them anywhere that they would otherwise enter a conventional DNS name, or a dotted decimal IPv4 address, or a literal IPv6 address. Since there is no central authority responsible for assigning dot-local names, and all devices on the local network are equally entitled to claim any dot-local name, users SHOULD be
aware of this and SHOULD exercise appropriate caution. In an untrusted or unfamiliar network environment, users SHOULD be aware that using a name like "www.local" may not actually connect them to the web site they expected, and could easily connect them to a different web page, or even a fake or spoof of their intended web site, designed to trick them into revealing confidential information. As always with networking, end-to-end cryptographic security can be a useful tool. For example, when connecting with ssh, the ssh host key verification process will inform the user if it detects that the identity of the entity they are communicating with has changed since the last time they connected to that name. 2. Application software may use these names as they would other similar DNS names, and is not required to recognize the names and treat them specially. Due to the relative ease of spoofing dot-local names, end-to-end cryptographic security remains important when communicating across a local network, just as it is when communicating across the global Internet. 3. Name resolution APIs and libraries SHOULD recognize these names as special and SHOULD NOT send queries for these names to their configured (unicast) caching DNS server(s). This is to avoid unnecessary load on the root name servers and other name servers, caused by queries for which those name servers do not have useful non-negative answers to give, and will not ever have useful non-negative answers to give. 4. Caching DNS servers SHOULD recognize these names as special and SHOULD NOT attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve these names. Instead, caching DNS servers SHOULD generate immediate NXDOMAIN responses for all such queries they may receive (from misbehaving name resolver libraries). This is to avoid unnecessary load on the root name servers and other name servers. 5. Authoritative DNS servers SHOULD NOT by default be configurable to answer queries for these names, and, like caching DNS servers, SHOULD generate immediate NXDOMAIN responses for all such queries they may receive. DNS server software MAY provide a configuration option to override this default, for testing purposes or other specialized uses. 6. DNS server operators SHOULD NOT attempt to configure authoritative DNS servers to act as authoritative for any of these names. Configuring an authoritative DNS server to act as authoritative for any of these names may not, in many cases,
yield the expected result. Since name resolver libraries and caching DNS servers SHOULD NOT send queries for those names (see 3 and 4 above), such queries SHOULD be suppressed before they even reach the authoritative DNS server in question, and consequently it will not even get an opportunity to answer them. 7. DNS Registrars MUST NOT allow any of these names to be registered in the normal way to any person or entity. These names are reserved protocol identifiers with special meaning and fall outside the set of names available for allocation by registrars. Attempting to allocate one of these names as if it were a normal domain name will probably not work as desired, for reasons 3, 4, and 6 above.