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

   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:

   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

   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.

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.

   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

   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.

   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.

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.)

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

   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

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).

   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].

   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

         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.

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.