• source navigation  • diff markup  • identifier search  • freetext search  • 


  7 Internet Engineering Task Force (IETF)                       S. Cheshire
  8 Request for Comments: 6762                                   M. Krochmal
  9 Category: Standards Track                                     Apple Inc.
 10 ISSN: 2070-1721                                            February 2013
 13                              Multicast DNS
 15 Abstract
 17    As networked devices become smaller, more portable, and more
 18    ubiquitous, the ability to operate with less configured
 19    infrastructure is increasingly important.  In particular, the ability
 20    to look up DNS resource record data types (including, but not limited
 21    to, host names) in the absence of a conventional managed DNS server
 22    is useful.
 24    Multicast DNS (mDNS) provides the ability to perform DNS-like
 25    operations on the local link in the absence of any conventional
 26    Unicast DNS server.  In addition, Multicast DNS designates a portion
 27    of the DNS namespace to be free for local use, without the need to
 28    pay any annual fee, and without the need to set up delegations or
 29    otherwise configure a conventional DNS server to answer for those
 30    names.
 32    The primary benefits of Multicast DNS names are that (i) they require
 33    little or no administration or configuration to set them up, (ii)
 34    they work when no infrastructure is present, and (iii) they work
 35    during infrastructure failures.
 37 Status of This Memo
 39    This is an Internet Standards Track document.
 41    This document is a product of the Internet Engineering Task Force
 42    (IETF).  It represents the consensus of the IETF community.  It has
 43    received public review and has been approved for publication by the
 44    Internet Engineering Steering Group (IESG).  Further information on
 45    Internet Standards is available in Section 2 of RFC 5741.
 47    Information about the current status of this document, any errata,
 48    and how to provide feedback on it may be obtained at
 49    http://www.rfc-editor.org/info/rfc6762.
 58 Cheshire & Krochmal          Standards Track                    [Page 1]
 60 RFC 6762                      Multicast DNS                February 2013
 63 Copyright Notice
 65    Copyright (c) 2013 IETF Trust and the persons identified as the
 66    document authors.  All rights reserved.
 68    This document is subject to BCP 78 and the IETF Trust's Legal
 69    Provisions Relating to IETF Documents
 70    (http://trustee.ietf.org/license-info) in effect on the date of
 71    publication of this document.  Please review these documents
 72    carefully, as they describe your rights and restrictions with respect
 73    to this document.  Code Components extracted from this document must
 74    include Simplified BSD License text as described in Section 4.e of
 75    the Trust Legal Provisions and are provided without warranty as
 76    described in the Simplified BSD License.
 78    This document may contain material from IETF Documents or IETF
 79    Contributions published or made publicly available before November
 80    10, 2008.  The person(s) controlling the copyright in some of this
 81    material may not have granted the IETF Trust the right to allow
 82    modifications of such material outside the IETF Standards Process.
 83    Without obtaining an adequate license from the person(s) controlling
 84    the copyright in such materials, this document may not be modified
 85    outside the IETF Standards Process, and derivative works of it may
 86    not be created outside the IETF Standards Process, except to format
 87    it for publication as an RFC or to translate it into languages other
 88    than English.
114 Cheshire & Krochmal          Standards Track                    [Page 2]
116 RFC 6762                      Multicast DNS                February 2013
119 Table of Contents
121    1. Introduction ....................................................4
122    2. Conventions and Terminology Used in This Document ...............4
123    3. Multicast DNS Names .............................................5
124    4. Reverse Address Mapping .........................................7
125    5. Querying ........................................................8
126    6. Responding .....................................................13
127    7. Traffic Reduction ..............................................22
128    8. Probing and Announcing on Startup ..............................25
129    9. Conflict Resolution ............................................31
130    10. Resource Record TTL Values and Cache Coherency ................33
131    11. Source Address Check ..........................................38
132    12. Special Characteristics of Multicast DNS Domains ..............40
133    13. Enabling and Disabling Multicast DNS ..........................41
134    14. Considerations for Multiple Interfaces ........................42
135    15. Considerations for Multiple Responders on the Same Machine ....43
136    16. Multicast DNS Character Set ...................................45
137    17. Multicast DNS Message Size ....................................46
138    18. Multicast DNS Message Format ..................................47
139    19. Summary of Differences between Multicast DNS and Unicast DNS ..51
140    20. IPv6 Considerations ...........................................52
141    21. Security Considerations .......................................52
142    22. IANA Considerations ...........................................53
143    23. Acknowledgments ...............................................56
144    24. References ....................................................56
145    Appendix A. Design Rationale for Choice of UDP Port Number ........60
146    Appendix B. Design Rationale for Not Using Hashed Multicast
147                Addresses .............................................61
148    Appendix C. Design Rationale for Maximum Multicast DNS Name
149                Length ................................................62
150    Appendix D. Benefits of Multicast Responses .......................64
151    Appendix E. Design Rationale for Encoding Negative Responses ......65
152    Appendix F. Use of UTF-8 ..........................................66
153    Appendix G. Private DNS Namespaces ................................67
154    Appendix H. Deployment History ....................................67
170 Cheshire & Krochmal          Standards Track                    [Page 3]
172 RFC 6762                      Multicast DNS                February 2013
175 1.  Introduction
177    Multicast DNS and its companion technology DNS-Based Service
178    Discovery [RFC6763] were created to provide IP networking with the
179    ease-of-use and autoconfiguration for which AppleTalk was well-known
180    [RFC6760].  When reading this document, familiarity with the concepts
181    of Zero Configuration Networking [Zeroconf] and automatic link-local
182    addressing [RFC3927] [RFC4862] is helpful.
184    Multicast DNS borrows heavily from the existing DNS protocol
185    [RFC1034] [RFC1035] [RFC6195], using the existing DNS message
186    structure, name syntax, and resource record types.  This document
187    specifies no new operation codes or response codes.  This document
188    describes how clients send DNS-like queries via IP multicast, and how
189    a collection of hosts cooperate to collectively answer those queries
190    in a useful manner.
192 2.  Conventions and Terminology Used in This Document
194    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
195    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
196    document are to be interpreted as described in "Key words for use in
197    RFCs to Indicate Requirement Levels" [RFC2119].
199    When this document uses the term "Multicast DNS", it should be taken
200    to mean: "Clients performing DNS-like queries for DNS-like resource
201    records by sending DNS-like UDP query and response messages over IP
202    Multicast to UDP port 5353".  The design rationale for selecting UDP
203    port 5353 is discussed in Appendix A.
205    This document uses the term "host name" in the strict sense to mean a
206    fully qualified domain name that has an IPv4 or IPv6 address record.
207    It does not use the term "host name" in the commonly used but
208    incorrect sense to mean just the first DNS label of a host's fully
209    qualified domain name.
211    A DNS (or mDNS) packet contains an IP Time to Live (TTL) in the IP
212    header, which is effectively a hop-count limit for the packet, to
213    guard against routing loops.  Each resource record also contains a
214    TTL, which is the number of seconds for which the resource record may
215    be cached.  This document uses the term "IP TTL" to refer to the IP
216    header TTL (hop limit), and the term "RR TTL" or just "TTL" to refer
217    to the resource record TTL (cache lifetime).
219    DNS-format messages contain a header, a Question Section, then
220    Answer, Authority, and Additional Record Sections.  The Answer,
221    Authority, and Additional Record Sections all hold resource records
226 Cheshire & Krochmal          Standards Track                    [Page 4]
228 RFC 6762                      Multicast DNS                February 2013
231    in the same format.  Where this document describes issues that apply
232    equally to all three sections, it uses the term "Resource Record
233    Sections" to refer collectively to these three sections.
235    This document uses the terms "shared" and "unique" when referring to
236    resource record sets [RFC1034]:
238       A "shared" resource record set is one where several Multicast DNS
239       responders may have records with the same name, rrtype, and
240       rrclass, and several responders may respond to a particular query.
242       A "unique" resource record set is one where all the records with
243       that name, rrtype, and rrclass are conceptually under the control
244       or ownership of a single responder, and it is expected that at
245       most one responder should respond to a query for that name,
246       rrtype, and rrclass.  Before claiming ownership of a unique
247       resource record set, a responder MUST probe to verify that no
248       other responder already claims ownership of that set, as described
249       in Section 8.1, "Probing".  (For fault-tolerance and other
250       reasons, sometimes it is permissible to have more than one
251       responder answering for a particular "unique" resource record set,
252       but such cooperating responders MUST give answers containing
253       identical rdata for these records.  If they do not give answers
254       containing identical rdata, then the probing step will reject the
255       data as being inconsistent with what is already being advertised
256       on the network for those names.)
258    Strictly speaking, the terms "shared" and "unique" apply to resource
259    record sets, not to individual resource records.  However, it is
260    sometimes convenient to talk of "shared resource records" and "unique
261    resource records".  When used this way, the terms should be
262    understood to mean a record that is a member of a "shared" or
263    "unique" resource record set, respectively.
265 3.  Multicast DNS Names
267    A host that belongs to an organization or individual who has control
268    over some portion of the DNS namespace can be assigned a globally
269    unique name within that portion of the DNS namespace, such as,
270    "cheshire.example.com.".  For those of us who have this luxury, this
271    works very well.  However, the majority of home computer users do not
272    have easy access to any portion of the global DNS namespace within
273    which they have the authority to create names.  This leaves the
274    majority of home computers effectively anonymous for practical
275    purposes.
282 Cheshire & Krochmal          Standards Track                    [Page 5]
284 RFC 6762                      Multicast DNS                February 2013
287    To remedy this problem, this document allows any computer user to
288    elect to give their computers link-local Multicast DNS host names of
289    the form: "single-dns-label.local.".  For example, a laptop computer
290    may answer to the name "MyComputer.local.".  Any computer user is
291    granted the authority to name their computer this way, provided that
292    the chosen host name is not already in use on that link.  Having
293    named their computer this way, the user has the authority to continue
294    utilizing that name until such time as a name conflict occurs on the
295    link that is not resolved in the user's favor.  If this happens, the
296    computer (or its human user) MUST cease using the name, and SHOULD
297    attempt to allocate a new unique name for use on that link.  These
298    conflicts are expected to be relatively rare for people who choose
299    reasonably imaginative names, but it is still important to have a
300    mechanism in place to handle them when they happen.
302    This document specifies that the DNS top-level domain ".local." is a
303    special domain with special semantics, namely that any fully
304    qualified name ending in ".local." is link-local, and names within
305    this domain are meaningful only on the link where they originate.
306    This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6
307    addresses in the FE80::/10 prefix, which are link-local and
308    meaningful only on the link where they originate.
310    Any DNS query for a name ending with ".local." MUST be sent to the
311    mDNS IPv4 link-local multicast address (or its IPv6
312    equivalent FF02::FB).  The design rationale for using a fixed
313    multicast address instead of selecting from a range of multicast
314    addresses using a hash function is discussed in Appendix B.
315    Implementers MAY choose to look up such names concurrently via other
316    mechanisms (e.g., Unicast DNS) and coalesce the results in some
317    fashion.  Implementers choosing to do this should be aware of the
318    potential for user confusion when a given name can produce different
319    results depending on external network conditions (such as, but not
320    limited to, which name lookup mechanism responds faster).
322    It is unimportant whether a name ending with ".local." occurred
323    because the user explicitly typed in a fully qualified domain name
324    ending in ".local.", or because the user entered an unqualified
325    domain name and the host software appended the suffix ".local."
326    because that suffix appears in the user's search list.  The ".local."
327    suffix could appear in the search list because the user manually
328    configured it, or because it was received via DHCP [RFC2132] or via
329    any other mechanism for configuring the DNS search list.  In this
330    respect the ".local." suffix is treated no differently from any other
331    search domain that might appear in the DNS search list.
338 Cheshire & Krochmal          Standards Track                    [Page 6]
340 RFC 6762                      Multicast DNS                February 2013
343    DNS queries for names that do not end with ".local." MAY be sent to
344    the mDNS multicast address, if no other conventional DNS server is
345    available.  This can allow hosts on the same link to continue
346    communicating using each other's globally unique DNS names during
347    network outages that disrupt communication with the greater Internet.
348    When resolving global names via local multicast, it is even more
349    important to use DNS Security Extensions (DNSSEC) [RFC4033] or other
350    security mechanisms to ensure that the response is trustworthy.
351    Resolving global names via local multicast is a contentious issue,
352    and this document does not discuss it further, instead concentrating
353    on the issue of resolving local names using DNS messages sent to a
354    multicast address.
356    This document recommends a single flat namespace for dot-local host
357    names, (i.e., the names of DNS "A" and "AAAA" records, which map
358    names to IPv4 and IPv6 addresses), but other DNS record types (such
359    as those used by DNS-Based Service Discovery [RFC6763]) may contain
360    as many labels as appropriate for the desired usage, up to a maximum
361    of 255 bytes, plus a terminating zero byte at the end.  Name length
362    issues are discussed further in Appendix C.
364    Enforcing uniqueness of host names is probably desirable in the
365    common case, but this document does not mandate that.  It is
366    permissible for a collection of coordinated hosts to agree to
367    maintain multiple DNS address records with the same name, possibly
368    for load-balancing or fault-tolerance reasons.  This document does
369    not take a position on whether that is sensible.  It is important
370    that both modes of operation be supported.  The Multicast DNS
371    protocol allows hosts to verify and maintain unique names for
372    resource records where that behavior is desired, and it also allows
373    hosts to maintain multiple resource records with a single shared name
374    where that behavior is desired.  This consideration applies to all
375    resource records, not just address records (host names).  In summary:
376    It is required that the protocol have the ability to detect and
377    handle name conflicts, but it is not required that this ability be
378    used for every record.
380 4.  Reverse Address Mapping
382    Like ".local.", the IPv4 and IPv6 reverse mapping domains are also
383    defined to be link-local:
385       Any DNS query for a name ending with "254.169.in-addr.arpa." MUST
386       be sent to the mDNS IPv4 link-local multicast address
387       or the mDNS IPv6 multicast address FF02::FB.  Since names under
388       this domain correspond to IPv4 link-local addresses, it is logical
389       that the local link is the best place to find information
390       pertaining to those names.
394 Cheshire & Krochmal          Standards Track                    [Page 7]
396 RFC 6762                      Multicast DNS                February 2013
399       Likewise, any DNS query for a name within the reverse mapping
400       domains for IPv6 link-local addresses ("8.e.f.ip6.arpa.",
401       "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.") MUST
402       be sent to the mDNS IPv6 link-local multicast address FF02::FB or
403       the mDNS IPv4 link-local multicast address
405 5.  Querying
407    There are two kinds of Multicast DNS queries: one-shot queries of the
408    kind made by legacy DNS resolvers, and continuous, ongoing Multicast
409    DNS queries made by fully compliant Multicast DNS queriers, which
410    support asynchronous operations including DNS-Based Service Discovery
411    [RFC6763].
413    Except in the rare case of a Multicast DNS responder that is
414    advertising only shared resource records and no unique records, a
415    Multicast DNS responder MUST also implement a Multicast DNS querier
416    so that it can first verify the uniqueness of those records before it
417    begins answering queries for them.
419 5.1.  One-Shot Multicast DNS Queries
421    The most basic kind of Multicast DNS client may simply send standard
422    DNS queries blindly to, without necessarily even
423    being aware of what a multicast address is.  This change can
424    typically be implemented with just a few lines of code in an existing
425    DNS resolver library.  If a name being queried falls within one of
426    the reserved Multicast DNS domains (see Sections 3 and 4), then,
427    rather than using the configured Unicast DNS server address, the
428    query is instead sent to (or its IPv6 equivalent
429    [FF02::FB]:5353).  Typically, the timeout would also be shortened to
430    two or three seconds.  It's possible to make a minimal Multicast DNS
431    resolver with only these simple changes.  These queries are typically
432    done using a high-numbered ephemeral UDP source port, but regardless
433    of whether they are sent from a dynamic port or from a fixed port,
434    these queries MUST NOT be sent using UDP source port 5353, since
435    using UDP source port 5353 signals the presence of a fully compliant
436    Multicast DNS querier, as described below.
438    A simple DNS resolver like this will typically just take the first
439    response it receives.  It will not listen for additional UDP
440    responses, but in many instances this may not be a serious problem.
441    If a user types "http://MyPrinter.local." into their web browser, and
442    their simple DNS resolver just takes the first response it receives,
443    and the user gets to see the status and configuration web page for
444    their printer, then the protocol has met the user's needs in this
445    case.
450 Cheshire & Krochmal          Standards Track                    [Page 8]
452 RFC 6762                      Multicast DNS                February 2013
455    While a basic DNS resolver like this may be adequate for simple host
456    name lookup, it may not get ideal behavior in other cases.
457    Additional refinements to create a fully compliant Multicast DNS
458    querier are described below.
460 5.2.  Continuous Multicast DNS Querying
462    In one-shot queries, the underlying assumption is that the
463    transaction begins when the application issues a query, and ends when
464    the first response is received.  There is another type of query
465    operation that is more asynchronous, in which having received one
466    response is not necessarily an indication that there will be no more
467    relevant responses, and the querying operation continues until no
468    further responses are required.  Determining when no further
469    responses are required depends on the type of operation being
470    performed.  If the operation is looking up the IPv4 and IPv6
471    addresses of another host, then no further responses are required
472    once a successful connection has been made to one of those IPv4 or
473    IPv6 addresses.  If the operation is browsing to present the user
474    with a list of DNS-SD services found on the network [RFC6763], then
475    no further responses are required once the user indicates this to the
476    user-interface software, e.g., by closing the network browsing window
477    that was displaying the list of discovered services.
479    Imagine some hypothetical software that allows users to discover
480    network printers.  The user wishes to discover all printers on the
481    local network, not only the printer that is quickest to respond.
482    When the user is actively looking for a network printer to use, they
483    open a network browsing window that displays the list of discovered
484    printers.  It would be convenient for the user if they could rely on
485    this list of network printers to stay up to date as network printers
486    come and go, rather than displaying out-of-date stale information,
487    and requiring the user explicitly to click a "refresh" button any
488    time they want to see accurate information (which, from the moment it
489    is displayed, is itself already beginning to become out-of-date and
490    stale).  If we are to display a continuously updated live list like
491    this, we need to be able to do it efficiently, without naive constant
492    polling, which would be an unreasonable burden on the network.  It is
493    not expected that all users will be browsing to discover new printers
494    all the time, but when a user is browsing to discover service
495    instances for an extended period, we want to be able to support that
496    operation efficiently.
498    Therefore, when retransmitting Multicast DNS queries to implement
499    this kind of continuous monitoring, the interval between the first
500    two queries MUST be at least one second, the intervals between
501    successive queries MUST increase by at least a factor of two, and the
502    querier MUST implement Known-Answer Suppression, as described below
506 Cheshire & Krochmal          Standards Track                    [Page 9]
508 RFC 6762                      Multicast DNS                February 2013
511    in Section 7.1.  The Known-Answer Suppression mechanism tells
512    responders which answers are already known to the querier, thereby
513    allowing responders to avoid wasting network capacity with pointless
514    repeated transmission of those answers.  A querier retransmits its
515    question because it wishes to receive answers it may have missed the
516    first time, not because it wants additional duplicate copies of
517    answers it already received.  Failure to implement Known-Answer
518    Suppression can result in unacceptable levels of network traffic.
519    When the interval between queries reaches or exceeds 60 minutes, a
520    querier MAY cap the interval to a maximum of 60 minutes, and perform
521    subsequent queries at a steady-state rate of one query per hour.  To
522    avoid accidental synchronization when, for some reason, multiple
523    clients begin querying at exactly the same moment (e.g., because of
524    some common external trigger event), a Multicast DNS querier SHOULD
525    also delay the first query of the series by a randomly chosen amount
526    in the range 20-120 ms.
528    When a Multicast DNS querier receives an answer, the answer contains
529    a TTL value that indicates for how many seconds this answer is valid.
530    After this interval has passed, the answer will no longer be valid
531    and SHOULD be deleted from the cache.  Before the record expiry time
532    is reached, a Multicast DNS querier that has local clients with an
533    active interest in the state of that record (e.g., a network browsing
534    window displaying a list of discovered services to the user) SHOULD
535    reissue its query to determine whether the record is still valid.
537    To perform this cache maintenance, a Multicast DNS querier should
538    plan to retransmit its query after at least 50% of the record
539    lifetime has elapsed.  This document recommends the following
540    specific strategy.
542    The querier should plan to issue a query at 80% of the record
543    lifetime, and then if no answer is received, at 85%, 90%, and 95%.
544    If an answer is received, then the remaining TTL is reset to the
545    value given in the answer, and this process repeats for as long as
546    the Multicast DNS querier has an ongoing interest in the record.  If
547    no answer is received after four queries, the record is deleted when
548    it reaches 100% of its lifetime.  A Multicast DNS querier MUST NOT
549    perform this cache maintenance for records for which it has no local
550    clients with an active interest.  If the expiry of a particular
551    record from the cache would result in no net effect to any client
552    software running on the querier device, and no visible effect to the
553    human user, then there is no reason for the Multicast DNS querier to
554    waste network capacity checking whether the record remains valid.
562 Cheshire & Krochmal          Standards Track                   [Page 10]
564 RFC 6762                      Multicast DNS                February 2013
567    To avoid the case where multiple Multicast DNS queriers on a network
568    all issue their queries simultaneously, a random variation of 2% of
569    the record TTL should be added, so that queries are scheduled to be
570    performed at 80-82%, 85-87%, 90-92%, and then 95-97% of the TTL.
572    An additional efficiency optimization SHOULD be performed when a
573    Multicast DNS response is received containing a unique answer (as
574    indicated by the cache-flush bit being set, described in Section
575    10.2, "Announcements to Flush Outdated Cache Entries").  In this
576    case, there is no need for the querier to continue issuing a stream
577    of queries with exponentially increasing intervals, since the receipt
578    of a unique answer is a good indication that no other answers will be
579    forthcoming.  In this case, the Multicast DNS querier SHOULD plan to
580    issue its next query for this record at 80-82% of the record's TTL,
581    as described above.
583    A compliant Multicast DNS querier, which implements the rules
584    specified in this document, MUST send its Multicast DNS queries from
585    UDP source port 5353 (the well-known port assigned to mDNS), and MUST
586    listen for Multicast DNS replies sent to UDP destination port 5353 at
587    the mDNS link-local multicast address ( and/or its IPv6
588    equivalent FF02::FB).
590 5.3.  Multiple Questions per Query
592    Multicast DNS allows a querier to place multiple questions in the
593    Question Section of a single Multicast DNS query message.
595    The semantics of a Multicast DNS query message containing multiple
596    questions is identical to a series of individual DNS query messages
597    containing one question each.  Combining multiple questions into a
598    single message is purely an efficiency optimization and has no other
599    semantic significance.
601 5.4.  Questions Requesting Unicast Responses
603    Sending Multicast DNS responses via multicast has the benefit that
604    all the other hosts on the network get to see those responses,
605    enabling them to keep their caches up to date and detect conflicting
606    responses.
608    However, there are situations where all the other hosts on the
609    network don't need to see every response.  Some examples are a laptop
610    computer waking from sleep, the Ethernet cable being connected to a
611    running machine, or a previously inactive interface being activated
612    through a configuration change.  At the instant of wake-up or link
613    activation, the machine is a brand new participant on a new network.
614    Its Multicast DNS cache for that interface is empty, and it has no
618 Cheshire & Krochmal          Standards Track                   [Page 11]
620 RFC 6762                      Multicast DNS                February 2013
623    knowledge of its peers on that link.  It may have a significant
624    number of questions that it wants answered right away, to discover
625    information about its new surroundings and present that information
626    to the user.  As a new participant on the network, it has no idea
627    whether the exact same questions may have been asked and answered
628    just seconds ago.  In this case, triggering a large sudden flood of
629    multicast responses may impose an unreasonable burden on the network.
631    To avoid large floods of potentially unnecessary responses in these
632    cases, Multicast DNS defines the top bit in the class field of a DNS
633    question as the unicast-response bit.  When this bit is set in a
634    question, it indicates that the querier is willing to accept unicast
635    replies in response to this specific query, as well as the usual
636    multicast responses.  These questions requesting unicast responses
637    are referred to as "QU" questions, to distinguish them from the more
638    usual questions requesting multicast responses ("QM" questions).  A
639    Multicast DNS querier sending its initial batch of questions
640    immediately on wake from sleep or interface activation SHOULD set the
641    unicast-response bit in those questions.
643    When a question is retransmitted (as described in Section 5.2), the
644    unicast-response bit SHOULD NOT be set in subsequent retransmissions
645    of that question.  Subsequent retransmissions SHOULD be usual "QM"
646    questions.  After the first question has received its responses, the
647    querier should have a large Known-Answer list (Section 7.1) so that
648    subsequent queries should elicit few, if any, further responses.
649    Reverting to multicast responses as soon as possible is important
650    because of the benefits that multicast responses provide (see
651    Appendix D).  In addition, the unicast-response bit SHOULD be set
652    only for questions that are active and ready to be sent the moment of
653    wake from sleep or interface activation.  New questions created by
654    local clients afterwards should be treated as normal "QM" questions
655    and SHOULD NOT have the unicast-response bit set on the first
656    question of the series.
658    When receiving a question with the unicast-response bit set, a
659    responder SHOULD usually respond with a unicast packet directed back
660    to the querier.  However, if the responder has not multicast that
661    record recently (within one quarter of its TTL), then the responder
662    SHOULD instead multicast the response so as to keep all the peer
663    caches up to date, and to permit passive conflict detection.  In the
664    case of answering a probe question (Section 8.1) with the unicast-
665    response bit set, the responder should always generate the requested
666    unicast response, but it may also send a multicast announcement if
667    the time since the last multicast announcement of that record is more
668    than a quarter of its TTL.
674 Cheshire & Krochmal          Standards Track                   [Page 12]
676 RFC 6762                      Multicast DNS                February 2013
679    Unicast replies are subject to all the same packet generation rules
680    as multicast replies, including the cache-flush bit (Section 10.2)
681    and (except when defending a unique name against a probe from another
682    host) randomized delays to reduce network collisions (Section 6).
684 5.5.  Direct Unicast Queries to Port 5353
686    In specialized applications there may be rare situations where it
687    makes sense for a Multicast DNS querier to send its query via unicast
688    to a specific machine.  When a Multicast DNS responder receives a
689    query via direct unicast, it SHOULD respond as it would for "QU"
690    questions, as described above in Section 5.4.  Since it is possible
691    for a unicast query to be received from a machine outside the local
692    link, responders SHOULD check that the source address in the query
693    packet matches the local subnet for that link (or, in the case of
694    IPv6, the source address has an on-link prefix) and silently ignore
695    the packet if not.
697    There may be specialized situations, outside the scope of this
698    document, where it is intended and desirable to create a responder
699    that does answer queries originating outside the local link.  Such a
700    responder would need to ensure that these non-local queries are
701    always answered via unicast back to the querier, since an answer sent
702    via link-local multicast would not reach a querier outside the local
703    link.
705 6.  Responding
707    When a Multicast DNS responder constructs and sends a Multicast DNS
708    response message, the Resource Record Sections of that message must
709    contain only records for which that responder is explicitly
710    authoritative.  These answers may be generated because the record
711    answers a question received in a Multicast DNS query message, or at
712    certain other times that the responder determines than an unsolicited
713    announcement is warranted.  A Multicast DNS responder MUST NOT place
714    records from its cache, which have been learned from other responders
715    on the network, in the Resource Record Sections of outgoing response
716    messages.  Only an authoritative source for a given record is allowed
717    to issue responses containing that record.
719    The determination of whether a given record answers a given question
720    is made using the standard DNS rules: the record name must match the
721    question name, the record rrtype must match the question qtype unless
722    the qtype is "ANY" (255) or the rrtype is "CNAME" (5), and the record
723    rrclass must match the question qclass unless the qclass is "ANY"
724    (255).  As with Unicast DNS, generally only DNS class 1 ("Internet")
725    is used, but should client software use classes other than 1, the
726    matching rules described above MUST be used.
730 Cheshire & Krochmal          Standards Track                   [Page 13]
732 RFC 6762                      Multicast DNS                February 2013
735    A Multicast DNS responder MUST only respond when it has a positive,
736    non-null response to send, or it authoritatively knows that a
737    particular record does not exist.  For unique records, where the host
738    has already established sole ownership of the name, it MUST return
739    negative answers to queries for records that it knows not to exist.
740    For example, a host with no IPv6 address, that has claimed sole
741    ownership of the name "host.local." for all rrtypes, MUST respond to
742    AAAA queries for "host.local." by sending a negative answer
743    indicating that no AAAA records exist for that name.  See Section
744    6.1, "Negative Responses".  For shared records, which are owned by no
745    single host, the nonexistence of a given record is ascertained by the
746    failure of any machine to respond to the Multicast DNS query, not by
747    any explicit negative response.  For shared records, NXDOMAIN and
748    other error responses MUST NOT be sent.
750    Multicast DNS responses MUST NOT contain any questions in the
751    Question Section.  Any questions in the Question Section of a
752    received Multicast DNS response MUST be silently ignored.  Multicast
753    DNS queriers receiving Multicast DNS responses do not care what
754    question elicited the response; they care only that the information
755    in the response is true and accurate.
757    A Multicast DNS responder on Ethernet [IEEE.802.3] and similar shared
758    multiple access networks SHOULD have the capability of delaying its
759    responses by up to 500 ms, as described below.
761    If a large number of Multicast DNS responders were all to respond
762    immediately to a particular query, a collision would be virtually
763    guaranteed.  By imposing a small random delay, the number of
764    collisions is dramatically reduced.  On a full-sized Ethernet using
765    the maximum cable lengths allowed and the maximum number of repeaters
766    allowed, an Ethernet frame is vulnerable to collisions during the
767    transmission of its first 256 bits.  On 10 Mb/s Ethernet, this
768    equates to a vulnerable time window of 25.6 microseconds.  On higher-
769    speed variants of Ethernet, the vulnerable time window is shorter.
771    In the case where a Multicast DNS responder has good reason to
772    believe that it will be the only responder on the link that will send
773    a response (i.e., because it is able to answer every question in the
774    query message, and for all of those answer records it has previously
775    verified that the name, rrtype, and rrclass are unique on the link),
776    it SHOULD NOT impose any random delay before responding, and SHOULD
777    normally generate its response within at most 10 ms.  In particular,
778    this applies to responding to probe queries with the unicast-response
779    bit set.  Since receiving a probe query gives a clear indication that
780    some other responder is planning to start using this name in the very
781    near future, answering such probe queries to defend a unique record
782    is a high priority and needs to be done without delay.  A probe query
786 Cheshire & Krochmal          Standards Track                   [Page 14]
788 RFC 6762                      Multicast DNS                February 2013
791    can be distinguished from a normal query by the fact that a probe
792    query contains a proposed record in the Authority Section that
793    answers the question in the Question Section (for more details, see
794    Section 8.2, "Simultaneous Probe Tiebreaking").
796    Responding without delay is appropriate for records like the address
797    record for a particular host name, when the host name has been
798    previously verified unique.  Responding without delay is *not*
799    appropriate for things like looking up PTR records used for DNS-Based
800    Service Discovery [RFC6763], where a large number of responses may be
801    anticipated.
803    In any case where there may be multiple responses, such as queries
804    where the answer is a member of a shared resource record set, each
805    responder SHOULD delay its response by a random amount of time
806    selected with uniform random distribution in the range 20-120 ms.
807    The reason for requiring that the delay be at least 20 ms is to
808    accommodate the situation where two or more query packets are sent
809    back-to-back, because in that case we want a responder with answers
810    to more than one of those queries to have the opportunity to
811    aggregate all of its answers into a single response message.
813    In the case where the query has the TC (truncated) bit set,
814    indicating that subsequent Known-Answer packets will follow,
815    responders SHOULD delay their responses by a random amount of time
816    selected with uniform random distribution in the range 400-500 ms, to
817    allow enough time for all the Known-Answer packets to arrive, as
818    described in Section 7.2, "Multipacket Known-Answer Suppression".
820    The source UDP port in all Multicast DNS responses MUST be 5353 (the
821    well-known port assigned to mDNS).  Multicast DNS implementations
822    MUST silently ignore any Multicast DNS responses they receive where
823    the source UDP port is not 5353.
825    The destination UDP port in all Multicast DNS responses MUST be 5353,
826    and the destination address MUST be the mDNS IPv4 link-local
827    multicast address or its IPv6 equivalent FF02::FB, except
828    when generating a reply to a query that explicitly requested a
829    unicast response:
831       * via the unicast-response bit,
832       * by virtue of being a legacy query (Section 6.7), or
833       * by virtue of being a direct unicast query.
835    Except for these three specific cases, responses MUST NOT be sent via
836    unicast, because then the "Passive Observation of Failures"
837    mechanisms described in Section 10.5 would not work correctly.  Other
842 Cheshire & Krochmal          Standards Track                   [Page 15]
844 RFC 6762                      Multicast DNS                February 2013
847    benefits of sending responses via multicast are discussed in Appendix
848    D.  A Multicast DNS querier MUST only accept unicast responses if
849    they answer a recently sent query (e.g., sent within the last two
850    seconds) that explicitly requested unicast responses.  A Multicast
851    DNS querier MUST silently ignore all other unicast responses.
853    To protect the network against excessive packet flooding due to
854    software bugs or malicious attack, a Multicast DNS responder MUST NOT
855    (except in the one special case of answering probe queries) multicast
856    a record on a given interface until at least one second has elapsed
857    since the last time that record was multicast on that particular
858    interface.  A legitimate querier on the network should have seen the
859    previous transmission and cached it.  A querier that did not receive
860    and cache the previous transmission will retry its request and
861    receive a subsequent response.  In the special case of answering
862    probe queries, because of the limited time before the probing host
863    will make its decision about whether or not to use the name, a
864    Multicast DNS responder MUST respond quickly.  In this special case
865    only, when responding via multicast to a probe, a Multicast DNS
866    responder is only required to delay its transmission as necessary to
867    ensure an interval of at least 250 ms since the last time the record
868    was multicast on that interface.
870 6.1.  Negative Responses
872    In the early design of Multicast DNS it was assumed that explicit
873    negative responses would never be needed.  A host can assert the
874    existence of the set of records that it claims to exist, and the
875    union of all such sets on a link is the set of Multicast DNS records
876    that exist on that link.  Asserting the nonexistence of every record
877    in the complement of that set -- i.e., all possible Multicast DNS
878    records that could exist on this link but do not at this moment --
879    was felt to be impractical and unnecessary.  The nonexistence of a
880    record would be ascertained by a querier querying for it and failing
881    to receive a response from any of the hosts currently attached to the
882    link.
884    However, operational experience showed that explicit negative
885    responses can sometimes be valuable.  One such example is when a
886    querier is querying for a AAAA record, and the host name in question
887    has no associated IPv6 addresses.  In this case, the responding host
888    knows it currently has exclusive ownership of that name, and it knows
889    that it currently does not have any IPv6 addresses, so an explicit
890    negative response is preferable to the querier having to retransmit
891    its query multiple times, and eventually give up with a timeout,
892    before it can conclude that a given AAAA record does not exist.
898 Cheshire & Krochmal          Standards Track                   [Page 16]
900 RFC 6762                      Multicast DNS                February 2013
903    Any time a responder receives a query for a name for which it has
904    verified exclusive ownership, for a type for which that name has no
905    records, the responder MUST (except as allowed in (a) below) respond
906    asserting the nonexistence of that record using a DNS NSEC record
907    [RFC4034].  In the case of Multicast DNS the NSEC record is not being
908    used for its usual DNSSEC [RFC4033] security properties, but simply
909    as a way of expressing which records do or do not exist with a given
910    name.
912    On receipt of a question for a particular name, rrtype, and rrclass,
913    for which a responder does have one or more unique answers, the
914    responder MAY also include an NSEC record in the Additional Record
915    Section indicating the nonexistence of other rrtypes for that name
916    and rrclass.
918    Implementers working with devices with sufficient memory and CPU
919    resources MAY choose to implement code to handle the full generality
920    of the DNS NSEC record [RFC4034], including bitmaps up to 65,536 bits
921    long.  To facilitate use by devices with limited memory and CPU
922    resources, Multicast DNS queriers are only REQUIRED to be able to
923    parse a restricted form of the DNS NSEC record.  All compliant
924    Multicast DNS implementations MUST at least correctly generate and
925    parse the restricted DNS NSEC record format described below:
927       o The 'Next Domain Name' field contains the record's own name.
928         When used with name compression, this means that the 'Next
929         Domain Name' field always takes exactly two bytes in the
930         message.
932       o The Type Bit Map block number is 0.
934       o The Type Bit Map block length byte is a value in the range 1-32.
936       o The Type Bit Map data is 1-32 bytes, as indicated by length
937         byte.
939    Because this restricted form of the DNS NSEC record is limited to
940    Type Bit Map block number zero, it cannot express the existence of
941    rrtypes above 255.  Consequently, if a Multicast DNS responder were
942    to have records with rrtypes above 255, it MUST NOT generate these
943    restricted-form NSEC records for those names, since to do so would
944    imply that the name has no records with rrtypes above 255, which
945    would be false.  In such cases a Multicast DNS responder MUST either
946    (a) emit no NSEC record for that name, or (b) emit a full NSEC record
947    containing the appropriate Type Bit Map block(s) with the correct
948    bits set for all the record types that exist.  In practice this is
949    not a significant limitation, since rrtypes above 255 are not
950    currently in widespread use.
954 Cheshire & Krochmal          Standards Track                   [Page 17]
956 RFC 6762                      Multicast DNS                February 2013
959    If a Multicast DNS implementation receives an NSEC record where the
960    'Next Domain Name' field is not the record's own name, then the
961    implementation SHOULD ignore the 'Next Domain Name' field and process
962    the remainder of the NSEC record as usual.  In Multicast DNS the
963    'Next Domain Name' field is not currently used, but it could be used
964    in a future version of this protocol, which is why a Multicast DNS
965    implementation MUST NOT reject or ignore an NSEC record it receives
966    just because it finds an unexpected value in the 'Next Domain Name'
967    field.
969    If a Multicast DNS implementation receives an NSEC record containing
970    more than one Type Bit Map, or where the Type Bit Map block number is
971    not zero, or where the block length is not in the range 1-32, then
972    the Multicast DNS implementation MAY silently ignore the entire NSEC
973    record.  A Multicast DNS implementation MUST NOT ignore an entire
974    message just because that message contains one or more NSEC record(s)
975    that the Multicast DNS implementation cannot parse.  This provision
976    is to allow future enhancements to the protocol to be introduced in a
977    backwards-compatible way that does not break compatibility with older
978    Multicast DNS implementations.
980    To help differentiate these synthesized NSEC records (generated
981    programmatically on-the-fly) from conventional Unicast DNS NSEC
982    records (which actually exist in a signed DNS zone), the synthesized
983    Multicast DNS NSEC records MUST NOT have the NSEC bit set in the Type
984    Bit Map, whereas conventional Unicast DNS NSEC records do have the
985    NSEC bit set.
987    The TTL of the NSEC record indicates the intended lifetime of the
988    negative cache entry.  In general, the TTL given for an NSEC record
989    SHOULD be the same as the TTL that the record would have had, had it
990    existed.  For example, the TTL for address records in Multicast DNS
991    is typically 120 seconds (see Section 10), so the negative cache
992    lifetime for an address record that does not exist should also be 120
993    seconds.
995    A responder MUST only generate negative responses to queries for
996    which it has legitimate ownership of the name, rrtype, and rrclass in
997    question, and can legitimately assert that no record with that name,
998    rrtype, and rrclass exists.  A responder can assert that a specified
999    rrtype does not exist for one of its names if it knows a priori that
1000    it has exclusive ownership of that name (e.g., names of reverse
1001    address mapping PTR records, which are derived from IP addresses,
1002    which should be unique on the local link) or if it previously claimed
1003    unique ownership of that name using probe queries for rrtype "ANY".
1004    (If it were to use probe queries for a specific rrtype, then it would
1005    only own the name for that rrtype, and could not assert that other
1006    rrtypes do not exist.)
1010 Cheshire & Krochmal          Standards Track                   [Page 18]
1012 RFC 6762                      Multicast DNS                February 2013
1015    The design rationale for this mechanism for encoding negative
1016    responses is discussed further in Appendix E.
1018 6.2.  Responding to Address Queries
1020    When a Multicast DNS responder sends a Multicast DNS response message
1021    containing its own address records, it MUST include all addresses
1022    that are valid on the interface on which it is sending the message,
1023    and MUST NOT include addresses that are not valid on that interface
1024    (such as addresses that may be configured on the host's other
1025    interfaces).  For example, if an interface has both an IPv6 link-
1026    local and an IPv6 routable address, both should be included in the
1027    response message so that queriers receive both and can make their own
1028    choice about which to use.  This allows a querier that only has an
1029    IPv6 link-local address to connect to the link-local address, and a
1030    different querier that has an IPv6 routable address to connect to the
1031    IPv6 routable address instead.
1033    When a Multicast DNS responder places an IPv4 or IPv6 address record
1034    (rrtype "A" or "AAAA") into a response message, it SHOULD also place
1035    any records of the other address type with the same name into the
1036    additional section, if there is space in the message.  This is to
1037    provide fate sharing, so that all a device's addresses are delivered
1038    atomically in a single message, to reduce the risk that packet loss
1039    could cause a querier to receive only the IPv4 addresses and not the
1040    IPv6 addresses, or vice versa.
1042    In the event that a device has only IPv4 addresses but no IPv6
1043    addresses, or vice versa, then the appropriate NSEC record SHOULD be
1044    placed into the additional section, so that queriers can know with
1045    certainty that the device has no addresses of that kind.
1047    Some Multicast DNS responders treat a physical interface with both
1048    IPv4 and IPv6 address as a single interface with two addresses.
1049    Other Multicast DNS responders may treat this case as logically two
1050    interfaces (one with one or more IPv4 addresses, and the other with
1051    one or more IPv6 addresses), but responders that operate this way
1052    MUST NOT put the corresponding automatic NSEC records in replies they
1053    send (i.e., a negative IPv4 assertion in their IPv6 responses, and a
1054    negative IPv6 assertion in their IPv4 responses) because this would
1055    cause incorrect operation in responders on the network that work the
1056    former way.
1058 6.3.  Responding to Multiquestion Queries
1060    Multicast DNS responders MUST correctly handle DNS query messages
1061    containing more than one question, by answering any or all of the
1062    questions to which they have answers.  Unlike single-question
1066 Cheshire & Krochmal          Standards Track                   [Page 19]
1068 RFC 6762                      Multicast DNS                February 2013
1071    queries, where responding without delay is allowed in appropriate
1072    cases, for query messages containing more than one question, all
1073    (non-defensive) answers SHOULD be randomly delayed in the range
1074    20-120 ms, or 400-500 ms if the TC (truncated) bit is set.  This is
1075    because when a query message contains more than one question, a
1076    Multicast DNS responder cannot generally be certain that other
1077    responders will not also be simultaneously generating answers to
1078    other questions in that query message.  (Answers defending a name, in
1079    response to a probe for that name, are not subject to this delay rule
1080    and are still sent immediately.)
1082 6.4.  Response Aggregation
1084    When possible, a responder SHOULD, for the sake of network
1085    efficiency, aggregate as many responses as possible into a single
1086    Multicast DNS response message.  For example, when a responder has
1087    several responses it plans to send, each delayed by a different
1088    interval, then earlier responses SHOULD be delayed by up to an
1089    additional 500 ms if that will permit them to be aggregated with
1090    other responses scheduled to go out a little later.
1092 6.5.  Wildcard Queries (qtype "ANY" and qclass "ANY")
1094    When responding to queries using qtype "ANY" (255) and/or qclass
1095    "ANY" (255), a Multicast DNS responder MUST respond with *ALL* of its
1096    records that match the query.  This is subtly different from how
1097    qtype "ANY" and qclass "ANY" work in Unicast DNS.
1099    A common misconception is that a Unicast DNS query for qtype "ANY"
1100    will elicit a response containing all matching records.  This is
1101    incorrect.  If there are any records that match the query, the
1102    response is required only to contain at least one of them, not
1103    necessarily all of them.
1105    This somewhat surprising behavior is commonly seen with caching
1106    (i.e., "recursive") name servers.  If a caching server receives a
1107    qtype "ANY" query for which it has at least one valid answer, it is
1108    allowed to return only those matching answers it happens to have
1109    already in its cache, and it is not required to reconsult the
1110    authoritative name server to check if there are any more records that
1111    also match the qtype "ANY" query.
1113    For example, one might imagine that a query for qtype "ANY" for name
1114    "host.example.com" would return both the IPv4 (A) and the IPv6 (AAAA)
1115    address records for that host.  In reality, what happens is that it
1116    depends on the history of what queries have been previously received
1117    by intervening caching servers.  If a caching server has no records
1118    for "host.example.com", then it will consult another server (usually
1122 Cheshire & Krochmal          Standards Track                   [Page 20]
1124 RFC 6762                      Multicast DNS                February 2013
1127    the authoritative name server for the name in question), and, in that
1128    case, it will typically return all IPv4 and IPv6 address records.
1129    However, if some other host has recently done a query for qtype "A"
1130    for name "host.example.com", so that the caching server already has
1131    IPv4 address records for "host.example.com" in its cache but no IPv6
1132    address records, then it will return only the IPv4 address records it
1133    already has cached, and no IPv6 address records.
1135    Multicast DNS does not share this property that qtype "ANY" and
1136    qclass "ANY" queries return some undefined subset of the matching
1137    records.  When responding to queries using qtype "ANY" (255) and/or
1138    qclass "ANY" (255), a Multicast DNS responder MUST respond with *ALL*
1139    of its records that match the query.
1141 6.6.  Cooperating Multicast DNS Responders
1143    If a Multicast DNS responder ("A") observes some other Multicast DNS
1144    responder ("B") send a Multicast DNS response message containing a
1145    resource record with the same name, rrtype, and rrclass as one of A's
1146    resource records, but *different* rdata, then:
1148       o If A's resource record is intended to be a shared resource
1149         record, then this is no conflict, and no action is required.
1151       o If A's resource record is intended to be a member of a unique
1152         resource record set owned solely by that responder, then this is
1153         a conflict and MUST be handled as described in Section 9,
1154         "Conflict Resolution".
1156    If a Multicast DNS responder ("A") observes some other Multicast DNS
1157    responder ("B") send a Multicast DNS response message containing a
1158    resource record with the same name, rrtype, and rrclass as one of A's
1159    resource records, and *identical* rdata, then:
1161       o If the TTL of B's resource record given in the message is at
1162         least half the true TTL from A's point of view, then no action
1163         is required.
1165       o If the TTL of B's resource record given in the message is less
1166         than half the true TTL from A's point of view, then A MUST mark
1167         its record to be announced via multicast.  Queriers receiving
1168         the record from B would use the TTL given by B and, hence, may
1169         delete the record sooner than A expects.  By sending its own
1170         multicast response correcting the TTL, A ensures that the record
1171         will be retained for the desired time.
1178 Cheshire & Krochmal          Standards Track                   [Page 21]
1180 RFC 6762                      Multicast DNS                February 2013
1183    These rules allow multiple Multicast DNS responders to offer the same
1184    data on the network (perhaps for fault-tolerance reasons) without
1185    conflicting with each other.
1187 6.7.  Legacy Unicast Responses
1189    If the source UDP port in a received Multicast DNS query is not port
1190    5353, this indicates that the querier originating the query is a
1191    simple resolver such as described in Section 5.1, "One-Shot Multicast
1192    DNS Queries", which does not fully implement all of Multicast DNS.
1193    In this case, the Multicast DNS responder MUST send a UDP response
1194    directly back to the querier, via unicast, to the query packet's
1195    source IP address and port.  This unicast response MUST be a
1196    conventional unicast response as would be generated by a conventional
1197    Unicast DNS server; for example, it MUST repeat the query ID and the
1198    question given in the query message.  In addition, the cache-flush
1199    bit described in Section 10.2, "Announcements to Flush Outdated Cache
1200    Entries", MUST NOT be set in legacy unicast responses.
1202    The resource record TTL given in a legacy unicast response SHOULD NOT
1203    be greater than ten seconds, even if the true TTL of the Multicast
1204    DNS resource record is higher.  This is because Multicast DNS
1205    responders that fully participate in the protocol use the cache
1206    coherency mechanisms described in Section 10, "Resource Record TTL
1207    Values and Cache Coherency", to update and invalidate stale data.
1208    Were unicast responses sent to legacy resolvers to use the same high
1209    TTLs, these legacy resolvers, which do not implement these cache
1210    coherency mechanisms, could retain stale cached resource record data
1211    long after it is no longer valid.
1213 7.  Traffic Reduction
1215    A variety of techniques are used to reduce the amount of traffic on
1216    the network.
1218 7.1.  Known-Answer Suppression
1220    When a Multicast DNS querier sends a query to which it already knows
1221    some answers, it populates the Answer Section of the DNS query
1222    message with those answers.
1224    Generally, this applies only to Shared records, not Unique records,
1225    since if a Multicast DNS querier already has at least one Unique
1226    record in its cache then it should not be expecting further different
1227    answers to this question, since the Unique record(s) it already has
1228    comprise the complete answer, so it has no reason to be sending the
1229    query at all.  In contrast, having some Shared records in its cache
1230    does not necessarily imply that a Multicast DNS querier will not
1234 Cheshire & Krochmal          Standards Track                   [Page 22]
1236 RFC 6762                      Multicast DNS                February 2013
1239    receive further answers to this query, and it is in this case that it
1240    is beneficial to use the Known-Answer list to suppress repeated
1241    sending of redundant answers that the querier already knows.
1243    A Multicast DNS responder MUST NOT answer a Multicast DNS query if
1244    the answer it would give is already included in the Answer Section
1245    with an RR TTL at least half the correct value.  If the RR TTL of the
1246    answer as given in the Answer Section is less than half of the true
1247    RR TTL as known by the Multicast DNS responder, the responder MUST
1248    send an answer so as to update the querier's cache before the record
1249    becomes in danger of expiration.
1251    Because a Multicast DNS responder will respond if the remaining TTL
1252    given in the Known-Answer list is less than half the true TTL, it is
1253    superfluous for the querier to include such records in the Known-
1254    Answer list.  Therefore, a Multicast DNS querier SHOULD NOT include
1255    records in the Known-Answer list whose remaining TTL is less than
1256    half of their original TTL.  Doing so would simply consume space in
1257    the message without achieving the goal of suppressing responses and
1258    would, therefore, be a pointless waste of network capacity.
1260    A Multicast DNS querier MUST NOT cache resource records observed in
1261    the Known-Answer Section of other Multicast DNS queries.  The Answer
1262    Section of Multicast DNS queries is not authoritative.  By placing
1263    information in the Answer Section of a Multicast DNS query, the
1264    querier is stating that it *believes* the information to be true.  It
1265    is not asserting that the information *is* true.  Some of those
1266    records may have come from other hosts that are no longer on the
1267    network.  Propagating that stale information to other Multicast DNS
1268    queriers on the network would not be helpful.
1270 7.2.  Multipacket Known-Answer Suppression
1272    Sometimes a Multicast DNS querier will already have too many answers
1273    to fit in the Known-Answer Section of its query packets.  In this
1274    case, it should issue a Multicast DNS query containing a question and
1275    as many Known-Answer records as will fit.  It MUST then set the TC
1276    (Truncated) bit in the header before sending the query.  It MUST
1277    immediately follow the packet with another query packet containing no
1278    questions and as many more Known-Answer records as will fit.  If
1279    there are still too many records remaining to fit in the packet, it
1280    again sets the TC bit and continues until all the Known-Answer
1281    records have been sent.
1283    A Multicast DNS responder seeing a Multicast DNS query with the TC
1284    bit set defers its response for a time period randomly selected in
1285    the interval 400-500 ms.  This gives the Multicast DNS querier time
1286    to send additional Known-Answer packets before the responder
1290 Cheshire & Krochmal          Standards Track                   [Page 23]
1292 RFC 6762                      Multicast DNS                February 2013
1295    responds.  If the responder sees any of its answers listed in the
1296    Known-Answer lists of subsequent packets from the querying host, it
1297    MUST delete that answer from the list of answers it is planning to
1298    give (provided that no other host on the network has also issued a
1299    query for that record and is waiting to receive an answer).
1301    If the responder receives additional Known-Answer packets with the TC
1302    bit set, it SHOULD extend the delay as necessary to ensure a pause of
1303    400-500 ms after the last such packet before it sends its answer.
1304    This opens the potential risk that a continuous stream of Known-
1305    Answer packets could, theoretically, prevent a responder from
1306    answering indefinitely.  In practice, answers are never actually
1307    delayed significantly, and should a situation arise where significant
1308    delays did happen, that would be a scenario where the network is so
1309    overloaded that it would be desirable to err on the side of caution.
1310    The consequence of delaying an answer may be that it takes a user
1311    longer than usual to discover all the services on the local network;
1312    in contrast, the consequence of incorrectly answering before all the
1313    Known-Answer packets have been received would be wasted capacity
1314    sending unnecessary answers on an already overloaded network.  In
1315    this (rare) situation, sacrificing speed to preserve reliable network
1316    operation is the right trade-off.
1318 7.3.  Duplicate Question Suppression
1320    If a host is planning to transmit (or retransmit) a query, and it
1321    sees another host on the network send a query containing the same
1322    "QM" question, and the Known-Answer Section of that query does not
1323    contain any records that this host would not also put in its own
1324    Known-Answer Section, then this host SHOULD treat its own query as
1325    having been sent.  When multiple queriers on the network are querying
1326    for the same resource records, there is no need for them to all be
1327    repeatedly asking the same question.
1329 7.4.  Duplicate Answer Suppression
1331    If a host is planning to send an answer, and it sees another host on
1332    the network send a response message containing the same answer
1333    record, and the TTL in that record is not less than the TTL this host
1334    would have given, then this host SHOULD treat its own answer as
1335    having been sent, and not also send an identical answer itself.  When
1336    multiple responders on the network have the same data, there is no
1337    need for all of them to respond.
1346 Cheshire & Krochmal          Standards Track                   [Page 24]
1348 RFC 6762                      Multicast DNS                February 2013
1351    The opportunity for duplicate answer suppression occurs when a host
1352    has received a query, and is delaying its response for some pseudo-
1353    random interval up to 500 ms, as described elsewhere in this
1354    document, and then, before the host sends its response, it sees some
1355    other host on the network send a response message containing the same
1356    answer record.
1358    This feature is particularly useful when Multicast DNS Proxy Servers
1359    are in use, where there could be more than one proxy on the network
1360    giving Multicast DNS answers on behalf of some other host (e.g.,
1361    because that other host is currently asleep and is not itself
1362    responding to queries).
1364 8.  Probing and Announcing on Startup
1366    Typically a Multicast DNS responder should have, at the very least,
1367    address records for all of its active interfaces.  Creating and
1368    advertising an HINFO record on each interface as well can be useful
1369    to network administrators.
1371    Whenever a Multicast DNS responder starts up, wakes up from sleep,
1372    receives an indication of a network interface "Link Change" event, or
1373    has any other reason to believe that its network connectivity may
1374    have changed in some relevant way, it MUST perform the two startup
1375    steps below: Probing (Section 8.1) and Announcing (Section 8.3).
1377 8.1.  Probing
1379    The first startup step is that, for all those resource records that a
1380    Multicast DNS responder desires to be unique on the local link, it
1381    MUST send a Multicast DNS query asking for those resource records, to
1382    see if any of them are already in use.  The primary example of this
1383    is a host's address records, which map its unique host name to its
1384    unique IPv4 and/or IPv6 addresses.  All probe queries SHOULD be done
1385    using the desired resource record name and class (usually class 1,
1386    "Internet"), and query type "ANY" (255), to elicit answers for all
1387    types of records with that name.  This allows a single question to be
1388    used in place of several questions, which is more efficient on the
1389    network.  It also allows a host to verify exclusive ownership of a
1390    name for all rrtypes, which is desirable in most cases.  It would be
1391    confusing, for example, if one host owned the "A" record for
1392    "myhost.local.", but a different host owned the "AAAA" record for
1393    that name.
1402 Cheshire & Krochmal          Standards Track                   [Page 25]
1404 RFC 6762                      Multicast DNS                February 2013
1407    The ability to place more than one question in a Multicast DNS query
1408    is useful here, because it can allow a host to use a single message
1409    to probe for all of its resource records instead of needing a
1410    separate message for each.  For example, a host can simultaneously
1411    probe for uniqueness of its "A" record and all its SRV records
1412    [RFC6763] in the same query message.
1414    When ready to send its Multicast DNS probe packet(s) the host should
1415    first wait for a short random delay time, uniformly distributed in
1416    the range 0-250 ms.  This random delay is to guard against the case
1417    where several devices are powered on simultaneously, or several
1418    devices are connected to an Ethernet hub, which is then powered on,
1419    or some other external event happens that might cause a group of
1420    hosts to all send synchronized probes.
1422    250 ms after the first query, the host should send a second; then,
1423    250 ms after that, a third.  If, by 250 ms after the third probe, no
1424    conflicting Multicast DNS responses have been received, the host may
1425    move to the next step, announcing.  (Note that probing is the one
1426    exception from the normal rule that there should be at least one
1427    second between repetitions of the same question, and the interval
1428    between subsequent repetitions should at least double.)
1430    When sending probe queries, a host MUST NOT consult its cache for
1431    potential answers.  Only conflicting Multicast DNS responses received
1432    "live" from the network are considered valid for the purposes of
1433    determining whether probing has succeeded or failed.
1435    In order to allow services to announce their presence without
1436    unreasonable delay, the time window for probing is intentionally set
1437    quite short.  As a result of this, from the time the first probe
1438    packet is sent, another device on the network using that name has
1439    just 750 ms to respond to defend its name.  On networks that are
1440    slow, or busy, or both, it is possible for round-trip latency to
1441    account for a few hundred milliseconds, and software delays in slow
1442    devices can add additional delay.  Hence, it is important that when a
1443    device receives a probe query for a name that it is currently using,
1444    it SHOULD generate its response to defend that name immediately and
1445    send it as quickly as possible.  The usual rules about random delays
1446    before responding, to avoid sudden bursts of simultaneous answers
1447    from different hosts, do not apply here since normally at most one
1448    host should ever respond to a given probe question.  Even when a
1449    single DNS query message contains multiple probe questions, it would
1450    be unusual for that message to elicit a defensive response from more
1451    than one other host.  Because of the mDNS multicast rate-limiting
1458 Cheshire & Krochmal          Standards Track                   [Page 26]
1460 RFC 6762                      Multicast DNS                February 2013
1463    rules, the probes SHOULD be sent as "QU" questions with the unicast-
1464    response bit set, to allow a defending host to respond immediately
1465    via unicast, instead of potentially having to wait before replying
1466    via multicast.
1468    During probing, from the time the first probe packet is sent until
1469    250 ms after the third probe, if any conflicting Multicast DNS
1470    response is received, then the probing host MUST defer to the
1471    existing host, and SHOULD choose new names for some or all of its
1472    resource records as appropriate.  Apparently conflicting Multicast
1473    DNS responses received *before* the first probe packet is sent MUST
1474    be silently ignored (see discussion of stale probe packets in Section
1475    8.2, "Simultaneous Probe Tiebreaking", below).  In the case of a host
1476    probing using query type "ANY" as recommended above, any answer
1477    containing a record with that name, of any type, MUST be considered a
1478    conflicting response and handled accordingly.
1480    If fifteen conflicts occur within any ten-second period, then the
1481    host MUST wait at least five seconds before each successive
1482    additional probe attempt.  This is to help ensure that, in the event
1483    of software bugs or other unanticipated problems, errant hosts do not
1484    flood the network with a continuous stream of multicast traffic.  For
1485    very simple devices, a valid way to comply with this requirement is
1486    to always wait five seconds after any failed probe attempt before
1487    trying again.
1489    If a responder knows by other means that its unique resource record
1490    set name, rrtype, and rrclass cannot already be in use by any other
1491    responder on the network, then it SHOULD skip the probing step for
1492    that resource record set.  For example, when creating the reverse
1493    address mapping PTR records, the host can reasonably assume that no
1494    other host will be trying to create those same PTR records, since
1495    that would imply that the two hosts were trying to use the same IP
1496    address, and if that were the case, the two hosts would be suffering
1497    communication problems beyond the scope of what Multicast DNS is
1498    designed to solve.  Similarly, if a responder is acting as a proxy,
1499    taking over from another Multicast DNS responder that has already
1500    verified the uniqueness of the record, then the proxy SHOULD NOT
1501    repeat the probing step for those records.
1503 8.2.  Simultaneous Probe Tiebreaking
1505    The astute reader will observe that there is a race condition
1506    inherent in the previous description.  If two hosts are probing for
1507    the same name simultaneously, neither will receive any response to
1508    the probe, and the hosts could incorrectly conclude that they may
1509    both proceed to use the name.  To break this symmetry, each host
1510    populates the query message's Authority Section with the record or
1514 Cheshire & Krochmal          Standards Track                   [Page 27]
1516 RFC 6762                      Multicast DNS                February 2013
1519    records with the rdata that it would be proposing to use, should its
1520    probing be successful.  The Authority Section is being used here in a
1521    way analogous to the way it is used as the "Update Section" in a DNS
1522    Update message [RFC2136] [RFC3007].
1524    When a host is probing for a group of related records with the same
1525    name (e.g., the SRV and TXT record describing a DNS-SD service), only
1526    a single question need be placed in the Question Section, since query
1527    type "ANY" (255) is used, which will elicit answers for all records
1528    with that name.  However, for tiebreaking to work correctly in all
1529    cases, the Authority Section must contain *all* the records and
1530    proposed rdata being probed for uniqueness.
1532    When a host that is probing for a record sees another host issue a
1533    query for the same record, it consults the Authority Section of that
1534    query.  If it finds any resource record(s) there which answers the
1535    query, then it compares the data of that (those) resource record(s)
1536    with its own tentative data.  We consider first the simple case of a
1537    host probing for a single record, receiving a simultaneous probe from
1538    another host also probing for a single record.  The two records are
1539    compared and the lexicographically later data wins.  This means that
1540    if the host finds that its own data is lexicographically later, it
1541    simply ignores the other host's probe.  If the host finds that its
1542    own data is lexicographically earlier, then it defers to the winning
1543    host by waiting one second, and then begins probing for this record
1544    again.  The logic for waiting one second and then trying again is to
1545    guard against stale probe packets on the network (possibly even stale
1546    probe packets sent moments ago by this host itself, before some
1547    configuration change, which may be echoed back after a short delay by
1548    some Ethernet switches and some 802.11 base stations).  If the
1549    winning simultaneous probe was from a real other host on the network,
1550    then after one second it will have completed its probing, and will
1551    answer subsequent probes.  If the apparently winning simultaneous
1552    probe was in fact just an old stale packet on the network (maybe from
1553    the host itself), then when it retries its probing in one second, its
1554    probes will go unanswered, and it will successfully claim the name.
1556    The determination of "lexicographically later" is performed by first
1557    comparing the record class (excluding the cache-flush bit described
1558    in Section 10.2), then the record type, then raw comparison of the
1559    binary content of the rdata without regard for meaning or structure.
1560    If the record classes differ, then the numerically greater class is
1561    considered "lexicographically later".  Otherwise, if the record types
1562    differ, then the numerically greater type is considered
1563    "lexicographically later".  If the rrtype and rrclass both match,
1564    then the rdata is compared.
1570 Cheshire & Krochmal          Standards Track                   [Page 28]
1572 RFC 6762                      Multicast DNS                February 2013
1575    In the case of resource records containing rdata that is subject to
1576    name compression [RFC1035], the names MUST be uncompressed before
1577    comparison.  (The details of how a particular name is compressed is
1578    an artifact of how and where the record is written into the DNS
1579    message; it is not an intrinsic property of the resource record
1580    itself.)
1582    The bytes of the raw uncompressed rdata are compared in turn,
1583    interpreting the bytes as eight-bit UNSIGNED values, until a byte is
1584    found whose value is greater than that of its counterpart (in which
1585    case, the rdata whose byte has the greater value is deemed
1586    lexicographically later) or one of the resource records runs out of
1587    rdata (in which case, the resource record which still has remaining
1588    data first is deemed lexicographically later).  The following is an
1589    example of a conflict:
1591      MyPrinter.local. A
1592      MyPrinter.local. A
1594    In this case, is lexicographically later (the third
1595    byte, with value 200, is greater than its counterpart with value 99),
1596    so it is deemed the winner.
1598    Note that it is vital that the bytes are interpreted as UNSIGNED
1599    values in the range 0-255, or the wrong outcome may result.  In the
1600    example above, if the byte with value 200 had been incorrectly
1601    interpreted as a signed eight-bit value, then it would be interpreted
1602    as value -56, and the wrong address record would be deemed the
1603    winner.
1605 8.2.1.  Simultaneous Probe Tiebreaking for Multiple Records
1607    When a host is probing for a set of records with the same name, or a
1608    message is received containing multiple tiebreaker records answering
1609    a given probe question in the Question Section, the host's records
1610    and the tiebreaker records from the message are each sorted into
1611    order, and then compared pairwise, using the same comparison
1612    technique described above, until a difference is found.
1614    The records are sorted using the same lexicographical order as
1615    described above, that is, if the record classes differ, the record
1616    with the lower class number comes first.  If the classes are the same
1617    but the rrtypes differ, the record with the lower rrtype number comes
1618    first.  If the class and rrtype match, then the rdata is compared
1619    bytewise until a difference is found.  For example, in the common
1620    case of advertising DNS-SD services with a TXT record and an SRV
1621    record, the TXT record comes first (the rrtype value for TXT is 16)
1622    and the SRV record comes second (the rrtype value for SRV is 33).
1626 Cheshire & Krochmal          Standards Track                   [Page 29]
1628 RFC 6762                      Multicast DNS                February 2013
1631    When comparing the records, if the first records match perfectly,
1632    then the second records are compared, and so on.  If either list of
1633    records runs out of records before any difference is found, then the
1634    list with records remaining is deemed to have won the tiebreak.  If
1635    both lists run out of records at the same time without any difference
1636    being found, then this indicates that two devices are advertising
1637    identical sets of records, as is sometimes done for fault tolerance,
1638    and there is, in fact, no conflict.
1640 8.3.  Announcing
1642    The second startup step is that the Multicast DNS responder MUST send
1643    an unsolicited Multicast DNS response containing, in the Answer
1644    Section, all of its newly registered resource records (both shared
1645    records, and unique records that have completed the probing step).
1646    If there are too many resource records to fit in a single packet,
1647    multiple packets should be used.
1649    In the case of shared records (e.g., the PTR records used by DNS-
1650    Based Service Discovery [RFC6763]), the records are simply placed as
1651    is into the Answer Section of the DNS response.
1653    In the case of records that have been verified to be unique in the
1654    previous step, they are placed into the Answer Section of the DNS
1655    response with the most significant bit of the rrclass set to one.
1656    The most significant bit of the rrclass for a record in the Answer
1657    Section of a response message is the Multicast DNS cache-flush bit
1658    and is discussed in more detail below in Section 10.2, "Announcements
1659    to Flush Outdated Cache Entries".
1661    The Multicast DNS responder MUST send at least two unsolicited
1662    responses, one second apart.  To provide increased robustness against
1663    packet loss, a responder MAY send up to eight unsolicited responses,
1664    provided that the interval between unsolicited responses increases by
1665    at least a factor of two with every response sent.
1667    A Multicast DNS responder MUST NOT send announcements in the absence
1668    of information that its network connectivity may have changed in some
1669    relevant way.  In particular, a Multicast DNS responder MUST NOT send
1670    regular periodic announcements as a matter of course.
1672    Whenever a Multicast DNS responder receives any Multicast DNS
1673    response (solicited or otherwise) containing a conflicting resource
1674    record, the conflict MUST be resolved as described in Section 9,
1675    "Conflict Resolution".
1682 Cheshire & Krochmal          Standards Track                   [Page 30]
1684 RFC 6762                      Multicast DNS                February 2013
1687 8.4.  Updating
1689    At any time, if the rdata of any of a host's Multicast DNS records
1690    changes, the host MUST repeat the Announcing step described above to
1691    update neighboring caches.  For example, if any of a host's IP
1692    addresses change, it MUST re-announce those address records.  The
1693    host does not need to repeat the Probing step because it has already
1694    established unique ownership of that name.
1696    In the case of shared records, a host MUST send a "goodbye"
1697    announcement with RR TTL zero (see Section 10.1, "Goodbye Packets")
1698    for the old rdata, to cause it to be deleted from peer caches, before
1699    announcing the new rdata.  In the case of unique records, a host
1700    SHOULD omit the "goodbye" announcement, since the cache-flush bit on
1701    the newly announced records will cause old rdata to be flushed from
1702    peer caches anyway.
1704    A host may update the contents of any of its records at any time,
1705    though a host SHOULD NOT update records more frequently than ten
1706    times per minute.  Frequent rapid updates impose a burden on the
1707    network.  If a host has information to disseminate which changes more
1708    frequently than ten times per minute, then it may be more appropriate
1709    to design a protocol for that specific purpose.
1711 9.  Conflict Resolution
1713    A conflict occurs when a Multicast DNS responder has a unique record
1714    for which it is currently authoritative, and it receives a Multicast
1715    DNS response message containing a record with the same name, rrtype
1716    and rrclass, but inconsistent rdata.  What may be considered
1717    inconsistent is context sensitive, except that resource records with
1718    identical rdata are never considered inconsistent, even if they
1719    originate from different hosts.  This is to permit use of proxies and
1720    other fault-tolerance mechanisms that may cause more than one
1721    responder to be capable of issuing identical answers on the network.
1723    A common example of a resource record type that is intended to be
1724    unique, not shared between hosts, is the address record that maps a
1725    host's name to its IP address.  Should a host witness another host
1726    announce an address record with the same name but a different IP
1727    address, then that is considered inconsistent, and that address
1728    record is considered to be in conflict.
1730    Whenever a Multicast DNS responder receives any Multicast DNS
1731    response (solicited or otherwise) containing a conflicting resource
1732    record in any of the Resource Record Sections, the Multicast DNS
1733    responder MUST immediately reset its conflicted unique record to
1734    probing state, and go through the startup steps described above in
1738 Cheshire & Krochmal          Standards Track                   [Page 31]
1740 RFC 6762                      Multicast DNS                February 2013
1743    Section 8, "Probing and Announcing on Startup".  The protocol used in
1744    the Probing phase will determine a winner and a loser, and the loser
1745    MUST cease using the name, and reconfigure.
1747    It is very important that any host receiving a resource record that
1748    conflicts with one of its own MUST take action as described above.
1749    In the case of two hosts using the same host name, where one has been
1750    configured to require a unique host name and the other has not, the
1751    one that has not been configured to require a unique host name will
1752    not perceive any conflict, and will not take any action.  By
1753    reverting to Probing state, the host that desires a unique host name
1754    will go through the necessary steps to ensure that a unique host name
1755    is obtained.
1757    The recommended course of action after probing and failing is as
1758    follows:
1760       1. Programmatically change the resource record name in an attempt
1761          to find a new name that is unique.  This could be done by
1762          adding some further identifying information (e.g., the model
1763          name of the hardware) if it is not already present in the name,
1764          or appending the digit "2" to the name, or incrementing a
1765          number at the end of the name if one is already present.
1767       2. Probe again, and repeat as necessary until a unique name is
1768          found.
1770       3. Once an available unique name has been determined, by probing
1771          without receiving any conflicting response, record this newly
1772          chosen name in persistent storage so that the device will use
1773          the same name the next time it is power-cycled.
1775       4. Display a message to the user or operator informing them of the
1776          name change.  For example:
1778             The name "Bob's Music" is in use by another music server on
1779             the network.  Your music collection has been renamed to
1780             "Bob's Music (2)".  If you want to change this name, use
1781             [describe appropriate menu item or preference dialog here].
1783          The details of how the user or operator is informed of the new
1784          name depends on context.  A desktop computer with a screen
1785          might put up a dialog box.  A headless server in the closet may
1786          write a message to a log file, or use whatever mechanism
1787          (email, SNMP trap, etc.) it uses to inform the administrator of
1788          error conditions.  On the other hand, a headless server in the
1789          closet may not inform the user at all -- if the user cares,
1794 Cheshire & Krochmal          Standards Track                   [Page 32]
1796 RFC 6762                      Multicast DNS                February 2013
1799          they will notice the name has changed, and connect to the
1800          server in the usual way (e.g., via web browser) to configure a
1801          new name.
1803       5. After one minute of probing, if the Multicast DNS responder has
1804          been unable to find any unused name, it should log an error
1805          message to inform the user or operator of this fact.  This
1806          situation should never occur in normal operation.  The only
1807          situations that would cause this to happen would be either a
1808          deliberate denial-of-service attack, or some kind of very
1809          obscure hardware or software bug that acts like a deliberate
1810          denial-of-service attack.
1812    These considerations apply to address records (i.e., host names) and
1813    to all resource records where uniqueness (or maintenance of some
1814    other defined constraint) is desired.
1816 10.  Resource Record TTL Values and Cache Coherency
1818    As a general rule, the recommended TTL value for Multicast DNS
1819    resource records with a host name as the resource record's name
1820    (e.g., A, AAAA, HINFO) or a host name contained within the resource
1821    record's rdata (e.g., SRV, reverse mapping PTR record) SHOULD be 120
1822    seconds.
1824    The recommended TTL value for other Multicast DNS resource records is
1825    75 minutes.
1827    A querier with an active outstanding query will issue a query message
1828    when one or more of the resource records in its cache are 80% of the
1829    way to expiry.  If the TTL on those records is 75 minutes, this
1830    ongoing cache maintenance process yields a steady-state query rate of
1831    one query every 60 minutes.
1833    Any distributed cache needs a cache coherency protocol.  If Multicast
1834    DNS resource records follow the recommendation and have a TTL of 75
1835    minutes, that means that stale data could persist in the system for a
1836    little over an hour.  Making the default RR TTL significantly lower
1837    would reduce the lifetime of stale data, but would produce too much
1838    extra traffic on the network.  Various techniques are available to
1839    minimize the impact of such stale data, outlined in the five
1840    subsections below.
1842 10.1.  Goodbye Packets
1844    In the case where a host knows that certain resource record data is
1845    about to become invalid (for example, when the host is undergoing a
1846    clean shutdown), the host SHOULD send an unsolicited Multicast DNS
1850 Cheshire & Krochmal          Standards Track                   [Page 33]
1852 RFC 6762                      Multicast DNS                February 2013
1855    response packet, giving the same resource record name, rrtype,
1856    rrclass, and rdata, but an RR TTL of zero.  This has the effect of
1857    updating the TTL stored in neighboring hosts' cache entries to zero,
1858    causing that cache entry to be promptly deleted.
1860    Queriers receiving a Multicast DNS response with a TTL of zero SHOULD
1861    NOT immediately delete the record from the cache, but instead record
1862    a TTL of 1 and then delete the record one second later.  In the case
1863    of multiple Multicast DNS responders on the network described in
1864    Section 6.6 above, if one of the responders shuts down and
1865    incorrectly sends goodbye packets for its records, it gives the other
1866    cooperating responders one second to send out their own response to
1867    "rescue" the records before they expire and are deleted.
1869 10.2.  Announcements to Flush Outdated Cache Entries
1871    Whenever a host has a resource record with new data, or with what
1872    might potentially be new data (e.g., after rebooting, waking from
1873    sleep, connecting to a new network link, or changing IP address), the
1874    host needs to inform peers of that new data.  In cases where the host
1875    has not been continuously connected and participating on the network
1876    link, it MUST first probe to re-verify uniqueness of its unique
1877    records, as described above in Section 8.1, "Probing".
1879    Having completed the Probing step, if necessary, the host MUST then
1880    send a series of unsolicited announcements to update cache entries in
1881    its neighbor hosts.  In these unsolicited announcements, if the
1882    record is one that has been verified unique, the host sets the most
1883    significant bit of the rrclass field of the resource record.  This
1884    bit, the cache-flush bit, tells neighboring hosts that this is not a
1885    shared record type.  Instead of merging this new record additively
1886    into the cache in addition to any previous records with the same
1887    name, rrtype, and rrclass, all old records with that name, rrtype,
1888    and rrclass that were received more than one second ago are declared
1889    invalid, and marked to expire from the cache in one second.
1891    The semantics of the cache-flush bit are as follows: normally when a
1892    resource record appears in a Resource Record Section of the DNS
1893    response it means, "This is an assertion that this information is
1894    true".  When a resource record appears in a Resource Record Section
1895    of the DNS response with the cache-flush bit set, it means, "This is
1896    an assertion that this information is the truth and the whole truth,
1897    and anything you may have heard more than a second ago regarding
1898    records of this name/rrtype/rrclass is no longer true".
1900    To accommodate the case where the set of records from one host
1901    constituting a single unique RRSet is too large to fit in a single
1902    packet, only cache records that are more than one second old are
1906 Cheshire & Krochmal          Standards Track                   [Page 34]
1908 RFC 6762                      Multicast DNS                February 2013
1911    flushed.  This allows the announcing host to generate a quick burst
1912    of packets back-to-back on the wire containing all the members of the
1913    RRSet.  When receiving records with the cache-flush bit set, all
1914    records older than one second are marked to be deleted one second in
1915    the future.  One second after the end of the little packet burst, any
1916    records not represented within that packet burst will then be expired
1917    from all peer caches.
1919    Any time a host sends a response packet containing some members of a
1920    unique RRSet, it MUST send the entire RRSet, preferably in a single
1921    packet, or if the entire RRSet will not fit in a single packet, in a
1922    quick burst of packets sent as close together as possible.  The host
1923    MUST set the cache-flush bit on all members of the unique RRSet.
1925    Another reason for waiting one second before deleting stale records
1926    from the cache is to accommodate bridged networks.  For example, a
1927    host's address record announcement on a wireless interface may be
1928    bridged onto a wired Ethernet and may cause that same host's Ethernet
1929    address records to be flushed from peer caches.  The one-second delay
1930    gives the host the chance to see its own announcement arrive on the
1931    wired Ethernet, and immediately re-announce its Ethernet interface's
1932    address records so that both sets remain valid and live in peer
1933    caches.
1935    These rules, about when to set the cache-flush bit and about sending
1936    the entire rrset, apply regardless of *why* the response message is
1937    being generated.  They apply to startup announcements as described in
1938    Section 8.3, "Announcing", and to responses generated as a result of
1939    receiving query messages.
1941    The cache-flush bit is only set in records in the Resource Record
1942    Sections of Multicast DNS responses sent to UDP port 5353.
1944    The cache-flush bit MUST NOT be set in any resource records in a
1945    response message sent in legacy unicast responses to UDP ports other
1946    than 5353.
1948    The cache-flush bit MUST NOT be set in any resource records in the
1949    Known-Answer list of any query message.
1951    The cache-flush bit MUST NOT ever be set in any shared resource
1952    record.  To do so would cause all the other shared versions of this
1953    resource record with different rdata from different responders to be
1954    immediately deleted from all the caches on the network.
1962 Cheshire & Krochmal          Standards Track                   [Page 35]
1964 RFC 6762                      Multicast DNS                February 2013
1967    The cache-flush bit does *not* apply to questions listed in the
1968    Question Section of a Multicast DNS message.  The top bit of the
1969    rrclass field in questions is used for an entirely different purpose
1970    (see Section 5.4, "Questions Requesting Unicast Responses").
1972    Note that the cache-flush bit is NOT part of the resource record
1973    class.  The cache-flush bit is the most significant bit of the second
1974    16-bit word of a resource record in a Resource Record Section of a
1975    Multicast DNS message (the field conventionally referred to as the
1976    rrclass field), and the actual resource record class is the least
1977    significant fifteen bits of this field.  There is no Multicast DNS
1978    resource record class 0x8001.  The value 0x8001 in the rrclass field
1979    of a resource record in a Multicast DNS response message indicates a
1980    resource record with class 1, with the cache-flush bit set.  When
1981    receiving a resource record with the cache-flush bit set,
1982    implementations should take care to mask off that bit before storing
1983    the resource record in memory, or otherwise ensure that it is given
1984    the correct semantic interpretation.
1986    The reuse of the top bit of the rrclass field only applies to
1987    conventional resource record types that are subject to caching, not
1988    to pseudo-RRs like OPT [RFC2671], TSIG [RFC2845], TKEY [RFC2930],
1989    SIG0 [RFC2931], etc., that pertain only to a particular transport
1990    level message and not to any actual DNS data.  Since pseudo-RRs
1991    should never go into the Multicast DNS cache, the concept of a cache-
1992    flush bit for these types is not applicable.  In particular, the
1993    rrclass field of an OPT record encodes the sender's UDP payload size,
1994    and should be interpreted as a sixteen-bit length value in the range
1995    0-65535, not a one-bit flag and a fifteen-bit length.
1997 10.3.  Cache Flush on Topology change
1999    If the hardware on a given host is able to indicate physical changes
2000    of connectivity, then when the hardware indicates such a change, the
2001    host should take this information into account in its Multicast DNS
2002    cache management strategy.  For example, a host may choose to
2003    immediately flush all cache records received on a particular
2004    interface when that cable is disconnected.  Alternatively, a host may
2005    choose to adjust the remaining TTL on all those records to a few
2006    seconds so that if the cable is not reconnected quickly, those
2007    records will expire from the cache.
2009    Likewise, when a host reboots, wakes from sleep, or undergoes some
2010    other similar discontinuous state change, the cache management
2011    strategy should take that information into account.
2018 Cheshire & Krochmal          Standards Track                   [Page 36]
2020 RFC 6762                      Multicast DNS                February 2013
2023 10.4.  Cache Flush on Failure Indication
2025    Sometimes a cache record can be determined to be stale when a client
2026    attempts to use the rdata it contains, and the client finds that
2027    rdata to be incorrect.
2029    For example, the rdata in an address record can be determined to be
2030    incorrect if attempts to contact that host fail, either because (for
2031    an IPv4 address on a local subnet) ARP requests for that address go
2032    unanswered, because (for an IPv6 address with an on-link prefix) ND
2033    requests for that address go unanswered, or because (for an address
2034    on a remote network) a router returns an ICMP "Host Unreachable"
2035    error.
2037    The rdata in an SRV record can be determined to be incorrect if
2038    attempts to communicate with the indicated service at the host and
2039    port number indicated are not successful.
2041    The rdata in a DNS-SD PTR record can be determined to be incorrect if
2042    attempts to look up the SRV record it references are not successful.
2044    The software implementing the Multicast DNS resource record cache
2045    should provide a mechanism so that clients detecting stale rdata can
2046    inform the cache.
2048    When the cache receives this hint that it should reconfirm some
2049    record, it MUST issue two or more queries for the resource record in
2050    dispute.  If no response is received within ten seconds, then, even
2051    though its TTL may indicate that it is not yet due to expire, that
2052    record SHOULD be promptly flushed from the cache.
2054    The end result of this is that if a printer suffers a sudden power
2055    failure or other abrupt disconnection from the network, its name may
2056    continue to appear in DNS-SD browser lists displayed on users'
2057    screens.  Eventually, that entry will expire from the cache
2058    naturally, but if a user tries to access the printer before that
2059    happens, the failure to successfully contact the printer will trigger
2060    the more hasty demise of its cache entries.  This is a sensible
2061    trade-off between good user experience and good network efficiency.
2062    If we were to insist that printers should disappear from the printer
2063    list within 30 seconds of becoming unavailable, for all failure
2064    modes, the only way to achieve this would be for the client to poll
2065    the printer at least every 30 seconds, or for the printer to announce
2066    its presence at least every 30 seconds, both of which would be an
2067    unreasonable burden on most networks.
2074 Cheshire & Krochmal          Standards Track                   [Page 37]
2076 RFC 6762                      Multicast DNS                February 2013
2079 10.5.  Passive Observation Of Failures (POOF)
2081    A host observes the multicast queries issued by the other hosts on
2082    the network.  One of the major benefits of also sending responses
2083    using multicast is that it allows all hosts to see the responses (or
2084    lack thereof) to those queries.
2086    If a host sees queries, for which a record in its cache would be
2087    expected to be given as an answer in a multicast response, but no
2088    such answer is seen, then the host may take this as an indication
2089    that the record may no longer be valid.
2091    After seeing two or more of these queries, and seeing no multicast
2092    response containing the expected answer within ten seconds, then even
2093    though its TTL may indicate that it is not yet due to expire, that
2094    record SHOULD be flushed from the cache.  The host SHOULD NOT perform
2095    its own queries to reconfirm that the record is truly gone.  If every
2096    host on a large network were to do this, it would cause a lot of
2097    unnecessary multicast traffic.  If host A sends multicast queries
2098    that remain unanswered, then there is no reason to suppose that host
2099    B or any other host is likely to be any more successful.
2101    The previous section, "Cache Flush on Failure Indication", describes
2102    a situation where a user trying to print discovers that the printer
2103    is no longer available.  By implementing the passive observation
2104    described here, when one user fails to contact the printer, all hosts
2105    on the network observe that failure and update their caches
2106    accordingly.
2108 11.  Source Address Check
2110    All Multicast DNS responses (including responses sent via unicast)
2111    SHOULD be sent with IP TTL set to 255.  This is recommended to
2112    provide backwards-compatibility with older Multicast DNS queriers
2113    (implementing a draft version of this document, posted in February
2114    2004) that check the IP TTL on reception to determine whether the
2115    packet originated on the local link.  These older queriers discard
2116    all packets with TTLs other than 255.
2118    A host sending Multicast DNS queries to a link-local destination
2119    address (including the and FF02::FB link-local multicast
2120    addresses) MUST only accept responses to that query that originate
2121    from the local link, and silently discard any other response packets.
2122    Without this check, it could be possible for remote rogue hosts to
2123    send spoof answer packets (perhaps unicast to the victim host), which
2124    the receiving machine could misinterpret as having originated on the
2125    local link.
2130 Cheshire & Krochmal          Standards Track                   [Page 38]
2132 RFC 6762                      Multicast DNS                February 2013
2135    The test for whether a response originated on the local link is done
2136    in two ways:
2138       * All responses received with a destination address in the IP
2139         header that is the mDNS IPv4 link-local multicast address
2140 or the mDNS IPv6 link-local multicast address
2141         FF02::FB are necessarily deemed to have originated on the local
2142         link, regardless of source IP address.  This is essential to
2143         allow devices to work correctly and reliably in unusual
2144         configurations, such as multiple logical IP subnets overlayed on
2145         a single link, or in cases of severe misconfiguration, where
2146         devices are physically connected to the same link, but are
2147         currently misconfigured with completely unrelated IP addresses
2148         and subnet masks.
2150       * For responses received with a unicast destination address in the
2151         IP header, the source IP address in the packet is checked to see
2152         if it is an address on a local subnet.  An IPv4 source address
2153         is determined to be on a local subnet if, for (one of) the
2154         address(es) configured on the interface receiving the packet, (I
2155         & M) == (P & M), where I and M are the interface address and
2156         subnet mask respectively, P is the source IP address from the
2157         packet, '&' represents the bitwise logical 'and' operation, and
2158         '==' represents a bitwise equality test.  An IPv6 source address
2159         is determined to be on the local link if, for any of the on-link
2160         IPv6 prefixes on the interface receiving the packet (learned via
2161         IPv6 router advertisements or otherwise configured on the host),
2162         the first 'n' bits of the IPv6 source address match the first
2163         'n' bits of the prefix address, where 'n' is the length of the
2164         prefix being considered.
2166    Since queriers will ignore responses apparently originating outside
2167    the local subnet, a responder SHOULD avoid generating responses that
2168    it can reasonably predict will be ignored.  This applies particularly
2169    in the case of overlayed subnets.  If a responder receives a query
2170    addressed to the mDNS IPv4 link-local multicast address,
2171    from a source address not apparently on the same subnet as the
2172    responder (or, in the case of IPv6, from a source IPv6 address for
2173    which the responder does not have any address with the same prefix on
2174    that interface), then even if the query indicates that a unicast
2175    response is preferred (see Section 5.4, "Questions Requesting Unicast
2176    Responses"), the responder SHOULD elect to respond by multicast
2177    anyway, since it can reasonably predict that a unicast response with
2178    an apparently non-local source address will probably be ignored.
2186 Cheshire & Krochmal          Standards Track                   [Page 39]
2188 RFC 6762                      Multicast DNS                February 2013
2191 12.  Special Characteristics of Multicast DNS Domains
2193    Unlike conventional DNS names, names that end in ".local." have only
2194    local significance.  The same is true of names within the IPv4 link-
2195    local reverse mapping domain "254.169.in-addr.arpa." and the IPv6
2196    link-local reverse mapping domains "8.e.f.ip6.arpa.",
2197    "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.".
2199    These names function primarily as protocol identifiers, rather than
2200    as user-visible identifiers.  Even though they may occasionally be
2201    visible to end users, that is not their primary purpose.  As such,
2202    these names should be treated as opaque identifiers.  In particular,
2203    the string "local" should not be translated or localized into
2204    different languages, much as the name "localhost" is not translated
2205    or localized into different languages.
2207    Conventional Unicast DNS seeks to provide a single unified namespace,
2208    where a given DNS query yields the same answer no matter where on the
2209    planet it is performed or to which recursive DNS server the query is
2210    sent.  In contrast, each IP link has its own private ".local.",
2211    "254.169.in-addr.arpa." and IPv6 link-local reverse mapping
2212    namespaces, and the answer to any query for a name within those
2213    domains depends on where that query is asked.  (This characteristic
2214    is not unique to Multicast DNS.  Although the original concept of DNS
2215    was a single global namespace, in recent years, split views,
2216    firewalls, intranets, DNS geolocation, and the like have increasingly
2217    meant that the answer to a given DNS query has become dependent on
2218    the location of the querier.)
2220    The IPv4 name server address for a Multicast DNS domain is
2221  The IPv6 name server address for a Multicast DNS domain
2222    is FF02::FB.  These are multicast addresses; therefore, they identify
2223    not a single host but a collection of hosts, working in cooperation
2224    to maintain some reasonable facsimile of a competently managed DNS
2225    zone.  Conceptually, a Multicast DNS domain is a single DNS zone;
2226    however, its server is implemented as a distributed process running
2227    on a cluster of loosely cooperating CPUs rather than as a single
2228    process running on a single CPU.
2230    Multicast DNS domains are not delegated from their parent domain via
2231    use of NS (Name Server) records, and there is also no concept of
2232    delegation of subdomains within a Multicast DNS domain.  Just because
2233    a particular host on the network may answer queries for a particular
2234    record type with the name "example.local." does not imply anything
2235    about whether that host will answer for the name
2236    "child.example.local.", or indeed for other record types with the
2237    name "example.local.".
2242 Cheshire & Krochmal          Standards Track                   [Page 40]
2244 RFC 6762                      Multicast DNS                February 2013
2247    There are no NS records anywhere in Multicast DNS domains.  Instead,
2248    the Multicast DNS domains are reserved by IANA, and there is
2249    effectively an implicit delegation of all Multicast DNS domains to
2250    the and [FF02::FB]:5353 multicast groups, by virtue
2251    of client software implementing the protocol rules specified in this
2252    document.
2254    Multicast DNS zones have no SOA (Start of Authority) record.  A
2255    conventional DNS zone's SOA record contains information such as the
2256    email address of the zone administrator and the monotonically
2257    increasing serial number of the last zone modification.  There is no
2258    single human administrator for any given Multicast DNS zone, so there
2259    is no email address.  Because the hosts managing any given Multicast
2260    DNS zone are only loosely coordinated, there is no readily available
2261    monotonically increasing serial number to determine whether or not
2262    the zone contents have changed.  A host holding part of the shared
2263    zone could crash or be disconnected from the network at any time
2264    without informing the other hosts.  There is no reliable way to
2265    provide a zone serial number that would, whenever such a crash or
2266    disconnection occurred, immediately change to indicate that the
2267    contents of the shared zone had changed.
2269    Zone transfers are not possible for any Multicast DNS zone.
2271 13.  Enabling and Disabling Multicast DNS
2273    The option to fail-over to Multicast DNS for names not ending in
2274    ".local." SHOULD be a user-configured option, and SHOULD be disabled
2275    by default because of the possible security issues related to
2276    unintended local resolution of apparently global names.  Enabling
2277    Multicast DNS for names not ending in ".local." may be appropriate on
2278    a secure isolated network, or on some future network were machines
2279    exclusively use DNSSEC for all DNS queries, and have Multicast DNS
2280    responders capable of generating the appropriate cryptographic DNSSEC
2281    signatures, thereby guarding against spoofing.
2283    The option to look up unqualified (relative) names by appending
2284    ".local." (or not) is controlled by whether ".local." appears (or
2285    not) in the client's DNS search list.
2287    No special control is needed for enabling and disabling Multicast DNS
2288    for names explicitly ending with ".local." as entered by the user.
2289    The user doesn't need a way to disable Multicast DNS for names ending
2290    with ".local.", because if the user doesn't want to use Multicast
2291    DNS, they can achieve this by simply not using those names.  If a
2292    user *does* enter a name ending in ".local.", then we can safely
2293    assume the user's intention was probably that it should work.  Having
2294    user configuration options that can be (intentionally or
2298 Cheshire & Krochmal          Standards Track                   [Page 41]
2300 RFC 6762                      Multicast DNS                February 2013
2303    unintentionally) set so that local names don't work is just one more
2304    way of frustrating the user's ability to perform the tasks they want,
2305    perpetuating the view that, "IP networking is too complicated to
2306    configure and too hard to use".
2308 14.  Considerations for Multiple Interfaces
2310    A host SHOULD defend its dot-local host name on all active interfaces
2311    on which it is answering Multicast DNS queries.
2313    In the event of a name conflict on *any* interface, a host should
2314    configure a new host name, if it wishes to maintain uniqueness of its
2315    host name.
2317    A host may choose to use the same name (or set of names) for all of
2318    its address records on all interfaces, or it may choose to manage its
2319    Multicast DNS interfaces independently, potentially answering to a
2320    different name (or set of names) on different interfaces.
2322    Except in the case of proxying and other similar specialized uses,
2323    addresses in IPv4 or IPv6 address records in Multicast DNS responses
2324    MUST be valid for use on the interface on which the response is being
2325    sent.
2327    Just as the same link-local IP address may validly be in use
2328    simultaneously on different links by different hosts, the same link-
2329    local host name may validly be in use simultaneously on different
2330    links, and this is not an error.  A multihomed host with connections
2331    to two different links may be able to communicate with two different
2332    hosts that are validly using the same name.  While this kind of name
2333    duplication should be rare, it means that a host that wants to fully
2334    support this case needs network programming APIs that allow
2335    applications to specify on what interface to perform a link-local
2336    Multicast DNS query, and to discover on what interface a Multicast
2337    DNS response was received.
2339    There is one other special precaution that multihomed hosts need to
2340    take.  It's common with today's laptop computers to have an Ethernet
2341    connection and an 802.11 [IEEE.802.11] wireless connection active at
2342    the same time.  What the software on the laptop computer can't easily
2343    tell is whether the wireless connection is in fact bridged onto the
2344    same network segment as its Ethernet connection.  If the two networks
2345    are bridged together, then packets the host sends on one interface
2346    will arrive on the other interface a few milliseconds later, and care
2347    must be taken to ensure that this bridging does not cause problems:
2354 Cheshire & Krochmal          Standards Track                   [Page 42]
2356 RFC 6762                      Multicast DNS                February 2013
2359    When the host announces its host name (i.e., its address records) on
2360    its wireless interface, those announcement records are sent with the
2361    cache-flush bit set, so when they arrive on the Ethernet segment,
2362    they will cause all the peers on the Ethernet to flush the host's
2363    Ethernet address records from their caches.  The Multicast DNS
2364    protocol has a safeguard to protect against this situation: when
2365    records are received with the cache-flush bit set, other records are
2366    not deleted from peer caches immediately, but are marked for deletion
2367    in one second.  When the host sees its own wireless address records
2368    arrive on its Ethernet interface, with the cache-flush bit set, this
2369    one-second grace period gives the host time to respond and re-
2370    announce its Ethernet address records, to reinstate those records in
2371    peer caches before they are deleted.
2373    As described, this solves one problem, but creates another, because
2374    when those Ethernet announcement records arrive back on the wireless
2375    interface, the host would again respond defensively to reinstate its
2376    wireless records, and this process would continue forever,
2377    continuously flooding the network with traffic.  The Multicast DNS
2378    protocol has a second safeguard, to solve this problem: the cache-
2379    flush bit does not apply to records received very recently, within
2380    the last second.  This means that when the host sees its own Ethernet
2381    address records arrive on its wireless interface, with the cache-
2382    flush bit set, it knows there's no need to re-announce its wireless
2383    address records again because it already sent them less than a second
2384    ago, and this makes them immune from deletion from peer caches.  (See
2385    Section 10.2.)
2387 15.  Considerations for Multiple Responders on the Same Machine
2389    It is possible to have more than one Multicast DNS responder and/or
2390    querier implementation coexist on the same machine, but there are
2391    some known issues.
2393 15.1.  Receiving Unicast Responses
2395    In most operating systems, incoming *multicast* packets can be
2396    delivered to *all* open sockets bound to the right port number,
2397    provided that the clients take the appropriate steps to allow this.
2398    For this reason, all Multicast DNS implementations SHOULD use the
2399    SO_REUSEPORT and/or SO_REUSEADDR options (or equivalent as
2400    appropriate for the operating system in question) so they will all be
2401    able to bind to UDP port 5353 and receive incoming multicast packets
2402    addressed to that port.  However, unlike multicast packets, incoming
2403    unicast UDP packets are typically delivered only to the first socket
2404    to bind to that port.  This means that "QU" responses and other
2405    packets sent via unicast will be received only by the first Multicast
2406    DNS responder and/or querier on a system.  This limitation can be
2410 Cheshire & Krochmal          Standards Track                   [Page 43]
2412 RFC 6762                      Multicast DNS                February 2013
2415    partially mitigated if Multicast DNS implementations detect when they
2416    are not the first to bind to port 5353, and in that case they do not
2417    request "QU" responses.  One way to detect if there is another
2418    Multicast DNS implementation already running is to attempt binding to
2419    port 5353 without using SO_REUSEPORT and/or SO_REUSEADDR, and if that
2420    fails it indicates that some other socket is already bound to this
2421    port.
2423 15.2.  Multipacket Known-Answer lists
2425    When a Multicast DNS querier issues a query with too many Known
2426    Answers to fit into a single packet, it divides the Known-Answer list
2427    into two or more packets.  Multicast DNS responders associate the
2428    initial truncated query with its continuation packets by examining
2429    the source IP address in each packet.  Since two independent
2430    Multicast DNS queriers running on the same machine will be sending
2431    packets with the same source IP address, from an outside perspective
2432    they appear to be a single entity.  If both queriers happened to send
2433    the same multipacket query at the same time, with different Known-
2434    Answer lists, then they could each end up suppressing answers that
2435    the other needs.
2437 15.3.  Efficiency
2439    If different clients on a machine were each to have their own
2440    independent Multicast DNS implementation, they would lose certain
2441    efficiency benefits.  Apart from the unnecessary code duplication,
2442    memory usage, and CPU load, the clients wouldn't get the benefit of a
2443    shared system-wide cache, and they would not be able to aggregate
2444    separate queries into single packets to reduce network traffic.
2446 15.4.  Recommendation
2448    Because of these issues, this document encourages implementers to
2449    design systems with a single Multicast DNS implementation that
2450    provides Multicast DNS services shared by all clients on that
2451    machine, much as most operating systems today have a single TCP
2452    implementation, which is shared between all clients on that machine.
2453    Due to engineering constraints, there may be situations where
2454    embedding a "user-level" Multicast DNS implementation in the client
2455    application software is the most expedient solution, and while this
2456    will usually work in practice, implementers should be aware of the
2457    issues outlined in this section.
2466 Cheshire & Krochmal          Standards Track                   [Page 44]
2468 RFC 6762                      Multicast DNS                February 2013
2471 16.  Multicast DNS Character Set
2473    Historically, Unicast DNS has been used with a very restricted set of
2474    characters.  Indeed, conventional DNS is usually limited to just
2475    twenty-six letters, ten digits and the hyphen character, not even
2476    allowing spaces or other punctuation.  Attempts to remedy this for
2477    Unicast DNS have been badly constrained by the perceived need to
2478    accommodate old buggy legacy DNS implementations.  In reality, the
2479    DNS specification itself actually imposes no limits on what
2480    characters may be used in names, and good DNS implementations handle
2481    any arbitrary eight-bit data without trouble.  "Clarifications to the
2482    DNS Specification" [RFC2181] directly discusses the subject of
2483    allowable character set in Section 11 ("Name syntax"), and explicitly
2484    states that DNS names may contain arbitrary eight-bit data.  However,
2485    the old rules for ARPANET host names back in the 1980s required host
2486    names to be just letters, digits, and hyphens [RFC1034], and since
2487    the predominant use of DNS is to store host address records, many
2488    have assumed that the DNS protocol itself suffers from the same
2489    limitation.  It might be accurate to say that there could be
2490    hypothetical bad implementations that do not handle eight-bit data
2491    correctly, but it would not be accurate to say that the protocol
2492    doesn't allow names containing eight-bit data.
2494    Multicast DNS is a new protocol and doesn't (yet) have old buggy
2495    legacy implementations to constrain the design choices.  Accordingly,
2496    it adopts the simple obvious elegant solution: all names in Multicast
2497    DNS MUST be encoded as precomposed UTF-8 [RFC3629] "Net-Unicode"
2498    [RFC5198] text.
2500    Some users of 16-bit Unicode have taken to stuffing a "zero-width
2501    nonbreaking space" character (U+FEFF) at the start of each UTF-16
2502    file, as a hint to identify whether the data is big-endian or little-
2503    endian, and calling it a "Byte Order Mark" (BOM).  Since there is
2504    only one possible byte order for UTF-8 data, a BOM is neither
2505    necessary nor permitted.  Multicast DNS names MUST NOT contain a
2506    "Byte Order Mark".  Any occurrence of the Unicode character U+FEFF at
2507    the start or anywhere else in a Multicast DNS name MUST be
2508    interpreted as being an actual intended part of the name,
2509    representing (just as for any other legal unicode value) an actual
2510    literal instance of that character (in this case a zero-width non-
2511    breaking space character).
2513    For names that are restricted to US-ASCII [RFC0020] letters, digits,
2514    and hyphens, the UTF-8 encoding is identical to the US-ASCII
2515    encoding, so this is entirely compatible with existing host names.
2516    For characters outside the US-ASCII range, UTF-8 encoding is used.
2522 Cheshire & Krochmal          Standards Track                   [Page 45]
2524 RFC 6762                      Multicast DNS                February 2013
2527    Multicast DNS implementations MUST NOT use any other encodings apart
2528    from precomposed UTF-8 (US-ASCII being considered a compatible subset
2529    of UTF-8).  The reasons for selecting UTF-8 instead of Punycode
2530    [RFC3492] are discussed further in Appendix F.
2532    The simple rules for case-insensitivity in Unicast DNS [RFC1034]
2533    [RFC1035] also apply in Multicast DNS; that is to say, in name
2534    comparisons, the lowercase letters "a" to "z" (0x61 to 0x7A) match
2535    their uppercase equivalents "A" to "Z" (0x41 to 0x5A).  Hence, if a
2536    querier issues a query for an address record with the name
2537    "myprinter.local.", then a responder having an address record with
2538    the name "MyPrinter.local." should issue a response.  No other
2539    automatic equivalences should be assumed.  In particular, all UTF-8
2540    multibyte characters (codes 0x80 and higher) are compared by simple
2541    binary comparison of the raw byte values.  Accented characters are
2542    *not* defined to be automatically equivalent to their unaccented
2543    counterparts.  Where automatic equivalences are desired, this may be
2544    achieved through the use of programmatically generated CNAME records.
2545    For example, if a responder has an address record for an accented
2546    name Y, and a querier issues a query for a name X, where X is the
2547    same as Y with all the accents removed, then the responder may issue
2548    a response containing two resource records: a CNAME record "X CNAME
2549    Y", asserting that the requested name X (unaccented) is an alias for
2550    the true (accented) name Y, followed by the address record for Y.
2552 17.  Multicast DNS Message Size
2554    The 1987 DNS specification [RFC1035] restricts DNS messages carried
2555    by UDP to no more than 512 bytes (not counting the IP or UDP
2556    headers).  For UDP packets carried over the wide-area Internet in
2557    1987, this was appropriate.  For link-local multicast packets on
2558    today's networks, there is no reason to retain this restriction.
2559    Given that the packets are by definition link-local, there are no
2560    Path MTU issues to consider.
2562    Multicast DNS messages carried by UDP may be up to the IP MTU of the
2563    physical interface, less the space required for the IP header (20
2564    bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes).
2566    In the case of a single Multicast DNS resource record that is too
2567    large to fit in a single MTU-sized multicast response packet, a
2568    Multicast DNS responder SHOULD send the resource record alone, in a
2569    single IP datagram, using multiple IP fragments.  Resource records
2570    this large SHOULD be avoided, except in the very rare cases where
2571    they really are the appropriate solution to the problem at hand.
2572    Implementers should be aware that many simple devices do not
2573    reassemble fragmented IP datagrams, so large resource records SHOULD
2574    NOT be used except in specialized cases where the implementer knows
2578 Cheshire & Krochmal          Standards Track                   [Page 46]
2580 RFC 6762                      Multicast DNS                February 2013
2583    that all receivers implement reassembly, or where the large resource
2584    record contains optional data which is not essential for correct
2585    operation of the client.
2587    A Multicast DNS packet larger than the interface MTU, which is sent
2588    using fragments, MUST NOT contain more than one resource record.
2590    Even when fragmentation is used, a Multicast DNS packet, including IP
2591    and UDP headers, MUST NOT exceed 9000 bytes.
2593    Note that 9000 bytes is also the maximum payload size of an Ethernet
2594    "Jumbo" packet [Jumbo].  However, in practice Ethernet "Jumbo"
2595    packets are not widely used, so it is advantageous to keep packets
2596    under 1500 bytes whenever possible.  Even on hosts that normally
2597    handle Ethernet "Jumbo" packets and IP fragment reassembly, it is
2598    becoming more common for these hosts to implement power-saving modes
2599    where the main CPU goes to sleep and hands off packet reception tasks
2600    to a more limited processor in the network interface hardware, which
2601    may not support Ethernet "Jumbo" packets or IP fragment reassembly.
2603 18.  Multicast DNS Message Format
2605    This section describes specific rules pertaining to the allowable
2606    values for the header fields of a Multicast DNS message, and other
2607    message format considerations.
2609 18.1.  ID (Query Identifier)
2611    Multicast DNS implementations SHOULD listen for unsolicited responses
2612    issued by hosts booting up (or waking up from sleep or otherwise
2613    joining the network).  Since these unsolicited responses may contain
2614    a useful answer to a question for which the querier is currently
2615    awaiting an answer, Multicast DNS implementations SHOULD examine all
2616    received Multicast DNS response messages for useful answers, without
2617    regard to the contents of the ID field or the Question Section.  In
2618    Multicast DNS, knowing which particular query message (if any) is
2619    responsible for eliciting a particular response message is less
2620    interesting than knowing whether the response message contains useful
2621    information.
2623    Multicast DNS implementations MAY cache data from any or all
2624    Multicast DNS response messages they receive, for possible future
2625    use, provided of course that normal TTL aging is performed on these
2626    cached resource records.
2628    In multicast query messages, the Query Identifier SHOULD be set to
2629    zero on transmission.
2634 Cheshire & Krochmal          Standards Track                   [Page 47]
2636 RFC 6762                      Multicast DNS                February 2013
2639    In multicast responses, including unsolicited multicast responses,
2640    the Query Identifier MUST be set to zero on transmission, and MUST be
2641    ignored on reception.
2643    In legacy unicast response messages generated specifically in
2644    response to a particular (unicast or multicast) query, the Query
2645    Identifier MUST match the ID from the query message.
2647 18.2.  QR (Query/Response) Bit
2649    In query messages the QR bit MUST be zero.
2650    In response messages the QR bit MUST be one.
2652 18.3.  OPCODE
2654    In both multicast query and multicast response messages, the OPCODE
2655    MUST be zero on transmission (only standard queries are currently
2656    supported over multicast).  Multicast DNS messages received with an
2657    OPCODE other than zero MUST be silently ignored.
2659 18.4.  AA (Authoritative Answer) Bit
2661    In query messages, the Authoritative Answer bit MUST be zero on
2662    transmission, and MUST be ignored on reception.
2664    In response messages for Multicast domains, the Authoritative Answer
2665    bit MUST be set to one (not setting this bit would imply there's some
2666    other place where "better" information may be found) and MUST be
2667    ignored on reception.
2669 18.5.  TC (Truncated) Bit
2671    In query messages, if the TC bit is set, it means that additional
2672    Known-Answer records may be following shortly.  A responder SHOULD
2673    record this fact, and wait for those additional Known-Answer records,
2674    before deciding whether to respond.  If the TC bit is clear, it means
2675    that the querying host has no additional Known Answers.
2677    In multicast response messages, the TC bit MUST be zero on
2678    transmission, and MUST be ignored on reception.
2680    In legacy unicast response messages, the TC bit has the same meaning
2681    as in conventional Unicast DNS: it means that the response was too
2682    large to fit in a single packet, so the querier SHOULD reissue its
2683    query using TCP in order to receive the larger response.
2690 Cheshire & Krochmal          Standards Track                   [Page 48]
2692 RFC 6762                      Multicast DNS                February 2013
2695 18.6.  RD (Recursion Desired) Bit
2697    In both multicast query and multicast response messages, the
2698    Recursion Desired bit SHOULD be zero on transmission, and MUST be
2699    ignored on reception.
2701 18.7.  RA (Recursion Available) Bit
2703    In both multicast query and multicast response messages, the
2704    Recursion Available bit MUST be zero on transmission, and MUST be
2705    ignored on reception.
2707 18.8.  Z (Zero) Bit
2709    In both query and response messages, the Zero bit MUST be zero on
2710    transmission, and MUST be ignored on reception.
2712 18.9.  AD (Authentic Data) Bit
2714    In both multicast query and multicast response messages, the
2715    Authentic Data bit [RFC2535] MUST be zero on transmission, and MUST
2716    be ignored on reception.
2718 18.10.  CD (Checking Disabled) Bit
2720    In both multicast query and multicast response messages, the Checking
2721    Disabled bit [RFC2535] MUST be zero on transmission, and MUST be
2722    ignored on reception.
2724 18.11.  RCODE (Response Code)
2726    In both multicast query and multicast response messages, the Response
2727    Code MUST be zero on transmission.  Multicast DNS messages received
2728    with non-zero Response Codes MUST be silently ignored.
2730 18.12.  Repurposing of Top Bit of qclass in Question Section
2732    In the Question Section of a Multicast DNS query, the top bit of the
2733    qclass field is used to indicate that unicast responses are preferred
2734    for this particular question.  (See Section 5.4.)
2736 18.13.  Repurposing of Top Bit of rrclass in Resource Record Sections
2738    In the Resource Record Sections of a Multicast DNS response, the top
2739    bit of the rrclass field is used to indicate that the record is a
2740    member of a unique RRSet, and the entire RRSet has been sent together
2741    (in the same packet, or in consecutive packets if there are too many
2742    records to fit in a single packet).  (See Section 10.2.)
2746 Cheshire & Krochmal          Standards Track                   [Page 49]
2748 RFC 6762                      Multicast DNS                February 2013
2751 18.14.  Name Compression
2753    When generating Multicast DNS messages, implementations SHOULD use
2754    name compression wherever possible to compress the names of resource
2755    records, by replacing some or all of the resource record name with a
2756    compact two-byte reference to an appearance of that data somewhere
2757    earlier in the message [RFC1035].
2759    This applies not only to Multicast DNS responses, but also to
2760    queries.  When a query contains more than one question, successive
2761    questions in the same message often contain similar names, and
2762    consequently name compression SHOULD be used, to save bytes.  In
2763    addition, queries may also contain Known Answers in the Answer
2764    Section, or probe tiebreaking data in the Authority Section, and
2765    these names SHOULD similarly be compressed for network efficiency.
2767    In addition to compressing the *names* of resource records, names
2768    that appear within the *rdata* of the following rrtypes SHOULD also
2769    be compressed in all Multicast DNS messages:
2773    Until future IETF Standards Action [RFC5226] specifying that names in
2774    the rdata of other types should be compressed, names that appear
2775    within the rdata of any type not listed above MUST NOT be compressed.
2777    Implementations receiving Multicast DNS messages MUST correctly
2778    decode compressed names appearing in the Question Section, and
2779    compressed names of resource records appearing in other sections.
2781    In addition, implementations MUST correctly decode compressed names
2782    appearing within the *rdata* of the rrtypes listed above.  Where
2783    possible, implementations SHOULD also correctly decode compressed
2784    names appearing within the *rdata* of other rrtypes known to the
2785    implementers at the time of implementation, because such forward-
2786    thinking planning helps facilitate the deployment of future
2787    implementations that may have reason to compress those rrtypes.  It
2788    is possible that no future IETF Standards Action [RFC5226] will be
2789    created that mandates or permits the compression of rdata in new
2790    types, but having implementations designed such that they are capable
2791    of decompressing all known types helps keep future options open.
2793    One specific difference between Unicast DNS and Multicast DNS is that
2794    Unicast DNS does not allow name compression for the target host in an
2795    SRV record, because Unicast DNS implementations before the first SRV
2796    specification in 1996 [RFC2052] may not decode these compressed
2802 Cheshire & Krochmal          Standards Track                   [Page 50]
2804 RFC 6762                      Multicast DNS                February 2013
2807    records properly.  Since all Multicast DNS implementations were
2808    created after 1996, all Multicast DNS implementations are REQUIRED to
2809    decode compressed SRV records correctly.
2811    In legacy unicast responses generated to answer legacy queries, name
2812    compression MUST NOT be performed on SRV records.
2814 19.  Summary of Differences between Multicast DNS and Unicast DNS
2816    Multicast DNS shares, as much as possible, the familiar APIs, naming
2817    syntax, resource record types, etc., of Unicast DNS.  There are, of
2818    course, necessary differences by virtue of it using multicast, and by
2819    virtue of it operating in a community of cooperating peers, rather
2820    than a precisely defined hierarchy controlled by a strict chain of
2821    formal delegations from the root.  These differences are summarized
2822    below:
2824    Multicast DNS...
2825    * uses multicast
2826    * uses UDP port 5353 instead of port 53
2827    * operates in well-defined parts of the DNS namespace
2828    * has no SOA (Start of Authority) records
2829    * uses UTF-8, and only UTF-8, to encode resource record names
2830    * allows names up to 255 bytes plus a terminating zero byte
2831    * allows name compression in rdata for SRV and other record types
2832    * allows larger UDP packets
2833    * allows more than one question in a query message
2834    * defines consistent results for qtype "ANY" and qclass "ANY" queries
2835    * uses the Answer Section of a query to list Known Answers
2836    * uses the TC bit in a query to indicate additional Known Answers
2837    * uses the Authority Section of a query for probe tiebreaking
2838    * ignores the Query ID field (except for generating legacy responses)
2839    * doesn't require the question to be repeated in the response message
2840    * uses unsolicited responses to announce new records
2841    * uses NSEC records to signal nonexistence of records
2842    * defines a unicast-response bit in the rrclass of query questions
2843    * defines a cache-flush bit in the rrclass of response records
2844    * uses DNS RR TTL 0 to indicate that a record has been deleted
2845    * recommends AAAA records in the additional section when responding
2846      to rrtype "A" queries, and vice versa
2847    * monitors queries to perform Duplicate Question Suppression
2848    * monitors responses to perform Duplicate Answer Suppression...
2849    * ... and Ongoing Conflict Detection
2850    * ... and Opportunistic Caching
2858 Cheshire & Krochmal          Standards Track                   [Page 51]
2860 RFC 6762                      Multicast DNS                February 2013
2863 20.  IPv6 Considerations
2865    An IPv4-only host and an IPv6-only host behave as "ships that pass in
2866    the night".  Even if they are on the same Ethernet, neither is aware
2867    of the other's traffic.  For this reason, each physical link may have
2868    *two* unrelated ".local." zones, one for IPv4 and one for IPv6.
2869    Since for practical purposes, a group of IPv4-only hosts and a group
2870    of IPv6-only hosts on the same Ethernet act as if they were on two
2871    entirely separate Ethernet segments, it is unsurprising that their
2872    use of the ".local." zone should occur exactly as it would if they
2873    really were on two entirely separate Ethernet segments.
2875    A dual-stack (v4/v6) host can participate in both ".local." zones,
2876    and should register its name(s) and perform its lookups both using
2877    IPv4 and IPv6.  This enables it to reach, and be reached by, both
2878    IPv4-only and IPv6-only hosts.  In effect, this acts like a
2879    multihomed host, with one connection to the logical "IPv4 Ethernet
2880    segment", and a connection to the logical "IPv6 Ethernet segment".
2881    When such a host generates NSEC records, if it is using the same host
2882    name for its IPv4 addresses and its IPv6 addresses on that network
2883    interface, its NSEC records should indicate that the host name has
2884    both A and AAAA records.
2886 21.  Security Considerations
2888    The algorithm for detecting and resolving name conflicts is, by its
2889    very nature, an algorithm that assumes cooperating participants.  Its
2890    purpose is to allow a group of hosts to arrive at a mutually disjoint
2891    set of host names and other DNS resource record names, in the absence
2892    of any central authority to coordinate this or mediate disputes.  In
2893    the absence of any higher authority to resolve disputes, the only
2894    alternative is that the participants must work together cooperatively
2895    to arrive at a resolution.
2897    In an environment where the participants are mutually antagonistic
2898    and unwilling to cooperate, other mechanisms are appropriate, like
2899    manually configured DNS.
2901    In an environment where there is a group of cooperating participants,
2902    but clients cannot be sure that there are no antagonistic hosts on
2903    the same physical link, the cooperating participants need to use
2904    IPsec signatures and/or DNSSEC [RFC4033] signatures so that they can
2905    distinguish Multicast DNS messages from trusted participants (which
2906    they process as usual) from Multicast DNS messages from untrusted
2907    participants (which they silently discard).
2914 Cheshire & Krochmal          Standards Track                   [Page 52]
2916 RFC 6762                      Multicast DNS                February 2013
2919    If DNS queries for *global* DNS names are sent to the mDNS multicast
2920    address (during network outages which disrupt communication with the
2921    greater Internet) it is *especially* important to use DNSSEC, because
2922    the user may have the impression that he or she is communicating with
2923    some authentic host, when in fact he or she is really communicating
2924    with some local host that is merely masquerading as that name.  This
2925    is less critical for names ending with ".local.", because the user
2926    should be aware that those names have only local significance and no
2927    global authority is implied.
2929    Most computer users neglect to type the trailing dot at the end of a
2930    fully qualified domain name, making it a relative domain name (e.g.,
2931    "www.example.com").  In the event of network outage, attempts to
2932    positively resolve the name as entered will fail, resulting in
2933    application of the search list, including ".local.", if present.  A
2934    malicious host could masquerade as "www.example.com." by answering
2935    the resulting Multicast DNS query for "www.example.com.local.".  To
2936    avoid this, a host MUST NOT append the search suffix ".local.", if
2937    present, to any relative (partially qualified) host name containing
2938    two or more labels.  Appending ".local." to single-label relative
2939    host names is acceptable, since the user should have no expectation
2940    that a single-label host name will resolve as is.  However, users who
2941    have both "example.com" and "local" in their search lists should be
2942    aware that if they type "www" into their web browser, it may not be
2943    immediately clear to them whether the page that appears is
2944    "www.example.com" or "www.local".
2946    Multicast DNS uses UDP port 5353.  On operating systems where only
2947    privileged processes are allowed to use ports below 1024, no such
2948    privilege is required to use port 5353.
2950 22.  IANA Considerations
2952    IANA has allocated the UDP port 5353 for the Multicast DNS protocol
2953    described in this document [SN].
2955    IANA has allocated the IPv4 link-local multicast address
2956    for the use described in this document [MC4].
2958    IANA has allocated the IPv6 multicast address set FF0X::FB (where "X"
2959    indicates any hexadecimal digit from '1' to 'F') for the use
2960    described in this document [MC6].  Only address FF02::FB (link-local
2961    scope) is currently in use by deployed software, but it is possible
2962    that in the future implementers may experiment with Multicast DNS
2963    using larger-scoped addresses, such as FF05::FB (site-local scope)
2964    [RFC4291].
2970 Cheshire & Krochmal          Standards Track                   [Page 53]
2972 RFC 6762                      Multicast DNS                February 2013
2975    IANA has implemented the following DNS records:
2977       MDNS.MCAST.NET.            IN  A
2980    Entries for the AAAA and corresponding PTR records have not been made
2981    as there is not yet an RFC providing direction for the management of
2982    the IP6.ARPA domain relating to the IPv6 multicast address space.
2984    The reuse of the top bit of the rrclass field in the Question and
2985    Resource Record Sections means that Multicast DNS can only carry DNS
2986    records with classes in the range 0-32767.  Classes in the range
2987    32768 to 65535 are incompatible with Multicast DNS.  IANA has noted
2988    this fact, and if IANA receives a request to allocate a DNS class
2989    value above 32767, IANA will make sure the requester is aware of this
2990    implication before proceeding.  This does not mean that allocations
2991    of DNS class values above 32767 should be denied, only that they
2992    should not be allowed until the requester has indicated that they are
2993    aware of how this allocation will interact with Multicast DNS.
2994    However, to date, only three DNS classes have been assigned by IANA
2995    (1, 3, and 4), and only one (1, "Internet") is actually in widespread
2996    use, so this issue is likely to remain a purely theoretical one.
2998    IANA has recorded the list of domains below as being Special-Use
2999    Domain Names [RFC6761]:
3001       .local.
3002       .254.169.in-addr.arpa.
3003       .8.e.f.ip6.arpa.
3004       .9.e.f.ip6.arpa.
3005       .a.e.f.ip6.arpa.
3006       .b.e.f.ip6.arpa.
3008 22.1.  Domain Name Reservation Considerations
3010    The six domains listed above, and any names falling within those
3011    domains (e.g., "MyPrinter.local.", "",
3012    "Ink-Jet._pdl-datastream._tcp.local.") are special [RFC6761] in the
3013    following ways:
3015       1. Users may use these names as they would other DNS names,
3016          entering them anywhere that they would otherwise enter a
3017          conventional DNS name, or a dotted decimal IPv4 address, or a
3018          literal IPv6 address.
3020          Since there is no central authority responsible for assigning
3021          dot-local names, and all devices on the local network are
3022          equally entitled to claim any dot-local name, users SHOULD be
3026 Cheshire & Krochmal          Standards Track                   [Page 54]
3028 RFC 6762                      Multicast DNS                February 2013
3031          aware of this and SHOULD exercise appropriate caution.  In an
3032          untrusted or unfamiliar network environment, users SHOULD be
3033          aware that using a name like "www.local" may not actually
3034          connect them to the web site they expected, and could easily
3035          connect them to a different web page, or even a fake or spoof
3036          of their intended web site, designed to trick them into
3037          revealing confidential information.  As always with networking,
3038          end-to-end cryptographic security can be a useful tool.  For
3039          example, when connecting with ssh, the ssh host key
3040          verification process will inform the user if it detects that
3041          the identity of the entity they are communicating with has
3042          changed since the last time they connected to that name.
3044       2. Application software may use these names as they would other
3045          similar DNS names, and is not required to recognize the names
3046          and treat them specially.  Due to the relative ease of spoofing
3047          dot-local names, end-to-end cryptographic security remains
3048          important when communicating across a local network, just as it
3049          is when communicating across the global Internet.
3051       3. Name resolution APIs and libraries SHOULD recognize these names
3052          as special and SHOULD NOT send queries for these names to their
3053          configured (unicast) caching DNS server(s).  This is to avoid
3054          unnecessary load on the root name servers and other name
3055          servers, caused by queries for which those name servers do not
3056          have useful non-negative answers to give, and will not ever
3057          have useful non-negative answers to give.
3059       4. Caching DNS servers SHOULD recognize these names as special and
3060          SHOULD NOT attempt to look up NS records for them, or otherwise
3061          query authoritative DNS servers in an attempt to resolve these
3062          names.  Instead, caching DNS servers SHOULD generate immediate
3063          NXDOMAIN responses for all such queries they may receive (from
3064          misbehaving name resolver libraries).  This is to avoid
3065          unnecessary load on the root name servers and other name
3066          servers.
3068       5. Authoritative DNS servers SHOULD NOT by default be configurable
3069          to answer queries for these names, and, like caching DNS
3070          servers, SHOULD generate immediate NXDOMAIN responses for all
3071          such queries they may receive.  DNS server software MAY provide
3072          a configuration option to override this default, for testing
3073          purposes or other specialized uses.
3075       6. DNS server operators SHOULD NOT attempt to configure
3076          authoritative DNS servers to act as authoritative for any of
3077          these names.  Configuring an authoritative DNS server to act as
3078          authoritative for any of these names may not, in many cases,
3082 Cheshire & Krochmal          Standards Track                   [Page 55]
3084 RFC 6762                      Multicast DNS                February 2013
3087          yield the expected result.  Since name resolver libraries and
3088          caching DNS servers SHOULD NOT send queries for those names
3089          (see 3 and 4 above), such queries SHOULD be suppressed before
3090          they even reach the authoritative DNS server in question, and
3091          consequently it will not even get an opportunity to answer
3092          them.
3094       7. DNS Registrars MUST NOT allow any of these names to be
3095          registered in the normal way to any person or entity.  These
3096          names are reserved protocol identifiers with special meaning
3097          and fall outside the set of names available for allocation by
3098          registrars.  Attempting to allocate one of these names as if it
3099          were a normal domain name will probably not work as desired,
3100          for reasons 3, 4, and 6 above.
3102 23.  Acknowledgments
3104    The concepts described in this document have been explored,
3105    developed, and implemented with help from Ran Atkinson, Richard
3106    Brown, Freek Dijkstra, Erik Guttman, Kyle McKay, Pasi Sarolahti,
3107    Pekka Savola, Robby Simpson, Mark Townsley, Paul Vixie, Bill
3108    Woodcock, and others.  Special thanks go to Bob Bradley, Josh
3109    Graessley, Scott Herscher, Rory McGuire, Roger Pantos, and Kiren
3110    Sekar for their significant contributions.  Special thanks also to
3111    Kerry Lynn for converting the document to xml2rfc form in May 2010,
3112    and to Area Director Ralph Droms for shepherding the document through
3113    its final steps.
3115 24.  References
3117 24.1.  Normative References
3119    [MC4]      IANA, "IPv4 Multicast Address Space Registry",
3120               <http://www.iana.org/assignments/multicast-addresses/>.
3122    [MC6]      IANA, "IPv6 Multicast Address Space Registry",
3123               <http://www.iana.org/assignments/
3124               ipv6-multicast-addresses/>.
3126    [RFC0020]  Cerf, V., "ASCII format for network interchange", RFC 20,
3127               October 1969.
3129    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
3130               STD 13, RFC 1034, November 1987.
3132    [RFC1035]  Mockapetris, P., "Domain names - implementation and
3133               specification", STD 13, RFC 1035, November 1987.
3138 Cheshire & Krochmal          Standards Track                   [Page 56]
3140 RFC 6762                      Multicast DNS                February 2013
3143    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
3144               Requirement Levels", BCP 14, RFC 2119, March 1997.
3146    [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
3147               10646", STD 63, RFC 3629, November 2003.
3149    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
3150               Rose, "Resource Records for the DNS Security Extensions",
3151               RFC 4034, March 2005.
3153    [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
3154               Interchange", RFC 5198, March 2008.
3156    [RFC6195]  Eastlake 3rd, D., "Domain Name System (DNS) IANA
3157               Considerations", BCP 42, RFC 6195, March 2011.
3159    [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
3160               RFC 6761, February 2013.
3162    [SN]       IANA, "Service Name and Transport Protocol Port Number
3163               Registry", <http://www.iana.org/assignments/
3164               service-names-port-numbers/>.
3166 24.2.  Informative References
3168    [B4W]      "Bonjour for Windows",
3169               <http://en.wikipedia.org/wiki/Bonjour_(software)>.
3171    [BJ]       Apple Bonjour Open Source Software,
3172               <http://developer.apple.com/bonjour/>.
3174    [IEEE.802.3]
3175               "Information technology - Telecommunications and
3176               information exchange between systems - Local and
3177               metropolitan area networks - Specific requirements - Part
3178               3: Carrier Sense Multiple Access with Collision Detection
3179               (CMSA/CD) Access Method and Physical Layer
3180               Specifications", IEEE Std 802.3-2008, December 2008,
3181               <http://standards.ieee.org/getieee802/802.3.html>.
3183    [IEEE.802.11]
3184               "Information technology - Telecommunications and
3185               information exchange between systems - Local and
3186               metropolitan area networks - Specific requirements - Part
3187               11: Wireless LAN Medium Access Control (MAC) and Physical
3188               Layer (PHY) Specifications", IEEE Std 802.11-2007, June
3189               2007, <http://standards.ieee.org/getieee802/802.11.html>.
3194 Cheshire & Krochmal          Standards Track                   [Page 57]
3196 RFC 6762                      Multicast DNS                February 2013
3199    [Jumbo]    "Ethernet Jumbo Frames", November 2009,
3200               <http://www.ethernetalliance.org/library/whitepaper/
3201               ethernet-jumbo-frames/>.
3203    [NIAS]     Cheshire, S. "Discovering Named Instances of Abstract
3204               Services using DNS", Work in Progress, July 2001.
3206    [NSD]      "NsdManager | Android Developer", June 2012,
3207               <http://developer.android.com/reference/
3208               android/net/nsd/NsdManager.html>.
3210    [RFC2052]  Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
3211               location of services (DNS SRV)", RFC 2052, October 1996.
3213    [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
3214               Extensions", RFC 2132, March 1997.
3216    [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
3217               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
3218               RFC 2136, April 1997.
3220    [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
3221               Specification", RFC 2181, July 1997.
3223    [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
3224               Extensions", RFC 2535, March 1999.
3226    [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
3227               2671, August 1999.
3229    [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
3230               Wellington, "Secret Key Transaction Authentication for DNS
3231               (TSIG)", RFC 2845, May 2000.
3233    [RFC2930]  Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
3234               RR)", RFC 2930, September 2000.
3236    [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
3237               ( SIG(0)s )", RFC 2931, September 2000.
3239    [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
3240               Update", RFC 3007, November 2000.
3242    [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
3243               for Internationalized Domain Names in Applications
3244               (IDNA)", RFC 3492, March 2003.
3250 Cheshire & Krochmal          Standards Track                   [Page 58]
3252 RFC 6762                      Multicast DNS                February 2013
3255    [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
3256               Configuration of IPv4 Link-Local Addresses", RFC 3927, May
3257               2005.
3259    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
3260               Rose, "DNS Security Introduction and Requirements", RFC
3261               4033, March 2005.
3263    [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
3264               Architecture", RFC 4291, February 2006.
3266    [RFC4795]  Aboba, B., Thaler, D., and L. Esibov, "Link-local
3267               Multicast Name Resolution (LLMNR)", RFC 4795, January
3268               2007.
3270    [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
3271               "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
3272               September 2007.
3274    [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
3275               Address Autoconfiguration", RFC 4862, September 2007.
3277    [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
3278               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
3279               May 2008.
3281    [RFC5890]  Klensin, J., "Internationalized Domain Names for
3282               Applications (IDNA): Definitions and Document Framework",
3283               RFC 5890, August 2010.
3285    [RFC6281]  Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
3286               "Understanding Apple's Back to My Mac (BTMM) Service", RFC
3287               6281, June 2011.
3289    [RFC6760]  Cheshire, S. and M. Krochmal, "Requirements for a Protocol
3290               to Replace the AppleTalk Name Binding Protocol (NBP)", RFC
3291               6760, February 2013.
3293    [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
3294               Discovery", RFC 6763, February 2013.
3296    [Zeroconf] Cheshire, S. and D. Steinberg, "Zero Configuration
3297               Networking: The Definitive Guide", O'Reilly Media, Inc.,
3298               ISBN 0-596-10100-7, December 2005.
3306 Cheshire & Krochmal          Standards Track                   [Page 59]
3308 RFC 6762                      Multicast DNS                February 2013
3311 Appendix A.  Design Rationale for Choice of UDP Port Number
3313    Arguments were made for and against using UDP port 53, the standard
3314    Unicast DNS port.  Some of the arguments are given below.  The
3315    arguments for using a different port were greater in number and more
3316    compelling, so that option was ultimately selected.  The UDP port
3317    "5353" was selected for its mnemonic similarity to "53".
3319    Arguments for using UDP port 53:
3321    * This is "just DNS", so it should be the same port.
3323    * There is less work to be done updating old resolver libraries to do
3324      simple Multicast DNS queries.  Only the destination address need be
3325      changed.  In some cases, this can be achieved without any code
3326      changes, just by adding the address to a configuration
3327      file.
3329    Arguments for using a different port (UDP port 5353):
3331    * This is not "just DNS".  This is a DNS-like protocol, but
3332      different.
3334    * Changing resolver library code to use a different port number is
3335      not hard.  In some cases, this can be achieved without any code
3336      changes, just by adding the address to a
3337      configuration file.
3339    * Using the same port number makes it hard to run a Multicast DNS
3340      responder and a conventional Unicast DNS server on the same
3341      machine.  If a conventional Unicast DNS server wishes to implement
3342      Multicast DNS as well, it can still do that, by opening two
3343      sockets.  Having two different port numbers allows this
3344      flexibility.
3346    * Some VPN software hijacks all outgoing traffic to port 53 and
3347      redirects it to a special DNS server set up to serve those VPN
3348      clients while they are connected to the corporate network.  It is
3349      questionable whether this is the right thing to do, but it is
3350      common, and redirecting link-local multicast DNS packets to a
3351      remote server rarely produces any useful results.  It does mean,
3352      for example, that a user of such VPN software becomes unable to
3353      access their local network printer sitting on their desk right next
3354      to their computer.  Using a different UDP port helps avoid this
3355      particular problem.
3362 Cheshire & Krochmal          Standards Track                   [Page 60]
3364 RFC 6762                      Multicast DNS                February 2013
3367    * On many operating systems, unprivileged software may not send or
3368      receive packets on low-numbered ports.  This means that any
3369      software sending or receiving Multicast DNS packets on port 53
3370      would have to run as "root", which is an undesirable security risk.
3371      Using a higher-numbered UDP port avoids this restriction.
3373 Appendix B.  Design Rationale for Not Using Hashed Multicast Addresses
3375    Some discovery protocols use a range of multicast addresses, and
3376    determine the address to be used by a hash function of the name being
3377    sought.  Queries are sent via multicast to the address as indicated
3378    by the hash function, and responses are returned to the querier via
3379    unicast.  Particularly in IPv6, where multicast addresses are
3380    extremely plentiful, this approach is frequently advocated.  For
3381    example, IPv6 Neighbor Discovery [RFC4861] sends Neighbor
3382    Solicitation messages to the "solicited-node multicast address",
3383    which is computed as a function of the solicited IPv6 address.
3385    There are some disadvantages to using hashed multicast addresses like
3386    this in a service discovery protocol:
3388    * When a host has a large number of records with different names, the
3389      host may have to join a large number of multicast groups.  Each
3390      time a host joins or leaves a multicast group, this results in
3391      Internet Group Management Protocol (IGMP) or Multicast Listener
3392      Discovery (MLD) traffic on the network announcing this fact.
3393      Joining a large number of multicast groups can place undue burden
3394      on the Ethernet hardware, which typically supports a limited number
3395      of multicast addresses efficiently.  When this number is exceeded,
3396      the Ethernet hardware may have to resort to receiving all
3397      multicasts and passing them up to the host networking code for
3398      filtering in software, thereby defeating much of the point of using
3399      a multicast address range in the first place.  Finally, many IPv6
3400      stacks have a fixed limit IPV6_MAX_MEMBERSHIPS, and the code simply
3401      fails with an error if a client attempts to exceed this limit.
3402      Common values for IPV6_MAX_MEMBERSHIPS are 20 or 31.
3404    * Multiple questions cannot be placed in one packet if they don't all
3405      hash to the same multicast address.
3407    * Duplicate Question Suppression doesn't work if queriers are not
3408      seeing each other's queries.
3410    * Duplicate Answer Suppression doesn't work if responders are not
3411      seeing each other's responses.
3413    * Opportunistic Caching doesn't work.
3418 Cheshire & Krochmal          Standards Track                   [Page 61]
3420 RFC 6762                      Multicast DNS                February 2013
3423    * Ongoing Conflict Detection doesn't work.
3425 Appendix C.  Design Rationale for Maximum Multicast DNS Name Length
3427    Multicast DNS names may be up to 255 bytes long (in the on-the-wire
3428    message format), not counting the terminating zero byte at the end.
3430    "Domain Names - Implementation and Specification" [RFC1035] says:
3432       Various objects and parameters in the DNS have size limits.  They
3433       are listed below.  Some could be easily changed, others are more
3434       fundamental.
3436       labels          63 octets or less
3438       names           255 octets or less
3440       ...
3442       the total length of a domain name (i.e., label octets and label
3443       length octets) is restricted to 255 octets or less.
3445    This text does not state whether this 255-byte limit includes the
3446    terminating zero at the end of every name.
3448    Several factors lead us to conclude that the 255-byte limit does
3449    *not* include the terminating zero:
3451    o It is common in software engineering to have size limits that are a
3452      power of two, or a multiple of a power of two, for efficiency.  For
3453      example, an integer on a modern processor is typically 2, 4, or 8
3454      bytes, not 3 or 5 bytes.  The number 255 is not a power of two, nor
3455      is it to most people a particularly noteworthy number.  It is
3456      noteworthy to computer scientists for only one reason -- because it
3457      is exactly one *less* than a power of two.  When a size limit is
3458      exactly one less than a power of two, that suggests strongly that
3459      the one extra byte is being reserved for some specific reason -- in
3460      this case reserved, perhaps, to leave room for a terminating zero
3461      at the end.
3463    o In the case of DNS label lengths, the stated limit is 63 bytes.  As
3464      with the total name length, this limit is exactly one less than a
3465      power of two.  This label length limit also excludes the label
3466      length byte at the start of every label.  Including that extra
3467      byte, a 63-byte label takes 64 bytes of space in memory or in a DNS
3468      message.
3474 Cheshire & Krochmal          Standards Track                   [Page 62]
3476 RFC 6762                      Multicast DNS                February 2013
3479    o It is common in software engineering for the semantic "length" of
3480      an object to be one less than the number of bytes it takes to store
3481      that object.  For example, in C, strlen("foo") is 3, but
3482      sizeof("foo") (which includes the terminating zero byte at the end)
3483      is 4.
3485    o The text describing the total length of a domain name mentions
3486      explicitly that label length and data octets are included, but does
3487      not mention the terminating zero at the end.  The zero byte at the
3488      end of a domain name is not a label length.  Indeed, the value zero
3489      is chosen as the terminating marker precisely because it is not a
3490      legal length byte value -- DNS prohibits empty labels.  For
3491      example, a name like "bad..name." is not a valid domain name
3492      because it contains a zero-length label in the middle, which cannot
3493      be expressed in a DNS message, because software parsing the message
3494      would misinterpret a zero label-length byte as being a zero "end of
3495      name" marker instead.
3497    Finally, "Clarifications to the DNS Specification" [RFC2181] offers
3498    additional confirmation that, in the context of DNS specifications,
3499    the stated "length" of a domain name does not include the terminating
3500    zero byte at the end.  That document refers to the root name, which
3501    is typically written as "." and is represented in a DNS message by a
3502    single lone zero byte (i.e., zero bytes of data plus a terminating
3503    zero), as the "zero length full name":
3505       The zero length full name is defined as representing the root of
3506       the DNS tree, and is typically written and displayed as ".".
3508    This wording supports the interpretation that, in a DNS context, when
3509    talking about lengths of names, the terminating zero byte at the end
3510    is not counted.  If the root name (".") is considered to be zero
3511    length, then to be consistent, the length (for example) of "org" has
3512    to be 4 and the length of "ietf.org" has to be 9, as shown below:
3514                                                   ------
3515                                                  | 0x00 |   length = 0
3516                                                   ------
3518                              ------------------   ------
3519                             | 0x03 | o | r | g | | 0x00 |   length = 4
3520                              ------------------   ------
3522       -----------------------------------------   ------
3523      | 0x04 | i | e | t | f | 0x03 | o | r | g | | 0x00 |   length = 9
3524       -----------------------------------------   ------
3530 Cheshire & Krochmal          Standards Track                   [Page 63]
3532 RFC 6762                      Multicast DNS                February 2013
3535    This means that the maximum length of a domain name, as represented
3536    in a Multicast DNS message, up to but not including the final
3537    terminating zero, must not exceed 255 bytes.
3539    However, many Unicast DNS implementers have read these RFCs
3540    differently, and argue that the 255-byte limit does include the
3541    terminating zero, and that the "Clarifications to the DNS
3542    Specification" [RFC2181] statement that "." is the "zero length full
3543    name" was simply a mistake.
3545    Hence, implementers should be aware that other Unicast DNS
3546    implementations may limit the maximum domain name to 254 bytes plus a
3547    terminating zero, depending on how that implementer interpreted the
3548    DNS specifications.
3550    Compliant Multicast DNS implementations MUST support names up to 255
3551    bytes plus a terminating zero, i.e., 256 bytes total.
3553 Appendix D.  Benefits of Multicast Responses
3555    Some people have argued that sending responses via multicast is
3556    inefficient on the network.  In fact, using multicast responses can
3557    result in a net lowering of overall multicast traffic for a variety
3558    of reasons, and provides other benefits too:
3560    * Opportunistic Caching.  One multicast response can update the
3561      caches on all machines on the network.  If another machine later
3562      wants to issue the same query, and it already has the answer in its
3563      cache, it may not need to even transmit that multicast query on the
3564      network at all.
3566    * Duplicate Query Suppression.  When more than one machine has the
3567      same ongoing long-lived query running, every machine does not have
3568      to transmit its own independent query.  When one machine transmits
3569      a query, all the other hosts see the answers, so they can suppress
3570      their own queries.
3572    * Passive Observation Of Failures (POOF).  When a host sees a
3573      multicast query, but does not see the corresponding multicast
3574      response, it can use this information to promptly delete stale data
3575      from its cache.  To achieve the same level of user-interface
3576      quality and responsiveness without multicast responses would
3577      require lower cache lifetimes and more frequent network polling,
3578      resulting in a higher packet rate.
3580    * Passive Conflict Detection.  Just because a name has been
3581      previously verified to be unique does not guarantee it will
3582      continue to be so indefinitely.  By allowing all Multicast DNS
3586 Cheshire & Krochmal          Standards Track                   [Page 64]
3588 RFC 6762                      Multicast DNS                February 2013
3591      responders to constantly monitor their peers' responses, conflicts
3592      arising out of network topology changes can be promptly detected
3593      and resolved.  If responses were not sent via multicast, some other
3594      conflict detection mechanism would be needed, imposing its own
3595      additional burden on the network.
3597    * Use on devices with constrained memory resources: When using
3598      delayed responses to reduce network collisions, responders need to
3599      maintain a list recording to whom each answer should be sent.  The
3600      option of multicast responses allows responders with limited
3601      storage, which cannot store an arbitrarily long list of response
3602      addresses, to choose to fail-over to a single multicast response in
3603      place of multiple unicast responses, when appropriate.
3605    * Overlayed Subnets.  In the case of overlayed subnets, multicast
3606      responses allow a receiver to know with certainty that a response
3607      originated on the local link, even when its source address may
3608      apparently suggest otherwise.
3610    * Robustness in the face of misconfiguration: Link-local multicast
3611      transcends virtually every conceivable network misconfiguration.
3612      Even if you have a collection of devices where every device's IP
3613      address, subnet mask, default gateway, and DNS server address are
3614      all wrong, packets sent by any of those devices addressed to a
3615      link-local multicast destination address will still be delivered to
3616      all peers on the local link.  This can be extremely helpful when
3617      diagnosing and rectifying network problems, since it facilitates a
3618      direct communication channel between client and server that works
3619      without reliance on ARP, IP routing tables, etc.  Being able to
3620      discover what IP address a device has (or thinks it has) is
3621      frequently a very valuable first step in diagnosing why it is
3622      unable to communicate on the local network.
3624 Appendix E.  Design Rationale for Encoding Negative Responses
3626    Alternative methods of asserting nonexistence were considered, such
3627    as using an NXDOMAIN response, or emitting a resource record with
3628    zero-length rdata.
3630    Using an NXDOMAIN response does not work well with Multicast DNS.  A
3631    Unicast DNS NXDOMAIN response applies to the entire message, but for
3632    efficiency Multicast DNS allows (and encourages) multiple responses
3633    in a single message.  If the error code in the header were NXDOMAIN,
3634    it would not be clear to which name(s) that error code applied.
3636    Asserting nonexistence by emitting a resource record with zero-length
3637    rdata would mean that there would be no way to differentiate between
3638    a record that doesn't exist, and a record that does exist, with zero-
3642 Cheshire & Krochmal          Standards Track                   [Page 65]
3644 RFC 6762                      Multicast DNS                February 2013
3647    length rdata.  By analogy, most file systems today allow empty files,
3648    so a file that exists with zero bytes of data is not considered
3649    equivalent to a filename that does not exist.
3651    A benefit of asserting nonexistence through NSEC records instead of
3652    through NXDOMAIN responses is that NSEC records can be added to the
3653    Additional Section of a DNS response to offer additional information
3654    beyond what the querier explicitly requested.  For example, in
3655    response to an SRV query, a responder should include A record(s)
3656    giving its IPv4 addresses in the Additional Section, and an NSEC
3657    record indicating which other types it does or does not have for this
3658    name.  If the responder is running on a host that does not support
3659    IPv6 (or does support IPv6 but currently has no IPv6 address on that
3660    interface) then this NSEC record in the Additional Section will
3661    indicate this absence of AAAA records.  In effect, the responder is
3662    saying, "Here's my SRV record, and here are my IPv4 addresses, and
3663    no, I don't have any IPv6 addresses, so don't waste your time
3664    asking".  Without this information in the Additional Section, it
3665    would take the querier an additional round-trip to perform an
3666    additional query to ascertain that the target host has no AAAA
3667    records.  (Arguably Unicast DNS could also benefit from this ability
3668    to express nonexistence in the Additional Section, but that is
3669    outside the scope of this document.)
3671 Appendix F.  Use of UTF-8
3673    After many years of debate, as a result of the perceived need to
3674    accommodate certain DNS implementations that apparently couldn't
3675    handle any character that's not a letter, digit, or hyphen (and
3676    apparently never would be updated to remedy this limitation), the
3677    Unicast DNS community settled on an extremely baroque encoding called
3678    "Punycode" [RFC3492].  Punycode is a remarkably ingenious encoding
3679    solution, but it is complicated, hard to understand, and hard to
3680    implement, using sophisticated techniques including insertion unsort
3681    coding, generalized variable-length integers, and bias adaptation.
3682    The resulting encoding is remarkably compact given the constraints,
3683    but it's still not as good as simple straightforward UTF-8, and it's
3684    hard even to predict whether a given input string will encode to a
3685    Punycode string that fits within DNS's 63-byte limit, except by
3686    simply trying the encoding and seeing whether it fits.  Indeed, the
3687    encoded size depends not only on the input characters, but on the
3688    order they appear, so the same set of characters may or may not
3689    encode to a legal Punycode string that fits within DNS's 63-byte
3690    limit, depending on the order the characters appear.  This is
3691    extremely hard to present in a user interface that explains to users
3692    why one name is allowed, but another name containing the exact same
3693    characters is not.  Neither Punycode nor any other of the "ASCII-
3694    Compatible Encodings" [RFC5890] proposed for Unicast DNS may be used
3698 Cheshire & Krochmal          Standards Track                   [Page 66]
3700 RFC 6762                      Multicast DNS                February 2013
3703    in Multicast DNS messages.  Any text being represented internally in
3704    some other representation must be converted to canonical precomposed
3705    UTF-8 before being placed in any Multicast DNS message.
3707 Appendix G.  Private DNS Namespaces
3709    The special treatment of names ending in ".local." has been
3710    implemented in Macintosh computers since the days of Mac OS 9, and
3711    continues today in Mac OS X and iOS.  There are also implementations
3712    for Microsoft Windows [B4W], Linux, and other platforms.
3714    Some network operators setting up private internal networks
3715    ("intranets") have used unregistered top-level domains, and some may
3716    have used the ".local" top-level domain.  Using ".local" as a private
3717    top-level domain conflicts with Multicast DNS and may cause problems
3718    for users.  Clients can be configured to send both Multicast and
3719    Unicast DNS queries in parallel for these names, and this does allow
3720    names to be looked up both ways, but this results in additional
3721    network traffic and additional delays in name resolution, as well as
3722    potentially creating user confusion when it is not clear whether any
3723    given result was received via link-local multicast from a peer on the
3724    same link, or from the configured unicast name server.  Because of
3725    this, we recommend against using ".local" as a private Unicast DNS
3726    top-level domain.  We do not recommend use of unregistered top-level
3727    domains at all, but should network operators decide to do this, the
3728    following top-level domains have been used on private internal
3729    networks without the problems caused by trying to reuse ".local." for
3730    this purpose:
3732       .intranet.
3733       .internal.
3734       .private.
3735       .corp.
3736       .home.
3737       .lan.
3739 Appendix H.  Deployment History
3741    In July 1997, in an email to the net-thinkers@thumper.vmeng.com
3742    mailing list, Stuart Cheshire first proposed the idea of running the
3743    AppleTalk Name Binding Protocol [RFC6760] over IP.  As a result of
3744    this and related IETF discussions, the IETF Zeroconf working group
3745    was chartered September 1999.  After various working group
3746    discussions and other informal IETF discussions, several Internet-
3747    Drafts were written that were loosely related to the general themes
3748    of DNS and multicast, but did not address the service discovery
3749    aspect of NBP.
3754 Cheshire & Krochmal          Standards Track                   [Page 67]
3756 RFC 6762                      Multicast DNS                February 2013
3759    In April 2000, Stuart Cheshire registered IPv4 multicast address
3760 with IANA [MC4] and began writing code to test and
3761    develop the idea of performing NBP-like service discovery using
3762    Multicast DNS, which was documented in a group of three Internet-
3763    Drafts:
3765    o "Requirements for a Protocol to Replace the AppleTalk Name Binding
3766      Protocol (NBP)" [RFC6760] is an overview explaining the AppleTalk
3767      Name Binding Protocol, because many in the IETF community had
3768      little first-hand experience using AppleTalk, and confusion in the
3769      IETF community about what AppleTalk NBP did was causing confusion
3770      about what would be required in an IP-based replacement.
3772    o "Discovering Named Instances of Abstract Services using DNS" [NIAS]
3773      proposed a way to perform NBP-like service discovery using DNS-
3774      compatible names and record types.
3776    o "Multicast DNS" (this document) specifies a way to transport those
3777      DNS-compatible queries and responses using IP multicast, for zero-
3778      configuration environments where no conventional Unicast DNS server
3779      was available.
3781    In 2001, an update to Mac OS 9 added resolver library support for
3782    host name lookup using Multicast DNS.  If the user typed a name such
3783    as "MyPrinter.local." into any piece of networking software that used
3784    the standard Mac OS 9 name lookup APIs, then those name lookup APIs
3785    would recognize the name as a dot-local name and query for it by
3786    sending simple one-shot Multicast DNS queries to
3787    This enabled the user to, for example, enter the name
3788    "MyPrinter.local." into their web browser in order to view a
3789    printer's status and configuration web page, or enter the name
3790    "MyPrinter.local." into the printer setup utility to create a print
3791    queue for printing documents on that printer.
3793    Multicast DNS responder software, with full service discovery, first
3794    began shipping to end users in volume with the launch of Mac OS X
3795    10.2 "Jaguar" in August 2002, and network printer makers (who had
3796    historically supported AppleTalk in their network printers and were
3797    receptive to IP-based technologies that could offer them similar
3798    ease-of-use) started adopting Multicast DNS shortly thereafter.
3800    In September 2002, Apple released the source code for the
3801    mDNSResponder daemon as Open Source under Apple's standard Apple
3802    Public Source License (APSL).
3804    Multicast DNS responder software became available for Microsoft
3805    Windows users in June 2004 with the launch of Apple's "Rendezvous for
3806    Windows" (now "Bonjour for Windows"), both in executable form (a
3810 Cheshire & Krochmal          Standards Track                   [Page 68]
3812 RFC 6762                      Multicast DNS                February 2013
3815    downloadable installer for end users) and as Open Source (one of the
3816    supported platforms within Apple's body of cross-platform code in the
3817    publicly accessible mDNSResponder CVS source code repository) [BJ].
3819    In August 2006, Apple re-licensed the cross-platform mDNSResponder
3820    source code under the Apache License, Version 2.0.
3822    In addition to desktop and laptop computers running Mac OS X and
3823    Microsoft Windows, Multicast DNS is now implemented in a wide range
3824    of hardware devices, such as Apple's "AirPort" wireless base
3825    stations, iPhone and iPad, and in home gateways from other vendors,
3826    network printers, network cameras, TiVo DVRs, etc.
3828    The Open Source community has produced many independent
3829    implementations of Multicast DNS, some in C like Apple's
3830    mDNSResponder daemon, and others in a variety of different languages
3831    including Java, Python, Perl, and C#/Mono.
3833    In January 2007, the IETF published the Informational RFC "Link-Local
3834    Multicast Name Resolution (LLMNR)" [RFC4795], which is substantially
3835    similar to Multicast DNS, but incompatible in some small but
3836    important ways.  In particular, the LLMNR design explicitly excluded
3837    support for service discovery, which made it an unsuitable candidate
3838    for a protocol to replace AppleTalk NBP [RFC6760].
3840    While the original focus of Multicast DNS and DNS-Based Service
3841    Discovery was for zero-configuration environments without a
3842    conventional Unicast DNS server, DNS-Based Service Discovery also
3843    works using Unicast DNS servers, using DNS Update [RFC2136] [RFC3007]
3844    to create service discovery records and standard DNS queries to query
3845    for them.  Apple's Back to My Mac service, launched with Mac OS X
3846    10.5 "Leopard" in October 2007, uses DNS-Based Service Discovery over
3847    Unicast DNS [RFC6281].
3849    In June 2012, Google's Android operating system added native support
3850    for DNS-SD and Multicast DNS with the android.net.nsd.NsdManager
3851    class in Android 4.1 "Jelly Bean" (API Level 16) [NSD].
3866 Cheshire & Krochmal          Standards Track                   [Page 69]
3868 RFC 6762                      Multicast DNS                February 2013
3871 Authors' Addresses
3873    Stuart Cheshire
3874    Apple Inc.
3875    1 Infinite Loop
3876    Cupertino, CA  95014
3877    USA
3879    Phone: +1 408 974 3207
3880    EMail: cheshire@apple.com
3883    Marc Krochmal
3884    Apple Inc.
3885    1 Infinite Loop
3886    Cupertino, CA  95014
3887    USA
3889    Phone: +1 408 974 4368
3890    EMail: marc@apple.com
3922 Cheshire & Krochmal          Standards Track                   [Page 70]

This page was automatically generated by LXR 0.3.1.  •  OpenWrt