Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6762

Multicast DNS

Pages: 70
Proposed Standard
Errata
Part 3 of 4 – Pages 41 to 56
First   Prev   Next

Top   ToC   RFC6762 - Page 41   prevText

13. Enabling and Disabling Multicast DNS

The option to fail-over to Multicast DNS for names not ending in ".local." SHOULD be a user-configured option, and SHOULD be disabled by default because of the possible security issues related to unintended local resolution of apparently global names. Enabling Multicast DNS for names not ending in ".local." may be appropriate on a secure isolated network, or on some future network were machines exclusively use DNSSEC for all DNS queries, and have Multicast DNS responders capable of generating the appropriate cryptographic DNSSEC signatures, thereby guarding against spoofing. The option to look up unqualified (relative) names by appending ".local." (or not) is controlled by whether ".local." appears (or not) in the client's DNS search list. No special control is needed for enabling and disabling Multicast DNS for names explicitly ending with ".local." as entered by the user. The user doesn't need a way to disable Multicast DNS for names ending with ".local.", because if the user doesn't want to use Multicast DNS, they can achieve this by simply not using those names. If a user *does* enter a name ending in ".local.", then we can safely assume the user's intention was probably that it should work. Having user configuration options that can be (intentionally or
Top   ToC   RFC6762 - Page 42
   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".

14. Considerations for Multiple Interfaces

A host SHOULD defend its dot-local host name on all active interfaces on which it is answering Multicast DNS queries. In the event of a name conflict on *any* interface, a host should configure a new host name, if it wishes to maintain uniqueness of its host name. A host may choose to use the same name (or set of names) for all of its address records on all interfaces, or it may choose to manage its Multicast DNS interfaces independently, potentially answering to a different name (or set of names) on different interfaces. Except in the case of proxying and other similar specialized uses, addresses in IPv4 or IPv6 address records in Multicast DNS responses MUST be valid for use on the interface on which the response is being sent. Just as the same link-local IP address may validly be in use simultaneously on different links by different hosts, the same link- local host name may validly be in use simultaneously on different links, and this is not an error. A multihomed host with connections to two different links may be able to communicate with two different hosts that are validly using the same name. While this kind of name duplication should be rare, it means that a host that wants to fully support this case needs network programming APIs that allow applications to specify on what interface to perform a link-local Multicast DNS query, and to discover on what interface a Multicast DNS response was received. There is one other special precaution that multihomed hosts need to take. It's common with today's laptop computers to have an Ethernet connection and an 802.11 [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:
Top   ToC   RFC6762 - Page 43
   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.)

15. Considerations for Multiple Responders on the Same Machine

It is possible to have more than one Multicast DNS responder and/or querier implementation coexist on the same machine, but there are some known issues.

15.1. Receiving Unicast Responses

In most operating systems, incoming *multicast* packets can be delivered to *all* open sockets bound to the right port number, provided that the clients take the appropriate steps to allow this. For this reason, all Multicast DNS implementations SHOULD use the SO_REUSEPORT and/or SO_REUSEADDR options (or equivalent as appropriate for the operating system in question) so they will all be able to bind to UDP port 5353 and receive incoming multicast packets addressed to that port. However, unlike multicast packets, incoming unicast UDP packets are typically delivered only to the first socket to bind to that port. This means that "QU" responses and other packets sent via unicast will be received only by the first Multicast DNS responder and/or querier on a system. This limitation can be
Top   ToC   RFC6762 - Page 44
   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.

15.2. Multipacket Known-Answer lists

When a Multicast DNS querier issues a query with too many Known Answers to fit into a single packet, it divides the Known-Answer list into two or more packets. Multicast DNS responders associate the initial truncated query with its continuation packets by examining the source IP address in each packet. Since two independent Multicast DNS queriers running on the same machine will be sending packets with the same source IP address, from an outside perspective they appear to be a single entity. If both queriers happened to send the same multipacket query at the same time, with different Known- Answer lists, then they could each end up suppressing answers that the other needs.

15.3. Efficiency

If different clients on a machine were each to have their own independent Multicast DNS implementation, they would lose certain efficiency benefits. Apart from the unnecessary code duplication, memory usage, and CPU load, the clients wouldn't get the benefit of a shared system-wide cache, and they would not be able to aggregate separate queries into single packets to reduce network traffic.

15.4. Recommendation

Because of these issues, this document encourages implementers to design systems with a single Multicast DNS implementation that provides Multicast DNS services shared by all clients on that machine, much as most operating systems today have a single TCP implementation, which is shared between all clients on that machine. Due to engineering constraints, there may be situations where embedding a "user-level" Multicast DNS implementation in the client application software is the most expedient solution, and while this will usually work in practice, implementers should be aware of the issues outlined in this section.
Top   ToC   RFC6762 - Page 45

16. Multicast DNS Character Set

Historically, Unicast DNS has been used with a very restricted set of characters. Indeed, conventional DNS is usually limited to just twenty-six letters, ten digits and the hyphen character, not even allowing spaces or other punctuation. Attempts to remedy this for Unicast DNS have been badly constrained by the perceived need to accommodate old buggy legacy DNS implementations. In reality, the DNS specification itself actually imposes no limits on what characters may be used in names, and good DNS implementations handle any arbitrary eight-bit data without trouble. "Clarifications to the DNS Specification" [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.
Top   ToC   RFC6762 - Page 46
   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.

17. Multicast DNS Message Size

The 1987 DNS specification [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
Top   ToC   RFC6762 - Page 47
   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.

18. Multicast DNS Message Format

This section describes specific rules pertaining to the allowable values for the header fields of a Multicast DNS message, and other message format considerations.

18.1. ID (Query Identifier)

Multicast DNS implementations SHOULD listen for unsolicited responses issued by hosts booting up (or waking up from sleep or otherwise joining the network). Since these unsolicited responses may contain a useful answer to a question for which the querier is currently awaiting an answer, Multicast DNS implementations SHOULD examine all received Multicast DNS response messages for useful answers, without regard to the contents of the ID field or the Question Section. In Multicast DNS, knowing which particular query message (if any) is responsible for eliciting a particular response message is less interesting than knowing whether the response message contains useful information. Multicast DNS implementations MAY cache data from any or all Multicast DNS response messages they receive, for possible future use, provided of course that normal TTL aging is performed on these cached resource records. In multicast query messages, the Query Identifier SHOULD be set to zero on transmission.
Top   ToC   RFC6762 - Page 48
   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.

18.2. QR (Query/Response) Bit

In query messages the QR bit MUST be zero. In response messages the QR bit MUST be one.

18.3. OPCODE

In both multicast query and multicast response messages, the OPCODE MUST be zero on transmission (only standard queries are currently supported over multicast). Multicast DNS messages received with an OPCODE other than zero MUST be silently ignored.

18.4. AA (Authoritative Answer) Bit

In query messages, the Authoritative Answer bit MUST be zero on transmission, and MUST be ignored on reception. In response messages for Multicast domains, the Authoritative Answer bit MUST be set to one (not setting this bit would imply there's some other place where "better" information may be found) and MUST be ignored on reception.

18.5. TC (Truncated) Bit

In query messages, if the TC bit is set, it means that additional Known-Answer records may be following shortly. A responder SHOULD record this fact, and wait for those additional Known-Answer records, before deciding whether to respond. If the TC bit is clear, it means that the querying host has no additional Known Answers. In multicast response messages, the TC bit MUST be zero on transmission, and MUST be ignored on reception. In legacy unicast response messages, the TC bit has the same meaning as in conventional Unicast DNS: it means that the response was too large to fit in a single packet, so the querier SHOULD reissue its query using TCP in order to receive the larger response.
Top   ToC   RFC6762 - Page 49

18.6. RD (Recursion Desired) Bit

In both multicast query and multicast response messages, the Recursion Desired bit SHOULD be zero on transmission, and MUST be ignored on reception.

18.7. RA (Recursion Available) Bit

In both multicast query and multicast response messages, the Recursion Available bit MUST be zero on transmission, and MUST be ignored on reception.

18.8. Z (Zero) Bit

In both query and response messages, the Zero bit MUST be zero on transmission, and MUST be ignored on reception.

18.9. AD (Authentic Data) Bit

In both multicast query and multicast response messages, the Authentic Data bit [RFC2535] MUST be zero on transmission, and MUST be ignored on reception.

18.10. CD (Checking Disabled) Bit

In both multicast query and multicast response messages, the Checking Disabled bit [RFC2535] MUST be zero on transmission, and MUST be ignored on reception.

18.11. RCODE (Response Code)

In both multicast query and multicast response messages, the Response Code MUST be zero on transmission. Multicast DNS messages received with non-zero Response Codes MUST be silently ignored.

18.12. Repurposing of Top Bit of qclass in Question Section

In the Question Section of a Multicast DNS query, the top bit of the qclass field is used to indicate that unicast responses are preferred for this particular question. (See Section 5.4.)

18.13. Repurposing of Top Bit of rrclass in Resource Record Sections

In the Resource Record Sections of a Multicast DNS response, the top bit of the rrclass field is used to indicate that the record is a member of a unique RRSet, and the entire RRSet has been sent together (in the same packet, or in consecutive packets if there are too many records to fit in a single packet). (See Section 10.2.)
Top   ToC   RFC6762 - Page 50

18.14. Name Compression

When generating Multicast DNS messages, implementations SHOULD use name compression wherever possible to compress the names of resource records, by replacing some or all of the resource record name with a compact two-byte reference to an appearance of that data somewhere earlier in the message [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
Top   ToC   RFC6762 - Page 51
   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.

19. Summary of Differences between Multicast DNS and Unicast DNS

Multicast DNS shares, as much as possible, the familiar APIs, naming syntax, resource record types, etc., of Unicast DNS. There are, of course, necessary differences by virtue of it using multicast, and by virtue of it operating in a community of cooperating peers, rather than a precisely defined hierarchy controlled by a strict chain of formal delegations from the root. These differences are summarized below: Multicast DNS... * uses multicast * uses UDP port 5353 instead of port 53 * operates in well-defined parts of the DNS namespace * has no SOA (Start of Authority) records * uses UTF-8, and only UTF-8, to encode resource record names * allows names up to 255 bytes plus a terminating zero byte * allows name compression in rdata for SRV and other record types * allows larger UDP packets * allows more than one question in a query message * defines consistent results for qtype "ANY" and qclass "ANY" queries * uses the Answer Section of a query to list Known Answers * uses the TC bit in a query to indicate additional Known Answers * uses the Authority Section of a query for probe tiebreaking * ignores the Query ID field (except for generating legacy responses) * doesn't require the question to be repeated in the response message * uses unsolicited responses to announce new records * uses NSEC records to signal nonexistence of records * defines a unicast-response bit in the rrclass of query questions * defines a cache-flush bit in the rrclass of response records * uses DNS RR TTL 0 to indicate that a record has been deleted * recommends AAAA records in the additional section when responding to rrtype "A" queries, and vice versa * monitors queries to perform Duplicate Question Suppression * monitors responses to perform Duplicate Answer Suppression... * ... and Ongoing Conflict Detection * ... and Opportunistic Caching
Top   ToC   RFC6762 - Page 52

20. IPv6 Considerations

An IPv4-only host and an IPv6-only host behave as "ships that pass in the night". Even if they are on the same Ethernet, neither is aware of the other's traffic. For this reason, each physical link may have *two* unrelated ".local." zones, one for IPv4 and one for IPv6. Since for practical purposes, a group of IPv4-only hosts and a group of IPv6-only hosts on the same Ethernet act as if they were on two entirely separate Ethernet segments, it is unsurprising that their use of the ".local." zone should occur exactly as it would if they really were on two entirely separate Ethernet segments. A dual-stack (v4/v6) host can participate in both ".local." zones, and should register its name(s) and perform its lookups both using IPv4 and IPv6. This enables it to reach, and be reached by, both IPv4-only and IPv6-only hosts. In effect, this acts like a multihomed host, with one connection to the logical "IPv4 Ethernet segment", and a connection to the logical "IPv6 Ethernet segment". When such a host generates NSEC records, if it is using the same host name for its IPv4 addresses and its IPv6 addresses on that network interface, its NSEC records should indicate that the host name has both A and AAAA records.

21. Security Considerations

The algorithm for detecting and resolving name conflicts is, by its very nature, an algorithm that assumes cooperating participants. Its purpose is to allow a group of hosts to arrive at a mutually disjoint set of host names and other DNS resource record names, in the absence of any central authority to coordinate this or mediate disputes. In the absence of any higher authority to resolve disputes, the only alternative is that the participants must work together cooperatively to arrive at a resolution. In an environment where the participants are mutually antagonistic and unwilling to cooperate, other mechanisms are appropriate, like manually configured DNS. In an environment where there is a group of cooperating participants, but clients cannot be sure that there are no antagonistic hosts on the same physical link, the cooperating participants need to use IPsec signatures and/or DNSSEC [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).
Top   ToC   RFC6762 - Page 53
   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.

22. IANA Considerations

IANA has allocated the UDP port 5353 for the Multicast DNS protocol described in this document [SN]. IANA has allocated the IPv4 link-local multicast address 224.0.0.251 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].
Top   ToC   RFC6762 - Page 54
   IANA has implemented the following DNS records:

      MDNS.MCAST.NET.            IN  A    224.0.0.251
      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.

22.1. Domain Name Reservation Considerations

The six domains listed above, and any names falling within those domains (e.g., "MyPrinter.local.", "34.12.254.169.in-addr.arpa.", "Ink-Jet._pdl-datastream._tcp.local.") are special [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
Top   ToC   RFC6762 - Page 55
         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,
Top   ToC   RFC6762 - Page 56
         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.

23. Acknowledgments

The concepts described in this document have been explored, developed, and implemented with help from Ran Atkinson, Richard Brown, Freek Dijkstra, Erik Guttman, Kyle McKay, Pasi Sarolahti, Pekka Savola, Robby Simpson, Mark Townsley, Paul Vixie, Bill Woodcock, and others. Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher, Rory McGuire, Roger Pantos, and Kiren Sekar for their significant contributions. Special thanks also to Kerry Lynn for converting the document to xml2rfc form in May 2010, and to Area Director Ralph Droms for shepherding the document through its final steps.


(page 56 continued on part 4)

Next Section