1 Internet Engineering Task Force (IETF)                       S. Cheshire   
    2 Request for Comments: 6762                                   M. Krochmal   
    3 Category: Standards Track                                     Apple Inc.   
    4 ISSN: 2070-1721                                            February 2013   
    7                              Multicast DNS                                 
    9 Abstract                                                                   
   11    As networked devices become smaller, more portable, and more            
   12    ubiquitous, the ability to operate with less configured                 
   13    infrastructure is increasingly important.  In particular, the ability   
   14    to look up DNS resource record data types (including, but not limited   
   15    to, host names) in the absence of a conventional managed DNS server     
   16    is useful.                                                              
   18    Multicast DNS (mDNS) provides the ability to perform DNS-like           
   19    operations on the local link in the absence of any conventional         
   20    Unicast DNS server.  In addition, Multicast DNS designates a portion    
   21    of the DNS namespace to be free for local use, without the need to      
   22    pay any annual fee, and without the need to set up delegations or       
   23    otherwise configure a conventional DNS server to answer for those       
   24    names.                                                                  
   26    The primary benefits of Multicast DNS names are that (i) they require   
   27    little or no administration or configuration to set them up, (ii)       
   28    they work when no infrastructure is present, and (iii) they work        
   29    during infrastructure failures.                                         
   31 Status of This Memo                                                        
   33    This is an Internet Standards Track document.                           
   35    This document is a product of the Internet Engineering Task Force       
   36    (IETF).  It represents the consensus of the IETF community.  It has     
   37    received public review and has been approved for publication by the     
   38    Internet Engineering Steering Group (IESG).  Further information on     
   39    Internet Standards is available in Section 2 of RFC 5741.               
   41    Information about the current status of this document, any errata,      
   42    and how to provide feedback on it may be obtained at                    
   43    http://www.rfc-editor.org/info/rfc6762.                                 
   52 Cheshire & Krochmal          Standards Track                    [Page 1]   

   53 RFC 6762                      Multicast DNS                February 2013   
   56 Copyright Notice                                                           
   58    Copyright (c) 2013 IETF Trust and the persons identified as the         
   59    document authors.  All rights reserved.                                 
   61    This document is subject to BCP 78 and the IETF Trust's Legal           
   62    Provisions Relating to IETF Documents                                   
   63    (http://trustee.ietf.org/license-info) in effect on the date of         
   64    publication of this document.  Please review these documents            
   65    carefully, as they describe your rights and restrictions with respect   
   66    to this document.  Code Components extracted from this document must    
   67    include Simplified BSD License text as described in Section 4.e of      
   68    the Trust Legal Provisions and are provided without warranty as         
   69    described in the Simplified BSD License.                                
   71    This document may contain material from IETF Documents or IETF          
   72    Contributions published or made publicly available before November      
   73    10, 2008.  The person(s) controlling the copyright in some of this      
   74    material may not have granted the IETF Trust the right to allow         
   75    modifications of such material outside the IETF Standards Process.      
   76    Without obtaining an adequate license from the person(s) controlling    
   77    the copyright in such materials, this document may not be modified      
   78    outside the IETF Standards Process, and derivative works of it may      
   79    not be created outside the IETF Standards Process, except to format     
   80    it for publication as an RFC or to translate it into languages other    
   81    than English.                                                           
  107 Cheshire & Krochmal          Standards Track                    [Page 2]   

  108 RFC 6762                      Multicast DNS                February 2013   
  111 Table of Contents                                                          
  113    1. Introduction ....................................................4   
  114    2. Conventions and Terminology Used in This Document ...............4   
  115    3. Multicast DNS Names .............................................5   
  116    4. Reverse Address Mapping .........................................7   
  117    5. Querying ........................................................8   
  118    6. Responding .....................................................13   
  119    7. Traffic Reduction ..............................................22   
  120    8. Probing and Announcing on Startup ..............................25   
  121    9. Conflict Resolution ............................................31   
  122    10. Resource Record TTL Values and Cache Coherency ................33   
  123    11. Source Address Check ..........................................38   
  124    12. Special Characteristics of Multicast DNS Domains ..............40   
  125    13. Enabling and Disabling Multicast DNS ..........................41   
  126    14. Considerations for Multiple Interfaces ........................42   
  127    15. Considerations for Multiple Responders on the Same Machine ....43   
  128    16. Multicast DNS Character Set ...................................45   
  129    17. Multicast DNS Message Size ....................................46   
  130    18. Multicast DNS Message Format ..................................47   
  131    19. Summary of Differences between Multicast DNS and Unicast DNS ..51   
  132    20. IPv6 Considerations ...........................................52   
  133    21. Security Considerations .......................................52   
  134    22. IANA Considerations ...........................................53   
  135    23. Acknowledgments ...............................................56   
  136    24. References ....................................................56   
  137    Appendix A. Design Rationale for Choice of UDP Port Number ........60   
  138    Appendix B. Design Rationale for Not Using Hashed Multicast             
  139                Addresses .............................................61   
  140    Appendix C. Design Rationale for Maximum Multicast DNS Name             
  141                Length ................................................62   
  142    Appendix D. Benefits of Multicast Responses .......................64   
  143    Appendix E. Design Rationale for Encoding Negative Responses ......65   
  144    Appendix F. Use of UTF-8 ..........................................66   
  145    Appendix G. Private DNS Namespaces ................................67   
  146    Appendix H. Deployment History ....................................67   
  162 Cheshire & Krochmal          Standards Track                    [Page 3]   

  163 RFC 6762                      Multicast DNS                February 2013   
  166 1.  Introduction                                                           
  168    Multicast DNS and its companion technology DNS-Based Service            
  169    Discovery [RFC6763] were created to provide IP networking with the      
  170    ease-of-use and autoconfiguration for which AppleTalk was well-known    
  171    [RFC6760].  When reading this document, familiarity with the concepts   
  172    of Zero Configuration Networking [Zeroconf] and automatic link-local    
  173    addressing [RFC3927] [RFC4862] is helpful.                              
  175    Multicast DNS borrows heavily from the existing DNS protocol            
  176    [RFC1034] [RFC1035] [RFC6195], using the existing DNS message           
  177    structure, name syntax, and resource record types.  This document       
  178    specifies no new operation codes or response codes.  This document      
  179    describes how clients send DNS-like queries via IP multicast, and how   
  180    a collection of hosts cooperate to collectively answer those queries    
  181    in a useful manner.                                                     
  183 2.  Conventions and Terminology Used in This Document                      
  185    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  186    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this    
  187    document are to be interpreted as described in "Key words for use in    
  188    RFCs to Indicate Requirement Levels" [RFC2119].                         
  190    When this document uses the term "Multicast DNS", it should be taken    
  191    to mean: "Clients performing DNS-like queries for DNS-like resource     
  192    records by sending DNS-like UDP query and response messages over IP     
  193    Multicast to UDP port 5353".  The design rationale for selecting UDP    
  194    port 5353 is discussed in Appendix A.                                   
  196    This document uses the term "host name" in the strict sense to mean a   
  197    fully qualified domain name that has an IPv4 or IPv6 address record.    
  198    It does not use the term "host name" in the commonly used but           
  199    incorrect sense to mean just the first DNS label of a host's fully      
  200    qualified domain name.                                                  
  202    A DNS (or mDNS) packet contains an IP Time to Live (TTL) in the IP      
  203    header, which is effectively a hop-count limit for the packet, to       
  204    guard against routing loops.  Each resource record also contains a      
  205    TTL, which is the number of seconds for which the resource record may   
  206    be cached.  This document uses the term "IP TTL" to refer to the IP     
  207    header TTL (hop limit), and the term "RR TTL" or just "TTL" to refer    
  208    to the resource record TTL (cache lifetime).                            
  210    DNS-format messages contain a header, a Question Section, then          
  211    Answer, Authority, and Additional Record Sections.  The Answer,         
  212    Authority, and Additional Record Sections all hold resource records     
  217 Cheshire & Krochmal          Standards Track                    [Page 4]   

  218 RFC 6762                      Multicast DNS                February 2013   
  221    in the same format.  Where this document describes issues that apply    
  222    equally to all three sections, it uses the term "Resource Record        
  223    Sections" to refer collectively to these three sections.                
  225    This document uses the terms "shared" and "unique" when referring to    
  226    resource record sets [RFC1034]:                                         
  228       A "shared" resource record set is one where several Multicast DNS    
  229       responders may have records with the same name, rrtype, and          
  230       rrclass, and several responders may respond to a particular query.   
  232       A "unique" resource record set is one where all the records with     
  233       that name, rrtype, and rrclass are conceptually under the control    
  234       or ownership of a single responder, and it is expected that at       
  235       most one responder should respond to a query for that name,          
  236       rrtype, and rrclass.  Before claiming ownership of a unique          
  237       resource record set, a responder MUST probe to verify that no        
  238       other responder already claims ownership of that set, as described   
  239       in Section 8.1, "Probing".  (For fault-tolerance and other           
  240       reasons, sometimes it is permissible to have more than one           
  241       responder answering for a particular "unique" resource record set,   
  242       but such cooperating responders MUST give answers containing         
  243       identical rdata for these records.  If they do not give answers      
  244       containing identical rdata, then the probing step will reject the    
  245       data as being inconsistent with what is already being advertised     
  246       on the network for those names.)                                     
  248    Strictly speaking, the terms "shared" and "unique" apply to resource    
  249    record sets, not to individual resource records.  However, it is        
  250    sometimes convenient to talk of "shared resource records" and "unique   
  251    resource records".  When used this way, the terms should be             
  252    understood to mean a record that is a member of a "shared" or           
  253    "unique" resource record set, respectively.                             
  255 3.  Multicast DNS Names                                                    
  257    A host that belongs to an organization or individual who has control    
  258    over some portion of the DNS namespace can be assigned a globally       
  259    unique name within that portion of the DNS namespace, such as,          
  260    "cheshire.example.com.".  For those of us who have this luxury, this    
  261    works very well.  However, the majority of home computer users do not   
  262    have easy access to any portion of the global DNS namespace within      
  263    which they have the authority to create names.  This leaves the         
  264    majority of home computers effectively anonymous for practical          
  265    purposes.                                                               
  272 Cheshire & Krochmal          Standards Track                    [Page 5]   

  273 RFC 6762                      Multicast DNS                February 2013   
  276    To remedy this problem, this document allows any computer user to       
  277    elect to give their computers link-local Multicast DNS host names of    
  278    the form: "single-dns-label.local.".  For example, a laptop computer    
  279    may answer to the name "MyComputer.local.".  Any computer user is       
  280    granted the authority to name their computer this way, provided that    
  281    the chosen host name is not already in use on that link.  Having        
  282    named their computer this way, the user has the authority to continue   
  283    utilizing that name until such time as a name conflict occurs on the    
  284    link that is not resolved in the user's favor.  If this happens, the    
  285    computer (or its human user) MUST cease using the name, and SHOULD      
  286    attempt to allocate a new unique name for use on that link.  These      
  287    conflicts are expected to be relatively rare for people who choose      
  288    reasonably imaginative names, but it is still important to have a       
  289    mechanism in place to handle them when they happen.                     
  291    This document specifies that the DNS top-level domain ".local." is a    
  292    special domain with special semantics, namely that any fully            
  293    qualified name ending in ".local." is link-local, and names within      
  294    this domain are meaningful only on the link where they originate.       
  295    This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6    
  296    addresses in the FE80::/10 prefix, which are link-local and             
  297    meaningful only on the link where they originate.                       
  299    Any DNS query for a name ending with ".local." MUST be sent to the      
  300    mDNS IPv4 link-local multicast address (or its IPv6         
  301    equivalent FF02::FB).  The design rationale for using a fixed           
  302    multicast address instead of selecting from a range of multicast        
  303    addresses using a hash function is discussed in Appendix B.             
  304    Implementers MAY choose to look up such names concurrently via other    
  305    mechanisms (e.g., Unicast DNS) and coalesce the results in some         
  306    fashion.  Implementers choosing to do this should be aware of the       
  307    potential for user confusion when a given name can produce different    
  308    results depending on external network conditions (such as, but not      
  309    limited to, which name lookup mechanism responds faster).               
  311    It is unimportant whether a name ending with ".local." occurred         
  312    because the user explicitly typed in a fully qualified domain name      
  313    ending in ".local.", or because the user entered an unqualified         
  314    domain name and the host software appended the suffix ".local."         
  315    because that suffix appears in the user's search list.  The ".local."   
  316    suffix could appear in the search list because the user manually        
  317    configured it, or because it was received via DHCP [RFC2132] or via     
  318    any other mechanism for configuring the DNS search list.  In this       
  319    respect the ".local." suffix is treated no differently from any other   
  320    search domain that might appear in the DNS search list.                 
  327 Cheshire & Krochmal          Standards Track                    [Page 6]   

  328 RFC 6762                      Multicast DNS                February 2013   
  331    DNS queries for names that do not end with ".local." MAY be sent to     
  332    the mDNS multicast address, if no other conventional DNS server is      
  333    available.  This can allow hosts on the same link to continue           
  334    communicating using each other's globally unique DNS names during       
  335    network outages that disrupt communication with the greater Internet.   
  336    When resolving global names via local multicast, it is even more        
  337    important to use DNS Security Extensions (DNSSEC) [RFC4033] or other    
  338    security mechanisms to ensure that the response is trustworthy.         
  339    Resolving global names via local multicast is a contentious issue,      
  340    and this document does not discuss it further, instead concentrating    
  341    on the issue of resolving local names using DNS messages sent to a      
  342    multicast address.                                                      
  344    This document recommends a single flat namespace for dot-local host     
  345    names, (i.e., the names of DNS "A" and "AAAA" records, which map        
  346    names to IPv4 and IPv6 addresses), but other DNS record types (such     
  347    as those used by DNS-Based Service Discovery [RFC6763]) may contain     
  348    as many labels as appropriate for the desired usage, up to a maximum    
  349    of 255 bytes, plus a terminating zero byte at the end.  Name length     
  350    issues are discussed further in Appendix C.                             
  352    Enforcing uniqueness of host names is probably desirable in the         
  353    common case, but this document does not mandate that.  It is            
  354    permissible for a collection of coordinated hosts to agree to           
  355    maintain multiple DNS address records with the same name, possibly      
  356    for load-balancing or fault-tolerance reasons.  This document does      
  357    not take a position on whether that is sensible.  It is important       
  358    that both modes of operation be supported.  The Multicast DNS           
  359    protocol allows hosts to verify and maintain unique names for           
  360    resource records where that behavior is desired, and it also allows     
  361    hosts to maintain multiple resource records with a single shared name   
  362    where that behavior is desired.  This consideration applies to all      
  363    resource records, not just address records (host names).  In summary:   
  364    It is required that the protocol have the ability to detect and         
  365    handle name conflicts, but it is not required that this ability be      
  366    used for every record.                                                  
  368 4.  Reverse Address Mapping                                                
  370    Like ".local.", the IPv4 and IPv6 reverse mapping domains are also      
  371    defined to be link-local:                                               
  373       Any DNS query for a name ending with "254.169.in-addr.arpa." MUST    
  374       be sent to the mDNS IPv4 link-local multicast address    
  375       or the mDNS IPv6 multicast address FF02::FB.  Since names under      
  376       this domain correspond to IPv4 link-local addresses, it is logical   
  377       that the local link is the best place to find information            
  378       pertaining to those names.                                           
  382 Cheshire & Krochmal          Standards Track                    [Page 7]   

  383 RFC 6762                      Multicast DNS                February 2013   
  386       Likewise, any DNS query for a name within the reverse mapping        
  387       domains for IPv6 link-local addresses ("8.e.f.ip6.arpa.",            
  388       "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.") MUST    
  389       be sent to the mDNS IPv6 link-local multicast address FF02::FB or    
  390       the mDNS IPv4 link-local multicast address              
  392 5.  Querying                                                               
  394    There are two kinds of Multicast DNS queries: one-shot queries of the   
  395    kind made by legacy DNS resolvers, and continuous, ongoing Multicast    
  396    DNS queries made by fully compliant Multicast DNS queriers, which       
  397    support asynchronous operations including DNS-Based Service Discovery   
  398    [RFC6763].                                                              
  400    Except in the rare case of a Multicast DNS responder that is            
  401    advertising only shared resource records and no unique records, a       
  402    Multicast DNS responder MUST also implement a Multicast DNS querier     
  403    so that it can first verify the uniqueness of those records before it   
  404    begins answering queries for them.                                      
  406 5.1.  One-Shot Multicast DNS Queries                                       
  408    The most basic kind of Multicast DNS client may simply send standard    
  409    DNS queries blindly to, without necessarily even       
  410    being aware of what a multicast address is.  This change can            
  411    typically be implemented with just a few lines of code in an existing   
  412    DNS resolver library.  If a name being queried falls within one of      
  413    the reserved Multicast DNS domains (see Sections 3 and 4), then,        
  414    rather than using the configured Unicast DNS server address, the        
  415    query is instead sent to (or its IPv6 equivalent       
  416    [FF02::FB]:5353).  Typically, the timeout would also be shortened to    
  417    two or three seconds.  It's possible to make a minimal Multicast DNS    
  418    resolver with only these simple changes.  These queries are typically   
  419    done using a high-numbered ephemeral UDP source port, but regardless    
  420    of whether they are sent from a dynamic port or from a fixed port,      
  421    these queries MUST NOT be sent using UDP source port 5353, since        
  422    using UDP source port 5353 signals the presence of a fully compliant    
  423    Multicast DNS querier, as described below.                              
  425    A simple DNS resolver like this will typically just take the first      
  426    response it receives.  It will not listen for additional UDP            
  427    responses, but in many instances this may not be a serious problem.     
  428    If a user types "http://MyPrinter.local." into their web browser, and   
  429    their simple DNS resolver just takes the first response it receives,    
  430    and the user gets to see the status and configuration web page for      
  431    their printer, then the protocol has met the user's needs in this       
  432    case.                                                                   
  437 Cheshire & Krochmal          Standards Track                    [Page 8]   

  438 RFC 6762                      Multicast DNS                February 2013   
  441    While a basic DNS resolver like this may be adequate for simple host    
  442    name lookup, it may not get ideal behavior in other cases.              
  443    Additional refinements to create a fully compliant Multicast DNS        
  444    querier are described below.                                            
  446 5.2.  Continuous Multicast DNS Querying                                    
  448    In one-shot queries, the underlying assumption is that the              
  449    transaction begins when the application issues a query, and ends when   
  450    the first response is received.  There is another type of query         
  451    operation that is more asynchronous, in which having received one       
  452    response is not necessarily an indication that there will be no more    
  453    relevant responses, and the querying operation continues until no       
  454    further responses are required.  Determining when no further            
  455    responses are required depends on the type of operation being           
  456    performed.  If the operation is looking up the IPv4 and IPv6            
  457    addresses of another host, then no further responses are required       
  458    once a successful connection has been made to one of those IPv4 or      
  459    IPv6 addresses.  If the operation is browsing to present the user       
  460    with a list of DNS-SD services found on the network [RFC6763], then     
  461    no further responses are required once the user indicates this to the   
  462    user-interface software, e.g., by closing the network browsing window   
  463    that was displaying the list of discovered services.                    
  465    Imagine some hypothetical software that allows users to discover        
  466    network printers.  The user wishes to discover all printers on the      
  467    local network, not only the printer that is quickest to respond.        
  468    When the user is actively looking for a network printer to use, they    
  469    open a network browsing window that displays the list of discovered     
  470    printers.  It would be convenient for the user if they could rely on    
  471    this list of network printers to stay up to date as network printers    
  472    come and go, rather than displaying out-of-date stale information,      
  473    and requiring the user explicitly to click a "refresh" button any       
  474    time they want to see accurate information (which, from the moment it   
  475    is displayed, is itself already beginning to become out-of-date and     
  476    stale).  If we are to display a continuously updated live list like     
  477    this, we need to be able to do it efficiently, without naive constant   
  478    polling, which would be an unreasonable burden on the network.  It is   
  479    not expected that all users will be browsing to discover new printers   
  480    all the time, but when a user is browsing to discover service           
  481    instances for an extended period, we want to be able to support that    
  482    operation efficiently.                                                  
  484    Therefore, when retransmitting Multicast DNS queries to implement       
  485    this kind of continuous monitoring, the interval between the first      
  486    two queries MUST be at least one second, the intervals between          
  487    successive queries MUST increase by at least a factor of two, and the   
  488    querier MUST implement Known-Answer Suppression, as described below     
  492 Cheshire & Krochmal          Standards Track                    [Page 9]   

  493 RFC 6762                      Multicast DNS                February 2013   
  496    in Section 7.1.  The Known-Answer Suppression mechanism tells           
  497    responders which answers are already known to the querier, thereby      
  498    allowing responders to avoid wasting network capacity with pointless    
  499    repeated transmission of those answers.  A querier retransmits its      
  500    question because it wishes to receive answers it may have missed the    
  501    first time, not because it wants additional duplicate copies of         
  502    answers it already received.  Failure to implement Known-Answer         
  503    Suppression can result in unacceptable levels of network traffic.       
  504    When the interval between queries reaches or exceeds 60 minutes, a      
  505    querier MAY cap the interval to a maximum of 60 minutes, and perform    
  506    subsequent queries at a steady-state rate of one query per hour.  To    
  507    avoid accidental synchronization when, for some reason, multiple        
  508    clients begin querying at exactly the same moment (e.g., because of     
  509    some common external trigger event), a Multicast DNS querier SHOULD     
  510    also delay the first query of the series by a randomly chosen amount    
  511    in the range 20-120 ms.                                                 
  513    When a Multicast DNS querier receives an answer, the answer contains    
  514    a TTL value that indicates for how many seconds this answer is valid.   
  515    After this interval has passed, the answer will no longer be valid      
  516    and SHOULD be deleted from the cache.  Before the record expiry time    
  517    is reached, a Multicast DNS querier that has local clients with an      
  518    active interest in the state of that record (e.g., a network browsing   
  519    window displaying a list of discovered services to the user) SHOULD     
  520    reissue its query to determine whether the record is still valid.       
  522    To perform this cache maintenance, a Multicast DNS querier should       
  523    plan to retransmit its query after at least 50% of the record           
  524    lifetime has elapsed.  This document recommends the following           
  525    specific strategy.                                                      
  527    The querier should plan to issue a query at 80% of the record           
  528    lifetime, and then if no answer is received, at 85%, 90%, and 95%.      
  529    If an answer is received, then the remaining TTL is reset to the        
  530    value given in the answer, and this process repeats for as long as      
  531    the Multicast DNS querier has an ongoing interest in the record.  If    
  532    no answer is received after four queries, the record is deleted when    
  533    it reaches 100% of its lifetime.  A Multicast DNS querier MUST NOT      
  534    perform this cache maintenance for records for which it has no local    
  535    clients with an active interest.  If the expiry of a particular         
  536    record from the cache would result in no net effect to any client       
  537    software running on the querier device, and no visible effect to the    
  538    human user, then there is no reason for the Multicast DNS querier to    
  539    waste network capacity checking whether the record remains valid.       
  547 Cheshire & Krochmal          Standards Track                   [Page 10]   

  548 RFC 6762                      Multicast DNS                February 2013   
  551    To avoid the case where multiple Multicast DNS queriers on a network    
  552    all issue their queries simultaneously, a random variation of 2% of     
  553    the record TTL should be added, so that queries are scheduled to be     
  554    performed at 80-82%, 85-87%, 90-92%, and then 95-97% of the TTL.        
  556    An additional efficiency optimization SHOULD be performed when a        
  557    Multicast DNS response is received containing a unique answer (as       
  558    indicated by the cache-flush bit being set, described in Section        
  559    10.2, "Announcements to Flush Outdated Cache Entries").  In this        
  560    case, there is no need for the querier to continue issuing a stream     
  561    of queries with exponentially increasing intervals, since the receipt   
  562    of a unique answer is a good indication that no other answers will be   
  563    forthcoming.  In this case, the Multicast DNS querier SHOULD plan to    
  564    issue its next query for this record at 80-82% of the record's TTL,     
  565    as described above.                                                     
  567    A compliant Multicast DNS querier, which implements the rules           
  568    specified in this document, MUST send its Multicast DNS queries from    
  569    UDP source port 5353 (the well-known port assigned to mDNS), and MUST   
  570    listen for Multicast DNS replies sent to UDP destination port 5353 at   
  571    the mDNS link-local multicast address ( and/or its IPv6      
  572    equivalent FF02::FB).                                                   
  574 5.3.  Multiple Questions per Query                                         
  576    Multicast DNS allows a querier to place multiple questions in the       
  577    Question Section of a single Multicast DNS query message.               
  579    The semantics of a Multicast DNS query message containing multiple      
  580    questions is identical to a series of individual DNS query messages     
  581    containing one question each.  Combining multiple questions into a      
  582    single message is purely an efficiency optimization and has no other    
  583    semantic significance.                                                  
  585 5.4.  Questions Requesting Unicast Responses                               
  587    Sending Multicast DNS responses via multicast has the benefit that      
  588    all the other hosts on the network get to see those responses,          
  589    enabling them to keep their caches up to date and detect conflicting    
  590    responses.                                                              
  592    However, there are situations where all the other hosts on the          
  593    network don't need to see every response.  Some examples are a laptop   
  594    computer waking from sleep, the Ethernet cable being connected to a     
  595    running machine, or a previously inactive interface being activated     
  596    through a configuration change.  At the instant of wake-up or link      
  597    activation, the machine is a brand new participant on a new network.    
  598    Its Multicast DNS cache for that interface is empty, and it has no      
  602 Cheshire & Krochmal          Standards Track                   [Page 11]   

  603 RFC 6762                      Multicast DNS                February 2013   
  606    knowledge of its peers on that link.  It may have a significant         
  607    number of questions that it wants answered right away, to discover      
  608    information about its new surroundings and present that information     
  609    to the user.  As a new participant on the network, it has no idea       
  610    whether the exact same questions may have been asked and answered       
  611    just seconds ago.  In this case, triggering a large sudden flood of     
  612    multicast responses may impose an unreasonable burden on the network.   
  614    To avoid large floods of potentially unnecessary responses in these     
  615    cases, Multicast DNS defines the top bit in the class field of a DNS    
  616    question as the unicast-response bit.  When this bit is set in a        
  617    question, it indicates that the querier is willing to accept unicast    
  618    replies in response to this specific query, as well as the usual        
  619    multicast responses.  These questions requesting unicast responses      
  620    are referred to as "QU" questions, to distinguish them from the more    
  621    usual questions requesting multicast responses ("QM" questions).  A     
  622    Multicast DNS querier sending its initial batch of questions            
  623    immediately on wake from sleep or interface activation SHOULD set the   
  624    unicast-response bit in those questions.                                
  626    When a question is retransmitted (as described in Section 5.2), the     
  627    unicast-response bit SHOULD NOT be set in subsequent retransmissions    
  628    of that question.  Subsequent retransmissions SHOULD be usual "QM"      
  629    questions.  After the first question has received its responses, the    
  630    querier should have a large Known-Answer list (Section 7.1) so that     
  631    subsequent queries should elicit few, if any, further responses.        
  632    Reverting to multicast responses as soon as possible is important       
  633    because of the benefits that multicast responses provide (see           
  634    Appendix D).  In addition, the unicast-response bit SHOULD be set       
  635    only for questions that are active and ready to be sent the moment of   
  636    wake from sleep or interface activation.  New questions created by      
  637    local clients afterwards should be treated as normal "QM" questions     
  638    and SHOULD NOT have the unicast-response bit set on the first           
  639    question of the series.                                                 
  641    When receiving a question with the unicast-response bit set, a          
  642    responder SHOULD usually respond with a unicast packet directed back    
  643    to the querier.  However, if the responder has not multicast that       
  644    record recently (within one quarter of its TTL), then the responder     
  645    SHOULD instead multicast the response so as to keep all the peer        
  646    caches up to date, and to permit passive conflict detection.  In the    
  647    case of answering a probe question (Section 8.1) with the unicast-      
  648    response bit set, the responder should always generate the requested    
  649    unicast response, but it may also send a multicast announcement if      
  650    the time since the last multicast announcement of that record is more   
  651    than a quarter of its TTL.                                              
  657 Cheshire & Krochmal          Standards Track                   [Page 12]   

  658 RFC 6762                      Multicast DNS                February 2013   
  661    Unicast replies are subject to all the same packet generation rules     
  662    as multicast replies, including the cache-flush bit (Section 10.2)      
  663    and (except when defending a unique name against a probe from another   
  664    host) randomized delays to reduce network collisions (Section 6).       
  666 5.5.  Direct Unicast Queries to Port 5353                                  
  668    In specialized applications there may be rare situations where it       
  669    makes sense for a Multicast DNS querier to send its query via unicast   
  670    to a specific machine.  When a Multicast DNS responder receives a       
  671    query via direct unicast, it SHOULD respond as it would for "QU"        
  672    questions, as described above in Section 5.4.  Since it is possible     
  673    for a unicast query to be received from a machine outside the local     
  674    link, responders SHOULD check that the source address in the query      
  675    packet matches the local subnet for that link (or, in the case of       
  676    IPv6, the source address has an on-link prefix) and silently ignore     
  677    the packet if not.                                                      
  679    There may be specialized situations, outside the scope of this          
  680    document, where it is intended and desirable to create a responder      
  681    that does answer queries originating outside the local link.  Such a    
  682    responder would need to ensure that these non-local queries are         
  683    always answered via unicast back to the querier, since an answer sent   
  684    via link-local multicast would not reach a querier outside the local    
  685    link.                                                                   
  687 6.  Responding                                                             
  689    When a Multicast DNS responder constructs and sends a Multicast DNS     
  690    response message, the Resource Record Sections of that message must     
  691    contain only records for which that responder is explicitly             
  692    authoritative.  These answers may be generated because the record       
  693    answers a question received in a Multicast DNS query message, or at     
  694    certain other times that the responder determines than an unsolicited   
  695    announcement is warranted.  A Multicast DNS responder MUST NOT place    
  696    records from its cache, which have been learned from other responders   
  697    on the network, in the Resource Record Sections of outgoing response    
  698    messages.  Only an authoritative source for a given record is allowed   
  699    to issue responses containing that record.                              
  701    The determination of whether a given record answers a given question    
  702    is made using the standard DNS rules: the record name must match the    
  703    question name, the record rrtype must match the question qtype unless   
  704    the qtype is "ANY" (255) or the rrtype is "CNAME" (5), and the record   
  705    rrclass must match the question qclass unless the qclass is "ANY"       
  706    (255).  As with Unicast DNS, generally only DNS class 1 ("Internet")    
  707    is used, but should client software use classes other than 1, the       
  708    matching rules described above MUST be used.                            
  712 Cheshire & Krochmal          Standards Track                   [Page 13]   

  713 RFC 6762                      Multicast DNS                February 2013   
  716    A Multicast DNS responder MUST only respond when it has a positive,     
  717    non-null response to send, or it authoritatively knows that a           
  718    particular record does not exist.  For unique records, where the host   
  719    has already established sole ownership of the name, it MUST return      
  720    negative answers to queries for records that it knows not to exist.     
  721    For example, a host with no IPv6 address, that has claimed sole         
  722    ownership of the name "host.local." for all rrtypes, MUST respond to    
  723    AAAA queries for "host.local." by sending a negative answer             
  724    indicating that no AAAA records exist for that name.  See Section       
  725    6.1, "Negative Responses".  For shared records, which are owned by no   
  726    single host, the nonexistence of a given record is ascertained by the   
  727    failure of any machine to respond to the Multicast DNS query, not by    
  728    any explicit negative response.  For shared records, NXDOMAIN and       
  729    other error responses MUST NOT be sent.                                 
  731    Multicast DNS responses MUST NOT contain any questions in the           
  732    Question Section.  Any questions in the Question Section of a           
  733    received Multicast DNS response MUST be silently ignored.  Multicast    
  734    DNS queriers receiving Multicast DNS responses do not care what         
  735    question elicited the response; they care only that the information     
  736    in the response is true and accurate.                                   
  738    A Multicast DNS responder on Ethernet [IEEE.802.3] and similar shared   
  739    multiple access networks SHOULD have the capability of delaying its     
  740    responses by up to 500 ms, as described below.                          
  742    If a large number of Multicast DNS responders were all to respond       
  743    immediately to a particular query, a collision would be virtually       
  744    guaranteed.  By imposing a small random delay, the number of            
  745    collisions is dramatically reduced.  On a full-sized Ethernet using     
  746    the maximum cable lengths allowed and the maximum number of repeaters   
  747    allowed, an Ethernet frame is vulnerable to collisions during the       
  748    transmission of its first 256 bits.  On 10 Mb/s Ethernet, this          
  749    equates to a vulnerable time window of 25.6 microseconds.  On higher-   
  750    speed variants of Ethernet, the vulnerable time window is shorter.      
  752    In the case where a Multicast DNS responder has good reason to          
  753    believe that it will be the only responder on the link that will send   
  754    a response (i.e., because it is able to answer every question in the    
  755    query message, and for all of those answer records it has previously    
  756    verified that the name, rrtype, and rrclass are unique on the link),    
  757    it SHOULD NOT impose any random delay before responding, and SHOULD     
  758    normally generate its response within at most 10 ms.  In particular,    
  759    this applies to responding to probe queries with the unicast-response   
  760    bit set.  Since receiving a probe query gives a clear indication that   
  761    some other responder is planning to start using this name in the very   
  762    near future, answering such probe queries to defend a unique record     
  763    is a high priority and needs to be done without delay.  A probe query   
  767 Cheshire & Krochmal          Standards Track                   [Page 14]   

  768 RFC 6762                      Multicast DNS                February 2013   
  771    can be distinguished from a normal query by the fact that a probe       
  772    query contains a proposed record in the Authority Section that          
  773    answers the question in the Question Section (for more details, see     
  774    Section 8.2, "Simultaneous Probe Tiebreaking").                         
  776    Responding without delay is appropriate for records like the address    
  777    record for a particular host name, when the host name has been          
  778    previously verified unique.  Responding without delay is *not*          
  779    appropriate for things like looking up PTR records used for DNS-Based   
  780    Service Discovery [RFC6763], where a large number of responses may be   
  781    anticipated.                                                            
  783    In any case where there may be multiple responses, such as queries      
  784    where the answer is a member of a shared resource record set, each      
  785    responder SHOULD delay its response by a random amount of time          
  786    selected with uniform random distribution in the range 20-120 ms.       
  787    The reason for requiring that the delay be at least 20 ms is to         
  788    accommodate the situation where two or more query packets are sent      
  789    back-to-back, because in that case we want a responder with answers     
  790    to more than one of those queries to have the opportunity to            
  791    aggregate all of its answers into a single response message.            
  793    In the case where the query has the TC (truncated) bit set,             
  794    indicating that subsequent Known-Answer packets will follow,            
  795    responders SHOULD delay their responses by a random amount of time      
  796    selected with uniform random distribution in the range 400-500 ms, to   
  797    allow enough time for all the Known-Answer packets to arrive, as        
  798    described in Section 7.2, "Multipacket Known-Answer Suppression".       
  800    The source UDP port in all Multicast DNS responses MUST be 5353 (the    
  801    well-known port assigned to mDNS).  Multicast DNS implementations       
  802    MUST silently ignore any Multicast DNS responses they receive where     
  803    the source UDP port is not 5353.                                        
  805    The destination UDP port in all Multicast DNS responses MUST be 5353,   
  806    and the destination address MUST be the mDNS IPv4 link-local            
  807    multicast address or its IPv6 equivalent FF02::FB, except   
  808    when generating a reply to a query that explicitly requested a          
  809    unicast response:                                                       
  811       * via the unicast-response bit,                                      
  812       * by virtue of being a legacy query (Section 6.7), or                
  813       * by virtue of being a direct unicast query.                         
  815    Except for these three specific cases, responses MUST NOT be sent via   
  816    unicast, because then the "Passive Observation of Failures"             
  817    mechanisms described in Section 10.5 would not work correctly.  Other   
  822 Cheshire & Krochmal          Standards Track                   [Page 15]   

  823 RFC 6762                      Multicast DNS                February 2013   
  826    benefits of sending responses via multicast are discussed in Appendix   
  827    D.  A Multicast DNS querier MUST only accept unicast responses if       
  828    they answer a recently sent query (e.g., sent within the last two       
  829    seconds) that explicitly requested unicast responses.  A Multicast      
  830    DNS querier MUST silently ignore all other unicast responses.           
  832    To protect the network against excessive packet flooding due to         
  833    software bugs or malicious attack, a Multicast DNS responder MUST NOT   
  834    (except in the one special case of answering probe queries) multicast   
  835    a record on a given interface until at least one second has elapsed     
  836    since the last time that record was multicast on that particular        
  837    interface.  A legitimate querier on the network should have seen the    
  838    previous transmission and cached it.  A querier that did not receive    
  839    and cache the previous transmission will retry its request and          
  840    receive a subsequent response.  In the special case of answering        
  841    probe queries, because of the limited time before the probing host      
  842    will make its decision about whether or not to use the name, a          
  843    Multicast DNS responder MUST respond quickly.  In this special case     
  844    only, when responding via multicast to a probe, a Multicast DNS         
  845    responder is only required to delay its transmission as necessary to    
  846    ensure an interval of at least 250 ms since the last time the record    
  847    was multicast on that interface.                                        
  849 6.1.  Negative Responses                                                   
  851    In the early design of Multicast DNS it was assumed that explicit       
  852    negative responses would never be needed.  A host can assert the        
  853    existence of the set of records that it claims to exist, and the        
  854    union of all such sets on a link is the set of Multicast DNS records    
  855    that exist on that link.  Asserting the nonexistence of every record    
  856    in the complement of that set -- i.e., all possible Multicast DNS       
  857    records that could exist on this link but do not at this moment --      
  858    was felt to be impractical and unnecessary.  The nonexistence of a      
  859    record would be ascertained by a querier querying for it and failing    
  860    to receive a response from any of the hosts currently attached to the   
  861    link.                                                                   
  863    However, operational experience showed that explicit negative           
  864    responses can sometimes be valuable.  One such example is when a        
  865    querier is querying for a AAAA record, and the host name in question    
  866    has no associated IPv6 addresses.  In this case, the responding host    
  867    knows it currently has exclusive ownership of that name, and it knows   
  868    that it currently does not have any IPv6 addresses, so an explicit      
  869    negative response is preferable to the querier having to retransmit     
  870    its query multiple times, and eventually give up with a timeout,        
  871    before it can conclude that a given AAAA record does not exist.         
  877 Cheshire & Krochmal          Standards Track                   [Page 16]   

  878 RFC 6762                      Multicast DNS                February 2013   
  881    Any time a responder receives a query for a name for which it has       
  882    verified exclusive ownership, for a type for which that name has no     
  883    records, the responder MUST (except as allowed in (a) below) respond    
  884    asserting the nonexistence of that record using a DNS NSEC record       
  885    [RFC4034].  In the case of Multicast DNS the NSEC record is not being   
  886    used for its usual DNSSEC [RFC4033] security properties, but simply     
  887    as a way of expressing which records do or do not exist with a given    
  888    name.                                                                   
  890    On receipt of a question for a particular name, rrtype, and rrclass,    
  891    for which a responder does have one or more unique answers, the         
  892    responder MAY also include an NSEC record in the Additional Record      
  893    Section indicating the nonexistence of other rrtypes for that name      
  894    and rrclass.                                                            
  896    Implementers working with devices with sufficient memory and CPU        
  897    resources MAY choose to implement code to handle the full generality    
  898    of the DNS NSEC record [RFC4034], including bitmaps up to 65,536 bits   
  899    long.  To facilitate use by devices with limited memory and CPU         
  900    resources, Multicast DNS queriers are only REQUIRED to be able to       
  901    parse a restricted form of the DNS NSEC record.  All compliant          
  902    Multicast DNS implementations MUST at least correctly generate and      
  903    parse the restricted DNS NSEC record format described below:            

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.

  905       o The 'Next Domain Name' field contains the record's own name.       
  906         When used with name compression, this means that the 'Next         
  907         Domain Name' field always takes exactly two bytes in the           
  908         message.                                                           
  910       o The Type Bit Map block number is 0.                                
  912       o The Type Bit Map block length byte is a value in the range 1-32.   
  914       o The Type Bit Map data is 1-32 bytes, as indicated by length        
  915         byte.                                                              
  917    Because this restricted form of the DNS NSEC record is limited to       
  918    Type Bit Map block number zero, it cannot express the existence of      
  919    rrtypes above 255.  Consequently, if a Multicast DNS responder were     
  920    to have records with rrtypes above 255, it MUST NOT generate these      
  921    restricted-form NSEC records for those names, since to do so would      
  922    imply that the name has no records with rrtypes above 255, which        
  923    would be false.  In such cases a Multicast DNS responder MUST either    
  924    (a) emit no NSEC record for that name, or (b) emit a full NSEC record   
  925    containing the appropriate Type Bit Map block(s) with the correct       
  926    bits set for all the record types that exist.  In practice this is      
  927    not a significant limitation, since rrtypes above 255 are not           
  928    currently in widespread use.                                            
  932 Cheshire & Krochmal          Standards Track                   [Page 17]   

  933 RFC 6762                      Multicast DNS                February 2013   
  936    If a Multicast DNS implementation receives an NSEC record where the     
  937    'Next Domain Name' field is not the record's own name, then the         
  938    implementation SHOULD ignore the 'Next Domain Name' field and process   
  939    the remainder of the NSEC record as usual.  In Multicast DNS the        
  940    'Next Domain Name' field is not currently used, but it could be used    
  941    in a future version of this protocol, which is why a Multicast DNS      
  942    implementation MUST NOT reject or ignore an NSEC record it receives     
  943    just because it finds an unexpected value in the 'Next Domain Name'     
  944    field.                                                                  
  946    If a Multicast DNS implementation receives an NSEC record containing    
  947    more than one Type Bit Map, or where the Type Bit Map block number is   
  948    not zero, or where the block length is not in the range 1-32, then      
  949    the Multicast DNS implementation MAY silently ignore the entire NSEC    
  950    record.  A Multicast DNS implementation MUST NOT ignore an entire       
  951    message just because that message contains one or more NSEC record(s)   
  952    that the Multicast DNS implementation cannot parse.  This provision     
  953    is to allow future enhancements to the protocol to be introduced in a   
  954    backwards-compatible way that does not break compatibility with older   
  955    Multicast DNS implementations.                                          
  957    To help differentiate these synthesized NSEC records (generated         
  958    programmatically on-the-fly) from conventional Unicast DNS NSEC         
  959    records (which actually exist in a signed DNS zone), the synthesized    
  960    Multicast DNS NSEC records MUST NOT have the NSEC bit set in the Type   
  961    Bit Map, whereas conventional Unicast DNS NSEC records do have the      
  962    NSEC bit set.                                                           
  964    The TTL of the NSEC record indicates the intended lifetime of the       
  965    negative cache entry.  In general, the TTL given for an NSEC record     
  966    SHOULD be the same as the TTL that the record would have had, had it    
  967    existed.  For example, the TTL for address records in Multicast DNS     
  968    is typically 120 seconds (see Section 10), so the negative cache        
  969    lifetime for an address record that does not exist should also be 120   
  970    seconds.                                                                
  972    A responder MUST only generate negative responses to queries for        
  973    which it has legitimate ownership of the name, rrtype, and rrclass in   
  974    question, and can legitimately assert that no record with that name,    
  975    rrtype, and rrclass exists.  A responder can assert that a specified    
  976    rrtype does not exist for one of its names if it knows a priori that    
  977    it has exclusive ownership of that name (e.g., names of reverse         
  978    address mapping PTR records, which are derived from IP addresses,       
  979    which should be unique on the local link) or if it previously claimed   
  980    unique ownership of that name using probe queries for rrtype "ANY".     
  981    (If it were to use probe queries for a specific rrtype, then it would   
  982    only own the name for that rrtype, and could not assert that other      
  983    rrtypes do not exist.)                                                  
  987 Cheshire & Krochmal          Standards Track                   [Page 18]   

  988 RFC 6762                      Multicast DNS                February 2013   
  991    The design rationale for this mechanism for encoding negative           
  992    responses is discussed further in Appendix E.                           
  994 6.2.  Responding to Address Queries                                        
  996    When a Multicast DNS responder sends a Multicast DNS response message   
  997    containing its own address records, it MUST include all addresses       
  998    that are valid on the interface on which it is sending the message,     
  999    and MUST NOT include addresses that are not valid on that interface     
 1000    (such as addresses that may be configured on the host's other           
 1001    interfaces).  For example, if an interface has both an IPv6 link-       
 1002    local and an IPv6 routable address, both should be included in the      
 1003    response message so that queriers receive both and can make their own   
 1004    choice about which to use.  This allows a querier that only has an      
 1005    IPv6 link-local address to connect to the link-local address, and a     
 1006    different querier that has an IPv6 routable address to connect to the   
 1007    IPv6 routable address instead.                                          
 1009    When a Multicast DNS responder places an IPv4 or IPv6 address record    
 1010    (rrtype "A" or "AAAA") into a response message, it SHOULD also place    
 1011    any records of the other address type with the same name into the       
 1012    additional section, if there is space in the message.  This is to       
 1013    provide fate sharing, so that all a device's addresses are delivered    
 1014    atomically in a single message, to reduce the risk that packet loss     
 1015    could cause a querier to receive only the IPv4 addresses and not the    
 1016    IPv6 addresses, or vice versa.                                          
 1018    In the event that a device has only IPv4 addresses but no IPv6          
 1019    addresses, or vice versa, then the appropriate NSEC record SHOULD be    
 1020    placed into the additional section, so that queriers can know with      
 1021    certainty that the device has no addresses of that kind.                
 1023    Some Multicast DNS responders treat a physical interface with both      
 1024    IPv4 and IPv6 address as a single interface with two addresses.         
 1025    Other Multicast DNS responders may treat this case as logically two     
 1026    interfaces (one with one or more IPv4 addresses, and the other with     
 1027    one or more IPv6 addresses), but responders that operate this way       
 1028    MUST NOT put the corresponding automatic NSEC records in replies they   
 1029    send (i.e., a negative IPv4 assertion in their IPv6 responses, and a    
 1030    negative IPv6 assertion in their IPv4 responses) because this would     
 1031    cause incorrect operation in responders on the network that work the    
 1032    former way.                                                             
 1034 6.3.  Responding to Multiquestion Queries                                  
 1036    Multicast DNS responders MUST correctly handle DNS query messages       
 1037    containing more than one question, by answering any or all of the       
 1038    questions to which they have answers.  Unlike single-question           
 1042 Cheshire & Krochmal          Standards Track                   [Page 19]   

 1043 RFC 6762                      Multicast DNS                February 2013   
 1046    queries, where responding without delay is allowed in appropriate       
 1047    cases, for query messages containing more than one question, all        
 1048    (non-defensive) answers SHOULD be randomly delayed in the range         
 1049    20-120 ms, or 400-500 ms if the TC (truncated) bit is set.  This is     
 1050    because when a query message contains more than one question, a         
 1051    Multicast DNS responder cannot generally be certain that other          
 1052    responders will not also be simultaneously generating answers to        
 1053    other questions in that query message.  (Answers defending a name, in   
 1054    response to a probe for that name, are not subject to this delay rule   
 1055    and are still sent immediately.)                                        
 1057 6.4.  Response Aggregation                                                 
 1059    When possible, a responder SHOULD, for the sake of network              
 1060    efficiency, aggregate as many responses as possible into a single       
 1061    Multicast DNS response message.  For example, when a responder has      
 1062    several responses it plans to send, each delayed by a different         
 1063    interval, then earlier responses SHOULD be delayed by up to an          
 1064    additional 500 ms if that will permit them to be aggregated with        
 1065    other responses scheduled to go out a little later.                     
 1067 6.5.  Wildcard Queries (qtype "ANY" and qclass "ANY")                      
 1069    When responding to queries using qtype "ANY" (255) and/or qclass        
 1070    "ANY" (255), a Multicast DNS responder MUST respond with *ALL* of its   
 1071    records that match the query.  This is subtly different from how        
 1072    qtype "ANY" and qclass "ANY" work in Unicast DNS.                       
 1074    A common misconception is that a Unicast DNS query for qtype "ANY"      
 1075    will elicit a response containing all matching records.  This is        
 1076    incorrect.  If there are any records that match the query, the          
 1077    response is required only to contain at least one of them, not          
 1078    necessarily all of them.                                                
 1080    This somewhat surprising behavior is commonly seen with caching         
 1081    (i.e., "recursive") name servers.  If a caching server receives a       
 1082    qtype "ANY" query for which it has at least one valid answer, it is     
 1083    allowed to return only those matching answers it happens to have        
 1084    already in its cache, and it is not required to reconsult the           
 1085    authoritative name server to check if there are any more records that   
 1086    also match the qtype "ANY" query.                                       
 1088    For example, one might imagine that a query for qtype "ANY" for name    
 1089    "host.example.com" would return both the IPv4 (A) and the IPv6 (AAAA)   
 1090    address records for that host.  In reality, what happens is that it     
 1091    depends on the history of what queries have been previously received    
 1092    by intervening caching servers.  If a caching server has no records     
 1093    for "host.example.com", then it will consult another server (usually    
 1097 Cheshire & Krochmal          Standards Track                   [Page 20]   

 1098 RFC 6762                      Multicast DNS                February 2013   
 1101    the authoritative name server for the name in question), and, in that   
 1102    case, it will typically return all IPv4 and IPv6 address records.       
 1103    However, if some other host has recently done a query for qtype "A"     
 1104    for name "host.example.com", so that the caching server already has     
 1105    IPv4 address records for "host.example.com" in its cache but no IPv6    
 1106    address records, then it will return only the IPv4 address records it   
 1107    already has cached, and no IPv6 address records.                        
 1109    Multicast DNS does not share this property that qtype "ANY" and         
 1110    qclass "ANY" queries return some undefined subset of the matching       
 1111    records.  When responding to queries using qtype "ANY" (255) and/or     
 1112    qclass "ANY" (255), a Multicast DNS responder MUST respond with *ALL*   
 1113    of its records that match the query.                                    
 1115 6.6.  Cooperating Multicast DNS Responders                                 
 1117    If a Multicast DNS responder ("A") observes some other Multicast DNS    
 1118    responder ("B") send a Multicast DNS response message containing a      
 1119    resource record with the same name, rrtype, and rrclass as one of A's   
 1120    resource records, but *different* rdata, then:                          
 1122       o If A's resource record is intended to be a shared resource         
 1123         record, then this is no conflict, and no action is required.       
 1125       o If A's resource record is intended to be a member of a unique      
 1126         resource record set owned solely by that responder, then this is   
 1127         a conflict and MUST be handled as described in Section 9,          
 1128         "Conflict Resolution".                                             
 1130    If a Multicast DNS responder ("A") observes some other Multicast DNS    
 1131    responder ("B") send a Multicast DNS response message containing a      
 1132    resource record with the same name, rrtype, and rrclass as one of A's   
 1133    resource records, and *identical* rdata, then:                          
 1135       o If the TTL of B's resource record given in the message is at       
 1136         least half the true TTL from A's point of view, then no action     
 1137         is required.                                                       
 1139       o If the TTL of B's resource record given in the message is less     
 1140         than half the true TTL from A's point of view, then A MUST mark    
 1141         its record to be announced via multicast.  Queriers receiving      
 1142         the record from B would use the TTL given by B and, hence, may     
 1143         delete the record sooner than A expects.  By sending its own       
 1144         multicast response correcting the TTL, A ensures that the record   
 1145         will be retained for the desired time.                             
 1152 Cheshire & Krochmal          Standards Track                   [Page 21]   

 1153 RFC 6762                      Multicast DNS                February 2013   
 1156    These rules allow multiple Multicast DNS responders to offer the same   
 1157    data on the network (perhaps for fault-tolerance reasons) without       
 1158    conflicting with each other.                                            
 1160 6.7.  Legacy Unicast Responses                                             
 1162    If the source UDP port in a received Multicast DNS query is not port    
 1163    5353, this indicates that the querier originating the query is a        
 1164    simple resolver such as described in Section 5.1, "One-Shot Multicast   
 1165    DNS Queries", which does not fully implement all of Multicast DNS.      
 1166    In this case, the Multicast DNS responder MUST send a UDP response      
 1167    directly back to the querier, via unicast, to the query packet's        
 1168    source IP address and port.  This unicast response MUST be a            
 1169    conventional unicast response as would be generated by a conventional   
 1170    Unicast DNS server; for example, it MUST repeat the query ID and the    
 1171    question given in the query message.  In addition, the cache-flush      
 1172    bit described in Section 10.2, "Announcements to Flush Outdated Cache   
 1173    Entries", MUST NOT be set in legacy unicast responses.                  
 1175    The resource record TTL given in a legacy unicast response SHOULD NOT   
 1176    be greater than ten seconds, even if the true TTL of the Multicast      
 1177    DNS resource record is higher.  This is because Multicast DNS           
 1178    responders that fully participate in the protocol use the cache         
 1179    coherency mechanisms described in Section 10, "Resource Record TTL      
 1180    Values and Cache Coherency", to update and invalidate stale data.       
 1181    Were unicast responses sent to legacy resolvers to use the same high    
 1182    TTLs, these legacy resolvers, which do not implement these cache        
 1183    coherency mechanisms, could retain stale cached resource record data    
 1184    long after it is no longer valid.                                       
 1186 7.  Traffic Reduction                                                      
 1188    A variety of techniques are used to reduce the amount of traffic on     
 1189    the network.                                                            
 1191 7.1.  Known-Answer Suppression                                             
 1193    When a Multicast DNS querier sends a query to which it already knows    
 1194    some answers, it populates the Answer Section of the DNS query          
 1195    message with those answers.                                             
 1197    Generally, this applies only to Shared records, not Unique records,     
 1198    since if a Multicast DNS querier already has at least one Unique        
 1199    record in its cache then it should not be expecting further different   
 1200    answers to this question, since the Unique record(s) it already has     
 1201    comprise the complete answer, so it has no reason to be sending the     
 1202    query at all.  In contrast, having some Shared records in its cache     
 1203    does not necessarily imply that a Multicast DNS querier will not        
 1207 Cheshire & Krochmal          Standards Track                   [Page 22]   

 1208 RFC 6762                      Multicast DNS                February 2013   
 1211    receive further answers to this query, and it is in this case that it   
 1212    is beneficial to use the Known-Answer list to suppress repeated         
 1213    sending of redundant answers that the querier already knows.            
 1215    A Multicast DNS responder MUST NOT answer a Multicast DNS query if      
 1216    the answer it would give is already included in the Answer Section      
 1217    with an RR TTL at least half the correct value.  If the RR TTL of the   
 1218    answer as given in the Answer Section is less than half of the true     
 1219    RR TTL as known by the Multicast DNS responder, the responder MUST      
 1220    send an answer so as to update the querier's cache before the record    
 1221    becomes in danger of expiration.                                        
 1223    Because a Multicast DNS responder will respond if the remaining TTL     
 1224    given in the Known-Answer list is less than half the true TTL, it is    
 1225    superfluous for the querier to include such records in the Known-       
 1226    Answer list.  Therefore, a Multicast DNS querier SHOULD NOT include     
 1227    records in the Known-Answer list whose remaining TTL is less than       
 1228    half of their original TTL.  Doing so would simply consume space in     
 1229    the message without achieving the goal of suppressing responses and     
 1230    would, therefore, be a pointless waste of network capacity.             
 1232    A Multicast DNS querier MUST NOT cache resource records observed in     
 1233    the Known-Answer Section of other Multicast DNS queries.  The Answer    
 1234    Section of Multicast DNS queries is not authoritative.  By placing      
 1235    information in the Answer Section of a Multicast DNS query, the         
 1236    querier is stating that it *believes* the information to be true.  It   
 1237    is not asserting that the information *is* true.  Some of those         
 1238    records may have come from other hosts that are no longer on the        
 1239    network.  Propagating that stale information to other Multicast DNS     
 1240    queriers on the network would not be helpful.                           
 1242 7.2.  Multipacket Known-Answer Suppression                                 
 1244    Sometimes a Multicast DNS querier will already have too many answers    
 1245    to fit in the Known-Answer Section of its query packets.  In this       
 1246    case, it should issue a Multicast DNS query containing a question and   
 1247    as many Known-Answer records as will fit.  It MUST then set the TC      
 1248    (Truncated) bit in the header before sending the query.  It MUST        
 1249    immediately follow the packet with another query packet containing no   
 1250    questions and as many more Known-Answer records as will fit.  If        
 1251    there are still too many records remaining to fit in the packet, it     
 1252    again sets the TC bit and continues until all the Known-Answer          
 1253    records have been sent.                                                 
 1255    A Multicast DNS responder seeing a Multicast DNS query with the TC      
 1256    bit set defers its response for a time period randomly selected in      
 1257    the interval 400-500 ms.  This gives the Multicast DNS querier time     
 1258    to send additional Known-Answer packets before the responder            
 1262 Cheshire & Krochmal          Standards Track                   [Page 23]   

 1263 RFC 6762                      Multicast DNS                February 2013   
 1266    responds.  If the responder sees any of its answers listed in the       
 1267    Known-Answer lists of subsequent packets from the querying host, it     
 1268    MUST delete that answer from the list of answers it is planning to      
 1269    give (provided that no other host on the network has also issued a      
 1270    query for that record and is waiting to receive an answer).             
 1272    If the responder receives additional Known-Answer packets with the TC   
 1273    bit set, it SHOULD extend the delay as necessary to ensure a pause of   
 1274    400-500 ms after the last such packet before it sends its answer.       
 1275    This opens the potential risk that a continuous stream of Known-        
 1276    Answer packets could, theoretically, prevent a responder from           
 1277    answering indefinitely.  In practice, answers are never actually        
 1278    delayed significantly, and should a situation arise where significant   
 1279    delays did happen, that would be a scenario where the network is so     
 1280    overloaded that it would be desirable to err on the side of caution.    
 1281    The consequence of delaying an answer may be that it takes a user       
 1282    longer than usual to discover all the services on the local network;    
 1283    in contrast, the consequence of incorrectly answering before all the    
 1284    Known-Answer packets have been received would be wasted capacity        
 1285    sending unnecessary answers on an already overloaded network.  In       
 1286    this (rare) situation, sacrificing speed to preserve reliable network   
 1287    operation is the right trade-off.                                       
 1289 7.3.  Duplicate Question Suppression                                       
 1291    If a host is planning to transmit (or retransmit) a query, and it       
 1292    sees another host on the network send a query containing the same       
 1293    "QM" question, and the Known-Answer Section of that query does not      
 1294    contain any records that this host would not also put in its own        
 1295    Known-Answer Section, then this host SHOULD treat its own query as      
 1296    having been sent.  When multiple queriers on the network are querying   
 1297    for the same resource records, there is no need for them to all be      
 1298    repeatedly asking the same question.                                    
 1300 7.4.  Duplicate Answer Suppression                                         
 1302    If a host is planning to send an answer, and it sees another host on    
 1303    the network send a response message containing the same answer          
 1304    record, and the TTL in that record is not less than the TTL this host   
 1305    would have given, then this host SHOULD treat its own answer as         
 1306    having been sent, and not also send an identical answer itself.  When   
 1307    multiple responders on the network have the same data, there is no      
 1308    need for all of them to respond.                                        
 1317 Cheshire & Krochmal          Standards Track                   [Page 24]   

 1318 RFC 6762                      Multicast DNS                February 2013   
 1321    The opportunity for duplicate answer suppression occurs when a host     
 1322    has received a query, and is delaying its response for some pseudo-     
 1323    random interval up to 500 ms, as described elsewhere in this            
 1324    document, and then, before the host sends its response, it sees some    
 1325    other host on the network send a response message containing the same   
 1326    answer record.                                                          
 1328    This feature is particularly useful when Multicast DNS Proxy Servers    
 1329    are in use, where there could be more than one proxy on the network     
 1330    giving Multicast DNS answers on behalf of some other host (e.g.,        
 1331    because that other host is currently asleep and is not itself           
 1332    responding to queries).                                                 
 1334 8.  Probing and Announcing on Startup                                      
 1336    Typically a Multicast DNS responder should have, at the very least,     
 1337    address records for all of its active interfaces.  Creating and         
 1338    advertising an HINFO record on each interface as well can be useful     
 1339    to network administrators.                                              
 1341    Whenever a Multicast DNS responder starts up, wakes up from sleep,      
 1342    receives an indication of a network interface "Link Change" event, or   
 1343    has any other reason to believe that its network connectivity may       
 1344    have changed in some relevant way, it MUST perform the two startup      
 1345    steps below: Probing (Section 8.1) and Announcing (Section 8.3).        
 1347 8.1.  Probing                                                              
 1349    The first startup step is that, for all those resource records that a   
 1350    Multicast DNS responder desires to be unique on the local link, it      
 1351    MUST send a Multicast DNS query asking for those resource records, to   
 1352    see if any of them are already in use.  The primary example of this     
 1353    is a host's address records, which map its unique host name to its      
 1354    unique IPv4 and/or IPv6 addresses.  All probe queries SHOULD be done    
 1355    using the desired resource record name and class (usually class 1,      
 1356    "Internet"), and query type "ANY" (255), to elicit answers for all      
 1357    types of records with that name.  This allows a single question to be   
 1358    used in place of several questions, which is more efficient on the      
 1359    network.  It also allows a host to verify exclusive ownership of a      
 1360    name for all rrtypes, which is desirable in most cases.  It would be    
 1361    confusing, for example, if one host owned the "A" record for            
 1362    "myhost.local.", but a different host owned the "AAAA" record for       
 1363    that name.                                                              
 1372 Cheshire & Krochmal          Standards Track                   [Page 25]   

 1373 RFC 6762                      Multicast DNS                February 2013   
 1376    The ability to place more than one question in a Multicast DNS query    
 1377    is useful here, because it can allow a host to use a single message     
 1378    to probe for all of its resource records instead of needing a           
 1379    separate message for each.  For example, a host can simultaneously      
 1380    probe for uniqueness of its "A" record and all its SRV records          
 1381    [RFC6763] in the same query message.                                    
 1383    When ready to send its Multicast DNS probe packet(s) the host should    
 1384    first wait for a short random delay time, uniformly distributed in      
 1385    the range 0-250 ms.  This random delay is to guard against the case     
 1386    where several devices are powered on simultaneously, or several         
 1387    devices are connected to an Ethernet hub, which is then powered on,     
 1388    or some other external event happens that might cause a group of        
 1389    hosts to all send synchronized probes.                                  
 1391    250 ms after the first query, the host should send a second; then,      
 1392    250 ms after that, a third.  If, by 250 ms after the third probe, no    
 1393    conflicting Multicast DNS responses have been received, the host may    
 1394    move to the next step, announcing.  (Note that probing is the one       
 1395    exception from the normal rule that there should be at least one        
 1396    second between repetitions of the same question, and the interval       
 1397    between subsequent repetitions should at least double.)                 
 1399    When sending probe queries, a host MUST NOT consult its cache for       
 1400    potential answers.  Only conflicting Multicast DNS responses received   
 1401    "live" from the network are considered valid for the purposes of        
 1402    determining whether probing has succeeded or failed.                    
 1404    In order to allow services to announce their presence without           
 1405    unreasonable delay, the time window for probing is intentionally set    
 1406    quite short.  As a result of this, from the time the first probe        
 1407    packet is sent, another device on the network using that name has       
 1408    just 750 ms to respond to defend its name.  On networks that are        
 1409    slow, or busy, or both, it is possible for round-trip latency to        
 1410    account for a few hundred milliseconds, and software delays in slow     
 1411    devices can add additional delay.  Hence, it is important that when a   
 1412    device receives a probe query for a name that it is currently using,    
 1413    it SHOULD generate its response to defend that name immediately and     
 1414    send it as quickly as possible.  The usual rules about random delays    
 1415    before responding, to avoid sudden bursts of simultaneous answers       
 1416    from different hosts, do not apply here since normally at most one      
 1417    host should ever respond to a given probe question.  Even when a        
 1418    single DNS query message contains multiple probe questions, it would    
 1419    be unusual for that message to elicit a defensive response from more    
 1420    than one other host.  Because of the mDNS multicast rate-limiting       
 1427 Cheshire & Krochmal          Standards Track                   [Page 26]   

 1428 RFC 6762                      Multicast DNS                February 2013   
 1431    rules, the probes SHOULD be sent as "QU" questions with the unicast-    
 1432    response bit set, to allow a defending host to respond immediately      
 1433    via unicast, instead of potentially having to wait before replying      
 1434    via multicast.                                                          
 1436    During probing, from the time the first probe packet is sent until      
 1437    250 ms after the third probe, if any conflicting Multicast DNS          
 1438    response is received, then the probing host MUST defer to the           
 1439    existing host, and SHOULD choose new names for some or all of its       
 1440    resource records as appropriate.  Apparently conflicting Multicast      
 1441    DNS responses received *before* the first probe packet is sent MUST     
 1442    be silently ignored (see discussion of stale probe packets in Section   
 1443    8.2, "Simultaneous Probe Tiebreaking", below).  In the case of a host   
 1444    probing using query type "ANY" as recommended above, any answer         
 1445    containing a record with that name, of any type, MUST be considered a   
 1446    conflicting response and handled accordingly.                           
 1448    If fifteen conflicts occur within any ten-second period, then the       
 1449    host MUST wait at least five seconds before each successive             
 1450    additional probe attempt.  This is to help ensure that, in the event    
 1451    of software bugs or other unanticipated problems, errant hosts do not   
 1452    flood the network with a continuous stream of multicast traffic.  For   
 1453    very simple devices, a valid way to comply with this requirement is     
 1454    to always wait five seconds after any failed probe attempt before       
 1455    trying again.                                                           
 1457    If a responder knows by other means that its unique resource record     
 1458    set name, rrtype, and rrclass cannot already be in use by any other     
 1459    responder on the network, then it SHOULD skip the probing step for      
 1460    that resource record set.  For example, when creating the reverse       
 1461    address mapping PTR records, the host can reasonably assume that no     
 1462    other host will be trying to create those same PTR records, since       
 1463    that would imply that the two hosts were trying to use the same IP      
 1464    address, and if that were the case, the two hosts would be suffering    
 1465    communication problems beyond the scope of what Multicast DNS is        
 1466    designed to solve.  Similarly, if a responder is acting as a proxy,     
 1467    taking over from another Multicast DNS responder that has already       
 1468    verified the uniqueness of the record, then the proxy SHOULD NOT        
 1469    repeat the probing step for those records.                              
 1471 8.2.  Simultaneous Probe Tiebreaking                                       
 1473    The astute reader will observe that there is a race condition           
 1474    inherent in the previous description.  If two hosts are probing for     
 1475    the same name simultaneously, neither will receive any response to      
 1476    the probe, and the hosts could incorrectly conclude that they may       
 1477    both proceed to use the name.  To break this symmetry, each host        
 1478    populates the query message's Authority Section with the record or      
 1482 Cheshire & Krochmal          Standards Track                   [Page 27]   

 1483 RFC 6762                      Multicast DNS                February 2013   
 1486    records with the rdata that it would be proposing to use, should its    
 1487    probing be successful.  The Authority Section is being used here in a   
 1488    way analogous to the way it is used as the "Update Section" in a DNS    
 1489    Update message [RFC2136] [RFC3007].                                     
 1491    When a host is probing for a group of related records with the same     
 1492    name (e.g., the SRV and TXT record describing a DNS-SD service), only   
 1493    a single question need be placed in the Question Section, since query   
 1494    type "ANY" (255) is used, which will elicit answers for all records     
 1495    with that name.  However, for tiebreaking to work correctly in all      
 1496    cases, the Authority Section must contain *all* the records and         
 1497    proposed rdata being probed for uniqueness.                             
 1499    When a host that is probing for a record sees another host issue a      
 1500    query for the same record, it consults the Authority Section of that    
 1501    query.  If it finds any resource record(s) there which answers the      
 1502    query, then it compares the data of that (those) resource record(s)     
 1503    with its own tentative data.  We consider first the simple case of a    
 1504    host probing for a single record, receiving a simultaneous probe from   
 1505    another host also probing for a single record.  The two records are     
 1506    compared and the lexicographically later data wins.  This means that    
 1507    if the host finds that its own data is lexicographically later, it      
 1508    simply ignores the other host's probe.  If the host finds that its      
 1509    own data is lexicographically earlier, then it defers to the winning    
 1510    host by waiting one second, and then begins probing for this record     
 1511    again.  The logic for waiting one second and then trying again is to    
 1512    guard against stale probe packets on the network (possibly even stale   
 1513    probe packets sent moments ago by this host itself, before some         
 1514    configuration change, which may be echoed back after a short delay by   
 1515    some Ethernet switches and some 802.11 base stations).  If the          
 1516    winning simultaneous probe was from a real other host on the network,   
 1517    then after one second it will have completed its probing, and will      
 1518    answer subsequent probes.  If the apparently winning simultaneous       
 1519    probe was in fact just an old stale packet on the network (maybe from   
 1520    the host itself), then when it retries its probing in one second, its   
 1521    probes will go unanswered, and it will successfully claim the name.     
 1523    The determination of "lexicographically later" is performed by first    
 1524    comparing the record class (excluding the cache-flush bit described     
 1525    in Section 10.2), then the record type, then raw comparison of the      
 1526    binary content of the rdata without regard for meaning or structure.    
 1527    If the record classes differ, then the numerically greater class is     
 1528    considered "lexicographically later".  Otherwise, if the record types   
 1529    differ, then the numerically greater type is considered                 
 1530    "lexicographically later".  If the rrtype and rrclass both match,       
 1531    then the rdata is compared.                                             
 1537 Cheshire & Krochmal          Standards Track                   [Page 28]   

 1538 RFC 6762                      Multicast DNS                February 2013   
 1541    In the case of resource records containing rdata that is subject to     
 1542    name compression [RFC1035], the names MUST be uncompressed before       
 1543    comparison.  (The details of how a particular name is compressed is     
 1544    an artifact of how and where the record is written into the DNS         
 1545    message; it is not an intrinsic property of the resource record         
 1546    itself.)                                                                
 1548    The bytes of the raw uncompressed rdata are compared in turn,           
 1549    interpreting the bytes as eight-bit UNSIGNED values, until a byte is    
 1550    found whose value is greater than that of its counterpart (in which     
 1551    case, the rdata whose byte has the greater value is deemed              
 1552    lexicographically later) or one of the resource records runs out of     
 1553    rdata (in which case, the resource record which still has remaining     
 1554    data first is deemed lexicographically later).  The following is an     
 1555    example of a conflict:                                                  
 1557      MyPrinter.local. A                                     
 1558      MyPrinter.local. A                                     
 1560    In this case, is lexicographically later (the third      
 1561    byte, with value 200, is greater than its counterpart with value 99),   
 1562    so it is deemed the winner.                                             
 1564    Note that it is vital that the bytes are interpreted as UNSIGNED        
 1565    values in the range 0-255, or the wrong outcome may result.  In the     
 1566    example above, if the byte with value 200 had been incorrectly          
 1567    interpreted as a signed eight-bit value, then it would be interpreted   
 1568    as value -56, and the wrong address record would be deemed the          
 1569    winner.                                                                 
 1571 8.2.1.  Simultaneous Probe Tiebreaking for Multiple Records                
 1573    When a host is probing for a set of records with the same name, or a    
 1574    message is received containing multiple tiebreaker records answering    
 1575    a given probe question in the Question Section, the host's records      
 1576    and the tiebreaker records from the message are each sorted into        
 1577    order, and then compared pairwise, using the same comparison            
 1578    technique described above, until a difference is found.                 
 1580    The records are sorted using the same lexicographical order as          
 1581    described above, that is, if the record classes differ, the record      
 1582    with the lower class number comes first.  If the classes are the same   
 1583    but the rrtypes differ, the record with the lower rrtype number comes   
 1584    first.  If the class and rrtype match, then the rdata is compared       
 1585    bytewise until a difference is found.  For example, in the common       
 1586    case of advertising DNS-SD services with a TXT record and an SRV        
 1587    record, the TXT record comes first (the rrtype value for TXT is 16)     
 1588    and the SRV record comes second (the rrtype value for SRV is 33).       
 1592 Cheshire & Krochmal          Standards Track                   [Page 29]   

 1593 RFC 6762                      Multicast DNS                February 2013   
 1596    When comparing the records, if the first records match perfectly,       
 1597    then the second records are compared, and so on.  If either list of     
 1598    records runs out of records before any difference is found, then the    
 1599    list with records remaining is deemed to have won the tiebreak.  If     
 1600    both lists run out of records at the same time without any difference   
 1601    being found, then this indicates that two devices are advertising       
 1602    identical sets of records, as is sometimes done for fault tolerance,    
 1603    and there is, in fact, no conflict.                                     
 1605 8.3.  Announcing                                                           
 1607    The second startup step is that the Multicast DNS responder MUST send   
 1608    an unsolicited Multicast DNS response containing, in the Answer         
 1609    Section, all of its newly registered resource records (both shared      
 1610    records, and unique records that have completed the probing step).      
 1611    If there are too many resource records to fit in a single packet,       
 1612    multiple packets should be used.                                        
 1614    In the case of shared records (e.g., the PTR records used by DNS-       
 1615    Based Service Discovery [RFC6763]), the records are simply placed as    
 1616    is into the Answer Section of the DNS response.                         
 1618    In the case of records that have been verified to be unique in the      
 1619    previous step, they are placed into the Answer Section of the DNS       
 1620    response with the most significant bit of the rrclass set to one.       
 1621    The most significant bit of the rrclass for a record in the Answer      
 1622    Section of a response message is the Multicast DNS cache-flush bit      
 1623    and is discussed in more detail below in Section 10.2, "Announcements   
 1624    to Flush Outdated Cache Entries".                                       
 1626    The Multicast DNS responder MUST send at least two unsolicited          
 1627    responses, one second apart.  To provide increased robustness against   
 1628    packet loss, a responder MAY send up to eight unsolicited responses,    
 1629    provided that the interval between unsolicited responses increases by   
 1630    at least a factor of two with every response sent.                      
 1632    A Multicast DNS responder MUST NOT send announcements in the absence    
 1633    of information that its network connectivity may have changed in some   
 1634    relevant way.  In particular, a Multicast DNS responder MUST NOT send   
 1635    regular periodic announcements as a matter of course.                   
 1637    Whenever a Multicast DNS responder receives any Multicast DNS           
 1638    response (solicited or otherwise) containing a conflicting resource     
 1639    record, the conflict MUST be resolved as described in Section 9,        
 1640    "Conflict Resolution".                                                  
 1647 Cheshire & Krochmal          Standards Track                   [Page 30]   

 1648 RFC 6762                      Multicast DNS                February 2013   
 1651 8.4.  Updating                                                             
 1653    At any time, if the rdata of any of a host's Multicast DNS records      
 1654    changes, the host MUST repeat the Announcing step described above to    
 1655    update neighboring caches.  For example, if any of a host's IP          
 1656    addresses change, it MUST re-announce those address records.  The       
 1657    host does not need to repeat the Probing step because it has already    
 1658    established unique ownership of that name.                              
 1660    In the case of shared records, a host MUST send a "goodbye"             
 1661    announcement with RR TTL zero (see Section 10.1, "Goodbye Packets")     
 1662    for the old rdata, to cause it to be deleted from peer caches, before   
 1663    announcing the new rdata.  In the case of unique records, a host        
 1664    SHOULD omit the "goodbye" announcement, since the cache-flush bit on    
 1665    the newly announced records will cause old rdata to be flushed from     
 1666    peer caches anyway.                                                     
 1668    A host may update the contents of any of its records at any time,       
 1669    though a host SHOULD NOT update records more frequently than ten        
 1670    times per minute.  Frequent rapid updates impose a burden on the        
 1671    network.  If a host has information to disseminate which changes more   
 1672    frequently than ten times per minute, then it may be more appropriate   
 1673    to design a protocol for that specific purpose.                         
 1675 9.  Conflict Resolution                                                    
 1677    A conflict occurs when a Multicast DNS responder has a unique record    
 1678    for which it is currently authoritative, and it receives a Multicast    
 1679    DNS response message containing a record with the same name, rrtype     
 1680    and rrclass, but inconsistent rdata.  What may be considered            
 1681    inconsistent is context sensitive, except that resource records with    
 1682    identical rdata are never considered inconsistent, even if they         
 1683    originate from different hosts.  This is to permit use of proxies and   
 1684    other fault-tolerance mechanisms that may cause more than one           
 1685    responder to be capable of issuing identical answers on the network.    
 1687    A common example of a resource record type that is intended to be       
 1688    unique, not shared between hosts, is the address record that maps a     
 1689    host's name to its IP address.  Should a host witness another host      
 1690    announce an address record with the same name but a different IP        
 1691    address, then that is considered inconsistent, and that address         
 1692    record is considered to be in conflict.                                 
 1694    Whenever a Multicast DNS responder receives any Multicast DNS           
 1695    response (solicited or otherwise) containing a conflicting resource     
 1696    record in any of the Resource Record Sections, the Multicast DNS        
 1697    responder MUST immediately reset its conflicted unique record to        
 1698    probing state, and go through the startup steps described above in      
 1702 Cheshire & Krochmal          Standards Track                   [Page 31]   

 1703 RFC 6762                      Multicast DNS                February 2013   
 1706    Section 8, "Probing and Announcing on Startup".  The protocol used in   
 1707    the Probing phase will determine a winner and a loser, and the loser    
 1708    MUST cease using the name, and reconfigure.                             
 1710    It is very important that any host receiving a resource record that     
 1711    conflicts with one of its own MUST take action as described above.      
 1712    In the case of two hosts using the same host name, where one has been   
 1713    configured to require a unique host name and the other has not, the     
 1714    one that has not been configured to require a unique host name will     
 1715    not perceive any conflict, and will not take any action.  By            
 1716    reverting to Probing state, the host that desires a unique host name    
 1717    will go through the necessary steps to ensure that a unique host name   
 1718    is obtained.                                                            
 1720    The recommended course of action after probing and failing is as        
 1721    follows:                                                                
 1723       1. Programmatically change the resource record name in an attempt    
 1724          to find a new name that is unique.  This could be done by         
 1725          adding some further identifying information (e.g., the model      
 1726          name of the hardware) if it is not already present in the name,   
 1727          or appending the digit "2" to the name, or incrementing a         
 1728          number at the end of the name if one is already present.          
 1730       2. Probe again, and repeat as necessary until a unique name is       
 1731          found.                                                            
 1733       3. Once an available unique name has been determined, by probing     
 1734          without receiving any conflicting response, record this newly     
 1735          chosen name in persistent storage so that the device will use     
 1736          the same name the next time it is power-cycled.                   
 1738       4. Display a message to the user or operator informing them of the   
 1739          name change.  For example:                                        
 1741             The name "Bob's Music" is in use by another music server on    
 1742             the network.  Your music collection has been renamed to        
 1743             "Bob's Music (2)".  If you want to change this name, use       
 1744             [describe appropriate menu item or preference dialog here].    
 1746          The details of how the user or operator is informed of the new    
 1747          name depends on context.  A desktop computer with a screen        
 1748          might put up a dialog box.  A headless server in the closet may   
 1749          write a message to a log file, or use whatever mechanism          
 1750          (email, SNMP trap, etc.) it uses to inform the administrator of   
 1751          error conditions.  On the other hand, a headless server in the    
 1752          closet may not inform the user at all -- if the user cares,       
 1757 Cheshire & Krochmal          Standards Track                   [Page 32]   

 1758 RFC 6762                      Multicast DNS                February 2013   
 1761          they will notice the name has changed, and connect to the         
 1762          server in the usual way (e.g., via web browser) to configure a    
 1763          new name.                                                         
 1765       5. After one minute of probing, if the Multicast DNS responder has   
 1766          been unable to find any unused name, it should log an error       
 1767          message to inform the user or operator of this fact.  This        
 1768          situation should never occur in normal operation.  The only       
 1769          situations that would cause this to happen would be either a      
 1770          deliberate denial-of-service attack, or some kind of very         
 1771          obscure hardware or software bug that acts like a deliberate      
 1772          denial-of-service attack.                                         
 1774    These considerations apply to address records (i.e., host names) and    
 1775    to all resource records where uniqueness (or maintenance of some        
 1776    other defined constraint) is desired.                                   
 1778 10.  Resource Record TTL Values and Cache Coherency                        
 1780    As a general rule, the recommended TTL value for Multicast DNS          
 1781    resource records with a host name as the resource record's name         
 1782    (e.g., A, AAAA, HINFO) or a host name contained within the resource     
 1783    record's rdata (e.g., SRV, reverse mapping PTR record) SHOULD be 120    
 1784    seconds.                                                                
 1786    The recommended TTL value for other Multicast DNS resource records is   
 1787    75 minutes.                                                             
 1789    A querier with an active outstanding query will issue a query message   
 1790    when one or more of the resource records in its cache are 80% of the    
 1791    way to expiry.  If the TTL on those records is 75 minutes, this         
 1792    ongoing cache maintenance process yields a steady-state query rate of   
 1793    one query every 60 minutes.                                             
 1795    Any distributed cache needs a cache coherency protocol.  If Multicast   
 1796    DNS resource records follow the recommendation and have a TTL of 75     
 1797    minutes, that means that stale data could persist in the system for a   
 1798    little over an hour.  Making the default RR TTL significantly lower     
 1799    would reduce the lifetime of stale data, but would produce too much     
 1800    extra traffic on the network.  Various techniques are available to      
 1801    minimize the impact of such stale data, outlined in the five            
 1802    subsections below.                                                      
 1804 10.1.  Goodbye Packets                                                     
 1806    In the case where a host knows that certain resource record data is     
 1807    about to become invalid (for example, when the host is undergoing a     
 1808    clean shutdown), the host SHOULD send an unsolicited Multicast DNS      
 1812 Cheshire & Krochmal          Standards Track                   [Page 33]   

 1813 RFC 6762                      Multicast DNS                February 2013   
 1816    response packet, giving the same resource record name, rrtype,          
 1817    rrclass, and rdata, but an RR TTL of zero.  This has the effect of      
 1818    updating the TTL stored in neighboring hosts' cache entries to zero,    
 1819    causing that cache entry to be promptly deleted.                        
 1821    Queriers receiving a Multicast DNS response with a TTL of zero SHOULD   
 1822    NOT immediately delete the record from the cache, but instead record    
 1823    a TTL of 1 and then delete the record one second later.  In the case    
 1824    of multiple Multicast DNS responders on the network described in        
 1825    Section 6.6 above, if one of the responders shuts down and              
 1826    incorrectly sends goodbye packets for its records, it gives the other   
 1827    cooperating responders one second to send out their own response to     
 1828    "rescue" the records before they expire and are deleted.                
 1830 10.2.  Announcements to Flush Outdated Cache Entries                       
 1832    Whenever a host has a resource record with new data, or with what       
 1833    might potentially be new data (e.g., after rebooting, waking from       
 1834    sleep, connecting to a new network link, or changing IP address), the   
 1835    host needs to inform peers of that new data.  In cases where the host   
 1836    has not been continuously connected and participating on the network    
 1837    link, it MUST first probe to re-verify uniqueness of its unique         
 1838    records, as described above in Section 8.1, "Probing".                  
 1840    Having completed the Probing step, if necessary, the host MUST then     
 1841    send a series of unsolicited announcements to update cache entries in   
 1842    its neighbor hosts.  In these unsolicited announcements, if the         
 1843    record is one that has been verified unique, the host sets the most     
 1844    significant bit of the rrclass field of the resource record.  This      
 1845    bit, the cache-flush bit, tells neighboring hosts that this is not a    
 1846    shared record type.  Instead of merging this new record additively      
 1847    into the cache in addition to any previous records with the same        
 1848    name, rrtype, and rrclass, all old records with that name, rrtype,      
 1849    and rrclass that were received more than one second ago are declared    
 1850    invalid, and marked to expire from the cache in one second.             
 1852    The semantics of the cache-flush bit are as follows: normally when a    
 1853    resource record appears in a Resource Record Section of the DNS         
 1854    response it means, "This is an assertion that this information is       
 1855    true".  When a resource record appears in a Resource Record Section     
 1856    of the DNS response with the cache-flush bit set, it means, "This is    
 1857    an assertion that this information is the truth and the whole truth,    
 1858    and anything you may have heard more than a second ago regarding        
 1859    records of this name/rrtype/rrclass is no longer true".                 
 1861    To accommodate the case where the set of records from one host          
 1862    constituting a single unique RRSet is too large to fit in a single      
 1863    packet, only cache records that are more than one second old are        
 1867 Cheshire & Krochmal          Standards Track                   [Page 34]   

 1868 RFC 6762                      Multicast DNS                February 2013   
 1871    flushed.  This allows the announcing host to generate a quick burst     
 1872    of packets back-to-back on the wire containing all the members of the   
 1873    RRSet.  When receiving records with the cache-flush bit set, all        
 1874    records older than one second are marked to be deleted one second in    
 1875    the future.  One second after the end of the little packet burst, any   
 1876    records not represented within that packet burst will then be expired   
 1877    from all peer caches.                                                   
 1879    Any time a host sends a response packet containing some members of a    
 1880    unique RRSet, it MUST send the entire RRSet, preferably in a single     
 1881    packet, or if the entire RRSet will not fit in a single packet, in a    
 1882    quick burst of packets sent as close together as possible.  The host    
 1883    MUST set the cache-flush bit on all members of the unique RRSet.        
 1885    Another reason for waiting one second before deleting stale records     
 1886    from the cache is to accommodate bridged networks.  For example, a      
 1887    host's address record announcement on a wireless interface may be       
 1888    bridged onto a wired Ethernet and may cause that same host's Ethernet   
 1889    address records to be flushed from peer caches.  The one-second delay   
 1890    gives the host the chance to see its own announcement arrive on the     
 1891    wired Ethernet, and immediately re-announce its Ethernet interface's    
 1892    address records so that both sets remain valid and live in peer         
 1893    caches.                                                                 
 1895    These rules, about when to set the cache-flush bit and about sending    
 1896    the entire rrset, apply regardless of *why* the response message is     
 1897    being generated.  They apply to startup announcements as described in   
 1898    Section 8.3, "Announcing", and to responses generated as a result of    
 1899    receiving query messages.                                               
 1901    The cache-flush bit is only set in records in the Resource Record       
 1902    Sections of Multicast DNS responses sent to UDP port 5353.              
 1904    The cache-flush bit MUST NOT be set in any resource records in a        
 1905    response message sent in legacy unicast responses to UDP ports other    
 1906    than 5353.                                                              
 1908    The cache-flush bit MUST NOT be set in any resource records in the      
 1909    Known-Answer list of any query message.                                 
 1911    The cache-flush bit MUST NOT ever be set in any shared resource         
 1912    record.  To do so would cause all the other shared versions of this     
 1913    resource record with different rdata from different responders to be    
 1914    immediately deleted from all the caches on the network.                 
 1922 Cheshire & Krochmal          Standards Track                   [Page 35]   

 1923 RFC 6762                      Multicast DNS                February 2013   
 1926    The cache-flush bit does *not* apply to questions listed in the         
 1927    Question Section of a Multicast DNS message.  The top bit of the        
 1928    rrclass field in questions is used for an entirely different purpose    
 1929    (see Section 5.4, "Questions Requesting Unicast Responses").            
 1931    Note that the cache-flush bit is NOT part of the resource record        
 1932    class.  The cache-flush bit is the most significant bit of the second   
 1933    16-bit word of a resource record in a Resource Record Section of a      
 1934    Multicast DNS message (the field conventionally referred to as the      
 1935    rrclass field), and the actual resource record class is the least       
 1936    significant fifteen bits of this field.  There is no Multicast DNS      
 1937    resource record class 0x8001.  The value 0x8001 in the rrclass field    
 1938    of a resource record in a Multicast DNS response message indicates a    
 1939    resource record with class 1, with the cache-flush bit set.  When       
 1940    receiving a resource record with the cache-flush bit set,               
 1941    implementations should take care to mask off that bit before storing    
 1942    the resource record in memory, or otherwise ensure that it is given     
 1943    the correct semantic interpretation.                                    
 1945    The reuse of the top bit of the rrclass field only applies to           
 1946    conventional resource record types that are subject to caching, not     
 1947    to pseudo-RRs like OPT [RFC2671], TSIG [RFC2845], TKEY [RFC2930],       
 1948    SIG0 [RFC2931], etc., that pertain only to a particular transport       
 1949    level message and not to any actual DNS data.  Since pseudo-RRs         
 1950    should never go into the Multicast DNS cache, the concept of a cache-   
 1951    flush bit for these types is not applicable.  In particular, the        
 1952    rrclass field of an OPT record encodes the sender's UDP payload size,   
 1953    and should be interpreted as a sixteen-bit length value in the range    
 1954    0-65535, not a one-bit flag and a fifteen-bit length.                   
 1956 10.3.  Cache Flush on Topology change                                      
 1958    If the hardware on a given host is able to indicate physical changes    
 1959    of connectivity, then when the hardware indicates such a change, the    
 1960    host should take this information into account in its Multicast DNS     
 1961    cache management strategy.  For example, a host may choose to           
 1962    immediately flush all cache records received on a particular            
 1963    interface when that cable is disconnected.  Alternatively, a host may   
 1964    choose to adjust the remaining TTL on all those records to a few        
 1965    seconds so that if the cable is not reconnected quickly, those          
 1966    records will expire from the cache.                                     
 1968    Likewise, when a host reboots, wakes from sleep, or undergoes some      
 1969    other similar discontinuous state change, the cache management          
 1970    strategy should take that information into account.                     
 1977 Cheshire & Krochmal          Standards Track                   [Page 36]   

 1978 RFC 6762                      Multicast DNS                February 2013   
 1981 10.4.  Cache Flush on Failure Indication                                   
 1983    Sometimes a cache record can be determined to be stale when a client    
 1984    attempts to use the rdata it contains, and the client finds that        
 1985    rdata to be incorrect.                                                  
 1987    For example, the rdata in an address record can be determined to be     
 1988    incorrect if attempts to contact that host fail, either because (for    
 1989    an IPv4 address on a local subnet) ARP requests for that address go     
 1990    unanswered, because (for an IPv6 address with an on-link prefix) ND     
 1991    requests for that address go unanswered, or because (for an address     
 1992    on a remote network) a router returns an ICMP "Host Unreachable"        
 1993    error.                                                                  
 1995    The rdata in an SRV record can be determined to be incorrect if         
 1996    attempts to communicate with the indicated service at the host and      
 1997    port number indicated are not successful.                               
 1999    The rdata in a DNS-SD PTR record can be determined to be incorrect if   
 2000    attempts to look up the SRV record it references are not successful.    
 2002    The software implementing the Multicast DNS resource record cache       
 2003    should provide a mechanism so that clients detecting stale rdata can    
 2004    inform the cache.                                                       
 2006    When the cache receives this hint that it should reconfirm some         
 2007    record, it MUST issue two or more queries for the resource record in    
 2008    dispute.  If no response is received within ten seconds, then, even     
 2009    though its TTL may indicate that it is not yet due to expire, that      
 2010    record SHOULD be promptly flushed from the cache.                       
 2012    The end result of this is that if a printer suffers a sudden power      
 2013    failure or other abrupt disconnection from the network, its name may    
 2014    continue to appear in DNS-SD browser lists displayed on users'          
 2015    screens.  Eventually, that entry will expire from the cache             
 2016    naturally, but if a user tries to access the printer before that        
 2017    happens, the failure to successfully contact the printer will trigger   
 2018    the more hasty demise of its cache entries.  This is a sensible         
 2019    trade-off between good user experience and good network efficiency.     
 2020    If we were to insist that printers should disappear from the printer    
 2021    list within 30 seconds of becoming unavailable, for all failure         
 2022    modes, the only way to achieve this would be for the client to poll     
 2023    the printer at least every 30 seconds, or for the printer to announce   
 2024    its presence at least every 30 seconds, both of which would be an       
 2025    unreasonable burden on most networks.                                   
 2032 Cheshire & Krochmal          Standards Track                   [Page 37]   

 2033 RFC 6762                      Multicast DNS                February 2013   
 2036 10.5.  Passive Observation Of Failures (POOF)                              
 2038    A host observes the multicast queries issued by the other hosts on      
 2039    the network.  One of the major benefits of also sending responses       
 2040    using multicast is that it allows all hosts to see the responses (or    
 2041    lack thereof) to those queries.                                         
 2043    If a host sees queries, for which a record in its cache would be        
 2044    expected to be given as an answer in a multicast response, but no       
 2045    such answer is seen, then the host may take this as an indication       
 2046    that the record may no longer be valid.                                 
 2048    After seeing two or more of these queries, and seeing no multicast      
 2049    response containing the expected answer within ten seconds, then even   
 2050    though its TTL may indicate that it is not yet due to expire, that      
 2051    record SHOULD be flushed from the cache.  The host SHOULD NOT perform   
 2052    its own queries to reconfirm that the record is truly gone.  If every   
 2053    host on a large network were to do this, it would cause a lot of        
 2054    unnecessary multicast traffic.  If host A sends multicast queries       
 2055    that remain unanswered, then there is no reason to suppose that host    
 2056    B or any other host is likely to be any more successful.                
 2058    The previous section, "Cache Flush on Failure Indication", describes    
 2059    a situation where a user trying to print discovers that the printer     
 2060    is no longer available.  By implementing the passive observation        
 2061    described here, when one user fails to contact the printer, all hosts   
 2062    on the network observe that failure and update their caches             
 2063    accordingly.                                                            
 2065 11.  Source Address Check                                                  
 2067    All Multicast DNS responses (including responses sent via unicast)      
 2068    SHOULD be sent with IP TTL set to 255.  This is recommended to          
 2069    provide backwards-compatibility with older Multicast DNS queriers       
 2070    (implementing a draft version of this document, posted in February      
 2071    2004) that check the IP TTL on reception to determine whether the       
 2072    packet originated on the local link.  These older queriers discard      
 2073    all packets with TTLs other than 255.                                   
 2075    A host sending Multicast DNS queries to a link-local destination        
 2076    address (including the and FF02::FB link-local multicast    
 2077    addresses) MUST only accept responses to that query that originate      
 2078    from the local link, and silently discard any other response packets.   
 2079    Without this check, it could be possible for remote rogue hosts to      
 2080    send spoof answer packets (perhaps unicast to the victim host), which   
 2081    the receiving machine could misinterpret as having originated on the    
 2082    local link.                                                             
 2087 Cheshire & Krochmal          Standards Track                   [Page 38]   

 2088 RFC 6762                      Multicast DNS                February 2013   
 2091    The test for whether a response originated on the local link is done    
 2092    in two ways:                                                            
 2094       * All responses received with a destination address in the IP        
 2095         header that is the mDNS IPv4 link-local multicast address          
 2096 or the mDNS IPv6 link-local multicast address          
 2097         FF02::FB are necessarily deemed to have originated on the local    
 2098         link, regardless of source IP address.  This is essential to       
 2099         allow devices to work correctly and reliably in unusual            
 2100         configurations, such as multiple logical IP subnets overlayed on   
 2101         a single link, or in cases of severe misconfiguration, where       
 2102         devices are physically connected to the same link, but are         
 2103         currently misconfigured with completely unrelated IP addresses     
 2104         and subnet masks.                                                  
 2106       * For responses received with a unicast destination address in the   
 2107         IP header, the source IP address in the packet is checked to see   
 2108         if it is an address on a local subnet.  An IPv4 source address     
 2109         is determined to be on a local subnet if, for (one of) the         
 2110         address(es) configured on the interface receiving the packet, (I   
 2111         & M) == (P & M), where I and M are the interface address and       
 2112         subnet mask respectively, P is the source IP address from the      
 2113         packet, '&' represents the bitwise logical 'and' operation, and    
 2114         '==' represents a bitwise equality test.  An IPv6 source address   
 2115         is determined to be on the local link if, for any of the on-link   
 2116         IPv6 prefixes on the interface receiving the packet (learned via   
 2117         IPv6 router advertisements or otherwise configured on the host),   
 2118         the first 'n' bits of the IPv6 source address match the first      
 2119         'n' bits of the prefix address, where 'n' is the length of the     
 2120         prefix being considered.                                           
 2122    Since queriers will ignore responses apparently originating outside     
 2123    the local subnet, a responder SHOULD avoid generating responses that    
 2124    it can reasonably predict will be ignored.  This applies particularly   
 2125    in the case of overlayed subnets.  If a responder receives a query      
 2126    addressed to the mDNS IPv4 link-local multicast address,    
 2127    from a source address not apparently on the same subnet as the          
 2128    responder (or, in the case of IPv6, from a source IPv6 address for      
 2129    which the responder does not have any address with the same prefix on   
 2130    that interface), then even if the query indicates that a unicast        
 2131    response is preferred (see Section 5.4, "Questions Requesting Unicast   
 2132    Responses"), the responder SHOULD elect to respond by multicast         
 2133    anyway, since it can reasonably predict that a unicast response with    
 2134    an apparently non-local source address will probably be ignored.        
 2142 Cheshire & Krochmal          Standards Track                   [Page 39]   

 2143 RFC 6762                      Multicast DNS                February 2013   
 2146 12.  Special Characteristics of Multicast DNS Domains                      
 2148    Unlike conventional DNS names, names that end in ".local." have only    
 2149    local significance.  The same is true of names within the IPv4 link-    
 2150    local reverse mapping domain "254.169.in-addr.arpa." and the IPv6       
 2151    link-local reverse mapping domains "8.e.f.ip6.arpa.",                   
 2152    "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.".            
 2154    These names function primarily as protocol identifiers, rather than     
 2155    as user-visible identifiers.  Even though they may occasionally be      
 2156    visible to end users, that is not their primary purpose.  As such,      
 2157    these names should be treated as opaque identifiers.  In particular,    
 2158    the string "local" should not be translated or localized into           
 2159    different languages, much as the name "localhost" is not translated     
 2160    or localized into different languages.                                  
 2162    Conventional Unicast DNS seeks to provide a single unified namespace,   
 2163    where a given DNS query yields the same answer no matter where on the   
 2164    planet it is performed or to which recursive DNS server the query is    
 2165    sent.  In contrast, each IP link has its own private ".local.",         
 2166    "254.169.in-addr.arpa." and IPv6 link-local reverse mapping             
 2167    namespaces, and the answer to any query for a name within those         
 2168    domains depends on where that query is asked.  (This characteristic     
 2169    is not unique to Multicast DNS.  Although the original concept of DNS   
 2170    was a single global namespace, in recent years, split views,            
 2171    firewalls, intranets, DNS geolocation, and the like have increasingly   
 2172    meant that the answer to a given DNS query has become dependent on      
 2173    the location of the querier.)                                           
 2175    The IPv4 name server address for a Multicast DNS domain is              
 2176  The IPv6 name server address for a Multicast DNS domain   
 2177    is FF02::FB.  These are multicast addresses; therefore, they identify   
 2178    not a single host but a collection of hosts, working in cooperation     
 2179    to maintain some reasonable facsimile of a competently managed DNS      
 2180    zone.  Conceptually, a Multicast DNS domain is a single DNS zone;       
 2181    however, its server is implemented as a distributed process running     
 2182    on a cluster of loosely cooperating CPUs rather than as a single        
 2183    process running on a single CPU.                                        
 2185    Multicast DNS domains are not delegated from their parent domain via    
 2186    use of NS (Name Server) records, and there is also no concept of        
 2187    delegation of subdomains within a Multicast DNS domain.  Just because   
 2188    a particular host on the network may answer queries for a particular    
 2189    record type with the name "example.local." does not imply anything      
 2190    about whether that host will answer for the name                        
 2191    "child.example.local.", or indeed for other record types with the       
 2192    name "example.local.".                                                  
 2197 Cheshire & Krochmal          Standards Track                   [Page 40]   

 2198 RFC 6762                      Multicast DNS                February 2013   
 2201    There are no NS records anywhere in Multicast DNS domains.  Instead,    
 2202    the Multicast DNS domains are reserved by IANA, and there is            
 2203    effectively an implicit delegation of all Multicast DNS domains to      
 2204    the and [FF02::FB]:5353 multicast groups, by virtue    
 2205    of client software implementing the protocol rules specified in this    
 2206    document.                                                               
 2208    Multicast DNS zones have no SOA (Start of Authority) record.  A         
 2209    conventional DNS zone's SOA record contains information such as the     
 2210    email address of the zone administrator and the monotonically           
 2211    increasing serial number of the last zone modification.  There is no    
 2212    single human administrator for any given Multicast DNS zone, so there   
 2213    is no email address.  Because the hosts managing any given Multicast    
 2214    DNS zone are only loosely coordinated, there is no readily available    
 2215    monotonically increasing serial number to determine whether or not      
 2216    the zone contents have changed.  A host holding part of the shared      
 2217    zone could crash or be disconnected from the network at any time        
 2218    without informing the other hosts.  There is no reliable way to         
 2219    provide a zone serial number that would, whenever such a crash or       
 2220    disconnection occurred, immediately change to indicate that the         
 2221    contents of the shared zone had changed.                                
 2223    Zone transfers are not possible for any Multicast DNS zone.             
 2225 13.  Enabling and Disabling Multicast DNS                                  
 2227    The option to fail-over to Multicast DNS for names not ending in        
 2228    ".local." SHOULD be a user-configured option, and SHOULD be disabled    
 2229    by default because of the possible security issues related to           
 2230    unintended local resolution of apparently global names.  Enabling       
 2231    Multicast DNS for names not ending in ".local." may be appropriate on   
 2232    a secure isolated network, or on some future network were machines      
 2233    exclusively use DNSSEC for all DNS queries, and have Multicast DNS      
 2234    responders capable of generating the appropriate cryptographic DNSSEC   
 2235    signatures, thereby guarding against spoofing.                          
 2237    The option to look up unqualified (relative) names by appending         
 2238    ".local." (or not) is controlled by whether ".local." appears (or       
 2239    not) in the client's DNS search list.                                   
 2241    No special control is needed for enabling and disabling Multicast DNS   
 2242    for names explicitly ending with ".local." as entered by the user.      
 2243    The user doesn't need a way to disable Multicast DNS for names ending   
 2244    with ".local.", because if the user doesn't want to use Multicast       
 2245    DNS, they can achieve this by simply not using those names.  If a       
 2246    user *does* enter a name ending in ".local.", then we can safely        
 2247    assume the user's intention was probably that it should work.  Having   
 2248    user configuration options that can be (intentionally or                
 2252 Cheshire & Krochmal          Standards Track                   [Page 41]   

 2253 RFC 6762                      Multicast DNS                February 2013   
 2256    unintentionally) set so that local names don't work is just one more    
 2257    way of frustrating the user's ability to perform the tasks they want,   
 2258    perpetuating the view that, "IP networking is too complicated to        
 2259    configure and too hard to use".                                         
 2261 14.  Considerations for Multiple Interfaces                                
 2263    A host SHOULD defend its dot-local host name on all active interfaces   
 2264    on which it is answering Multicast DNS queries.                         
 2266    In the event of a name conflict on *any* interface, a host should       
 2267    configure a new host name, if it wishes to maintain uniqueness of its   
 2268    host name.                                                              
 2270    A host may choose to use the same name (or set of names) for all of     
 2271    its address records on all interfaces, or it may choose to manage its   
 2272    Multicast DNS interfaces independently, potentially answering to a      
 2273    different name (or set of names) on different interfaces.               
 2275    Except in the case of proxying and other similar specialized uses,      
 2276    addresses in IPv4 or IPv6 address records in Multicast DNS responses    
 2277    MUST be valid for use on the interface on which the response is being   
 2278    sent.                                                                   
 2280    Just as the same link-local IP address may validly be in use            
 2281    simultaneously on different links by different hosts, the same link-    
 2282    local host name may validly be in use simultaneously on different       
 2283    links, and this is not an error.  A multihomed host with connections    
 2284    to two different links may be able to communicate with two different    
 2285    hosts that are validly using the same name.  While this kind of name    
 2286    duplication should be rare, it means that a host that wants to fully    
 2287    support this case needs network programming APIs that allow             
 2288    applications to specify on what interface to perform a link-local       
 2289    Multicast DNS query, and to discover on what interface a Multicast      
 2290    DNS response was received.                                              
 2292    There is one other special precaution that multihomed hosts need to     
 2293    take.  It's common with today's laptop computers to have an Ethernet    
 2294    connection and an 802.11 [IEEE.802.11] wireless connection active at    
 2295    the same time.  What the software on the laptop computer can't easily   
 2296    tell is whether the wireless connection is in fact bridged onto the     
 2297    same network segment as its Ethernet connection.  If the two networks   
 2298    are bridged together, then packets the host sends on one interface      
 2299    will arrive on the other interface a few milliseconds later, and care   
 2300    must be taken to ensure that this bridging does not cause problems:     
 2307 Cheshire & Krochmal          Standards Track                   [Page 42]   

 2308 RFC 6762                      Multicast DNS                February 2013   
 2311    When the host announces its host name (i.e., its address records) on    
 2312    its wireless interface, those announcement records are sent with the    
 2313    cache-flush bit set, so when they arrive on the Ethernet segment,       
 2314    they will cause all the peers on the Ethernet to flush the host's       
 2315    Ethernet address records from their caches.  The Multicast DNS          
 2316    protocol has a safeguard to protect against this situation: when        
 2317    records are received with the cache-flush bit set, other records are    
 2318    not deleted from peer caches immediately, but are marked for deletion   
 2319    in one second.  When the host sees its own wireless address records     
 2320    arrive on its Ethernet interface, with the cache-flush bit set, this    
 2321    one-second grace period gives the host time to respond and re-          
 2322    announce its Ethernet address records, to reinstate those records in    
 2323    peer caches before they are deleted.                                    
 2325    As described, this solves one problem, but creates another, because     
 2326    when those Ethernet announcement records arrive back on the wireless    
 2327    interface, the host would again respond defensively to reinstate its    
 2328    wireless records, and this process would continue forever,              
 2329    continuously flooding the network with traffic.  The Multicast DNS      
 2330    protocol has a second safeguard, to solve this problem: the cache-      
 2331    flush bit does not apply to records received very recently, within      
 2332    the last second.  This means that when the host sees its own Ethernet   
 2333    address records arrive on its wireless interface, with the cache-       
 2334    flush bit set, it knows there's no need to re-announce its wireless     
 2335    address records again because it already sent them less than a second   
 2336    ago, and this makes them immune from deletion from peer caches.  (See   
 2337    Section 10.2.)                                                          
 2339 15.  Considerations for Multiple Responders on the Same Machine            
 2341    It is possible to have more than one Multicast DNS responder and/or     
 2342    querier implementation coexist on the same machine, but there are       
 2343    some known issues.                                                      
 2345 15.1.  Receiving Unicast Responses                                         
 2347    In most operating systems, incoming *multicast* packets can be          
 2348    delivered to *all* open sockets bound to the right port number,         
 2349    provided that the clients take the appropriate steps to allow this.     
 2350    For this reason, all Multicast DNS implementations SHOULD use the       
 2351    SO_REUSEPORT and/or SO_REUSEADDR options (or equivalent as              
 2352    appropriate for the operating system in question) so they will all be   
 2353    able to bind to UDP port 5353 and receive incoming multicast packets    
 2354    addressed to that port.  However, unlike multicast packets, incoming    
 2355    unicast UDP packets are typically delivered only to the first socket    
 2356    to bind to that port.  This means that "QU" responses and other         
 2357    packets sent via unicast will be received only by the first Multicast   
 2358    DNS responder and/or querier on a system.  This limitation can be       
 2362 Cheshire & Krochmal          Standards Track                   [Page 43]   

 2363 RFC 6762                      Multicast DNS                February 2013   
 2366    partially mitigated if Multicast DNS implementations detect when they   
 2367    are not the first to bind to port 5353, and in that case they do not    
 2368    request "QU" responses.  One way to detect if there is another          
 2369    Multicast DNS implementation already running is to attempt binding to   
 2370    port 5353 without using SO_REUSEPORT and/or SO_REUSEADDR, and if that   
 2371    fails it indicates that some other socket is already bound to this      
 2372    port.                                                                   
 2374 15.2.  Multipacket Known-Answer lists                                      
 2376    When a Multicast DNS querier issues a query with too many Known         
 2377    Answers to fit into a single packet, it divides the Known-Answer list   
 2378    into two or more packets.  Multicast DNS responders associate the       
 2379    initial truncated query with its continuation packets by examining      
 2380    the source IP address in each packet.  Since two independent            
 2381    Multicast DNS queriers running on the same machine will be sending      
 2382    packets with the same source IP address, from an outside perspective    
 2383    they appear to be a single entity.  If both queriers happened to send   
 2384    the same multipacket query at the same time, with different Known-      
 2385    Answer lists, then they could each end up suppressing answers that      
 2386    the other needs.                                                        
 2388 15.3.  Efficiency                                                          
 2390    If different clients on a machine were each to have their own           
 2391    independent Multicast DNS implementation, they would lose certain       
 2392    efficiency benefits.  Apart from the unnecessary code duplication,      
 2393    memory usage, and CPU load, the clients wouldn't get the benefit of a   
 2394    shared system-wide cache, and they would not be able to aggregate       
 2395    separate queries into single packets to reduce network traffic.         
 2397 15.4.  Recommendation                                                      
 2399    Because of these issues, this document encourages implementers to       
 2400    design systems with a single Multicast DNS implementation that          
 2401    provides Multicast DNS services shared by all clients on that           
 2402    machine, much as most operating systems today have a single TCP         
 2403    implementation, which is shared between all clients on that machine.    
 2404    Due to engineering constraints, there may be situations where           
 2405    embedding a "user-level" Multicast DNS implementation in the client     
 2406    application software is the most expedient solution, and while this     
 2407    will usually work in practice, implementers should be aware of the      
 2408    issues outlined in this section.                                        
 2417 Cheshire & Krochmal          Standards Track                   [Page 44]   

 2418 RFC 6762                      Multicast DNS                February 2013   
 2421 16.  Multicast DNS Character Set                                           
 2423    Historically, Unicast DNS has been used with a very restricted set of   
 2424    characters.  Indeed, conventional DNS is usually limited to just        
 2425    twenty-six letters, ten digits and the hyphen character, not even       
 2426    allowing spaces or other punctuation.  Attempts to remedy this for      
 2427    Unicast DNS have been badly constrained by the perceived need to        
 2428    accommodate old buggy legacy DNS implementations.  In reality, the      
 2429    DNS specification itself actually imposes no limits on what             
 2430    characters may be used in names, and good DNS implementations handle    
 2431    any arbitrary eight-bit data without trouble.  "Clarifications to the   
 2432    DNS Specification" [RFC2181] directly discusses the subject of          
 2433    allowable character set in Section 11 ("Name syntax"), and explicitly   
 2434    states that DNS names may contain arbitrary eight-bit data.  However,   
 2435    the old rules for ARPANET host names back in the 1980s required host    
 2436    names to be just letters, digits, and hyphens [RFC1034], and since      
 2437    the predominant use of DNS is to store host address records, many       
 2438    have assumed that the DNS protocol itself suffers from the same         
 2439    limitation.  It might be accurate to say that there could be            
 2440    hypothetical bad implementations that do not handle eight-bit data      
 2441    correctly, but it would not be accurate to say that the protocol        
 2442    doesn't allow names containing eight-bit data.                          
 2444    Multicast DNS is a new protocol and doesn't (yet) have old buggy        
 2445    legacy implementations to constrain the design choices.  Accordingly,   
 2446    it adopts the simple obvious elegant solution: all names in Multicast   
 2447    DNS MUST be encoded as precomposed UTF-8 [RFC3629] "Net-Unicode"        
 2448    [RFC5198] text.                                                         
 2450    Some users of 16-bit Unicode have taken to stuffing a "zero-width       
 2451    nonbreaking space" character (U+FEFF) at the start of each UTF-16       
 2452    file, as a hint to identify whether the data is big-endian or little-   
 2453    endian, and calling it a "Byte Order Mark" (BOM).  Since there is       
 2454    only one possible byte order for UTF-8 data, a BOM is neither           
 2455    necessary nor permitted.  Multicast DNS names MUST NOT contain a        
 2456    "Byte Order Mark".  Any occurrence of the Unicode character U+FEFF at   
 2457    the start or anywhere else in a Multicast DNS name MUST be              
 2458    interpreted as being an actual intended part of the name,               
 2459    representing (just as for any other legal unicode value) an actual      
 2460    literal instance of that character (in this case a zero-width non-      
 2461    breaking space character).                                              
 2463    For names that are restricted to US-ASCII [RFC0020] letters, digits,    
 2464    and hyphens, the UTF-8 encoding is identical to the US-ASCII            
 2465    encoding, so this is entirely compatible with existing host names.      
 2466    For characters outside the US-ASCII range, UTF-8 encoding is used.      
 2472 Cheshire & Krochmal          Standards Track                   [Page 45]   

 2473 RFC 6762                      Multicast DNS                February 2013   
 2476    Multicast DNS implementations MUST NOT use any other encodings apart    
 2477    from precomposed UTF-8 (US-ASCII being considered a compatible subset   
 2478    of UTF-8).  The reasons for selecting UTF-8 instead of Punycode         
 2479    [RFC3492] are discussed further in Appendix F.                          
 2481    The simple rules for case-insensitivity in Unicast DNS [RFC1034]        
 2482    [RFC1035] also apply in Multicast DNS; that is to say, in name          
 2483    comparisons, the lowercase letters "a" to "z" (0x61 to 0x7A) match      
 2484    their uppercase equivalents "A" to "Z" (0x41 to 0x5A).  Hence, if a     
 2485    querier issues a query for an address record with the name              
 2486    "myprinter.local.", then a responder having an address record with      
 2487    the name "MyPrinter.local." should issue a response.  No other          
 2488    automatic equivalences should be assumed.  In particular, all UTF-8     
 2489    multibyte characters (codes 0x80 and higher) are compared by simple     
 2490    binary comparison of the raw byte values.  Accented characters are      
 2491    *not* defined to be automatically equivalent to their unaccented        
 2492    counterparts.  Where automatic equivalences are desired, this may be    
 2493    achieved through the use of programmatically generated CNAME records.   
 2494    For example, if a responder has an address record for an accented       
 2495    name Y, and a querier issues a query for a name X, where X is the       
 2496    same as Y with all the accents removed, then the responder may issue    
 2497    a response containing two resource records: a CNAME record "X CNAME     
 2498    Y", asserting that the requested name X (unaccented) is an alias for    
 2499    the true (accented) name Y, followed by the address record for Y.       
 2501 17.  Multicast DNS Message Size                                            
 2503    The 1987 DNS specification [RFC1035] restricts DNS messages carried     
 2504    by UDP to no more than 512 bytes (not counting the IP or UDP            
 2505    headers).  For UDP packets carried over the wide-area Internet in       
 2506    1987, this was appropriate.  For link-local multicast packets on        
 2507    today's networks, there is no reason to retain this restriction.        
 2508    Given that the packets are by definition link-local, there are no       
 2509    Path MTU issues to consider.                                            
 2511    Multicast DNS messages carried by UDP may be up to the IP MTU of the    
 2512    physical interface, less the space required for the IP header (20       
 2513    bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes).        
 2515    In the case of a single Multicast DNS resource record that is too       
 2516    large to fit in a single MTU-sized multicast response packet, a         
 2517    Multicast DNS responder SHOULD send the resource record alone, in a     
 2518    single IP datagram, using multiple IP fragments.  Resource records      
 2519    this large SHOULD be avoided, except in the very rare cases where       
 2520    they really are the appropriate solution to the problem at hand.        
 2521    Implementers should be aware that many simple devices do not            
 2522    reassemble fragmented IP datagrams, so large resource records SHOULD    
 2523    NOT be used except in specialized cases where the implementer knows     
 2527 Cheshire & Krochmal          Standards Track                   [Page 46]   

 2528 RFC 6762                      Multicast DNS                February 2013   
 2531    that all receivers implement reassembly, or where the large resource    
 2532    record contains optional data which is not essential for correct        
 2533    operation of the client.                                                
 2535    A Multicast DNS packet larger than the interface MTU, which is sent     
 2536    using fragments, MUST NOT contain more than one resource record.        
 2538    Even when fragmentation is used, a Multicast DNS packet, including IP   
 2539    and UDP headers, MUST NOT exceed 9000 bytes.                            
 2541    Note that 9000 bytes is also the maximum payload size of an Ethernet    
 2542    "Jumbo" packet [Jumbo].  However, in practice Ethernet "Jumbo"          
 2543    packets are not widely used, so it is advantageous to keep packets      
 2544    under 1500 bytes whenever possible.  Even on hosts that normally        
 2545    handle Ethernet "Jumbo" packets and IP fragment reassembly, it is       
 2546    becoming more common for these hosts to implement power-saving modes    
 2547    where the main CPU goes to sleep and hands off packet reception tasks   
 2548    to a more limited processor in the network interface hardware, which    
 2549    may not support Ethernet "Jumbo" packets or IP fragment reassembly.     
 2551 18.  Multicast DNS Message Format                                          
 2553    This section describes specific rules pertaining to the allowable       
 2554    values for the header fields of a Multicast DNS message, and other      
 2555    message format considerations.                                          
 2557 18.1.  ID (Query Identifier)                                               
 2559    Multicast DNS implementations SHOULD listen for unsolicited responses   
 2560    issued by hosts booting up (or waking up from sleep or otherwise        
 2561    joining the network).  Since these unsolicited responses may contain    
 2562    a useful answer to a question for which the querier is currently        
 2563    awaiting an answer, Multicast DNS implementations SHOULD examine all    
 2564    received Multicast DNS response messages for useful answers, without    
 2565    regard to the contents of the ID field or the Question Section.  In     
 2566    Multicast DNS, knowing which particular query message (if any) is       
 2567    responsible for eliciting a particular response message is less         
 2568    interesting than knowing whether the response message contains useful   
 2569    information.                                                            
 2571    Multicast DNS implementations MAY cache data from any or all            
 2572    Multicast DNS response messages they receive, for possible future       
 2573    use, provided of course that normal TTL aging is performed on these     
 2574    cached resource records.                                                
 2576    In multicast query messages, the Query Identifier SHOULD be set to      
 2577    zero on transmission.                                                   
 2582 Cheshire & Krochmal          Standards Track                   [Page 47]   

 2583 RFC 6762                      Multicast DNS                February 2013   
 2586    In multicast responses, including unsolicited multicast responses,      
 2587    the Query Identifier MUST be set to zero on transmission, and MUST be   
 2588    ignored on reception.                                                   
 2590    In legacy unicast response messages generated specifically in           
 2591    response to a particular (unicast or multicast) query, the Query        
 2592    Identifier MUST match the ID from the query message.                    
 2594 18.2.  QR (Query/Response) Bit                                             
 2596    In query messages the QR bit MUST be zero.                              
 2597    In response messages the QR bit MUST be one.                            
 2599 18.3.  OPCODE                                                              
 2601    In both multicast query and multicast response messages, the OPCODE     
 2602    MUST be zero on transmission (only standard queries are currently       
 2603    supported over multicast).  Multicast DNS messages received with an     
 2604    OPCODE other than zero MUST be silently ignored.                        
 2606 18.4.  AA (Authoritative Answer) Bit                                       
 2608    In query messages, the Authoritative Answer bit MUST be zero on         
 2609    transmission, and MUST be ignored on reception.                         
 2611    In response messages for Multicast domains, the Authoritative Answer    
 2612    bit MUST be set to one (not setting this bit would imply there's some   
 2613    other place where "better" information may be found) and MUST be        
 2614    ignored on reception.                                                   
 2616 18.5.  TC (Truncated) Bit                                                  
 2618    In query messages, if the TC bit is set, it means that additional       
 2619    Known-Answer records may be following shortly.  A responder SHOULD      
 2620    record this fact, and wait for those additional Known-Answer records,   
 2621    before deciding whether to respond.  If the TC bit is clear, it means   
 2622    that the querying host has no additional Known Answers.                 
 2624    In multicast response messages, the TC bit MUST be zero on              
 2625    transmission, and MUST be ignored on reception.                         
 2627    In legacy unicast response messages, the TC bit has the same meaning    
 2628    as in conventional Unicast DNS: it means that the response was too      
 2629    large to fit in a single packet, so the querier SHOULD reissue its      
 2630    query using TCP in order to receive the larger response.                
 2637 Cheshire & Krochmal          Standards Track                   [Page 48]   

 2638 RFC 6762                      Multicast DNS                February 2013   
 2641 18.6.  RD (Recursion Desired) Bit                                          
 2643    In both multicast query and multicast response messages, the            
 2644    Recursion Desired bit SHOULD be zero on transmission, and MUST be       
 2645    ignored on reception.                                                   
 2647 18.7.  RA (Recursion Available) Bit                                        
 2649    In both multicast query and multicast response messages, the            
 2650    Recursion Available bit MUST be zero on transmission, and MUST be       
 2651    ignored on reception.                                                   
 2653 18.8.  Z (Zero) Bit                                                        
 2655    In both query and response messages, the Zero bit MUST be zero on       
 2656    transmission, and MUST be ignored on reception.                         
 2658 18.9.  AD (Authentic Data) Bit                                             
 2660    In both multicast query and multicast response messages, the            
 2661    Authentic Data bit [RFC2535] MUST be zero on transmission, and MUST     
 2662    be ignored on reception.                                                
 2664 18.10.  CD (Checking Disabled) Bit                                         
 2666    In both multicast query and multicast response messages, the Checking   
 2667    Disabled bit [RFC2535] MUST be zero on transmission, and MUST be        
 2668    ignored on reception.                                                   
 2670 18.11.  RCODE (Response Code)                                              
 2672    In both multicast query and multicast response messages, the Response   
 2673    Code MUST be zero on transmission.  Multicast DNS messages received     
 2674    with non-zero Response Codes MUST be silently ignored.                  
 2676 18.12.  Repurposing of Top Bit of qclass in Question Section               
 2678    In the Question Section of a Multicast DNS query, the top bit of the    
 2679    qclass field is used to indicate that unicast responses are preferred   
 2680    for this particular question.  (See Section 5.4.)                       
 2682 18.13.  Repurposing of Top Bit of rrclass in Resource Record Sections      
 2684    In the Resource Record Sections of a Multicast DNS response, the top    
 2685    bit of the rrclass field is used to indicate that the record is a       
 2686    member of a unique RRSet, and the entire RRSet has been sent together   
 2687    (in the same packet, or in consecutive packets if there are too many    
 2688    records to fit in a single packet).  (See Section 10.2.)                
 2692 Cheshire & Krochmal          Standards Track                   [Page 49]   

 2693 RFC 6762                      Multicast DNS                February 2013   
 2696 18.14.  Name Compression                                                   
 2698    When generating Multicast DNS messages, implementations SHOULD use      
 2699    name compression wherever possible to compress the names of resource    
 2700    records, by replacing some or all of the resource record name with a    
 2701    compact two-byte reference to an appearance of that data somewhere      
 2702    earlier in the message [RFC1035].                                       
 2704    This applies not only to Multicast DNS responses, but also to           
 2705    queries.  When a query contains more than one question, successive      
 2706    questions in the same message often contain similar names, and          
 2707    consequently name compression SHOULD be used, to save bytes.  In        
 2708    addition, queries may also contain Known Answers in the Answer          
 2709    Section, or probe tiebreaking data in the Authority Section, and        
 2710    these names SHOULD similarly be compressed for network efficiency.      
 2712    In addition to compressing the *names* of resource records, names       
 2713    that appear within the *rdata* of the following rrtypes SHOULD also     
 2714    be compressed in all Multicast DNS messages:                            
 2716      NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC      
 2718    Until future IETF Standards Action [RFC5226] specifying that names in   
 2719    the rdata of other types should be compressed, names that appear        
 2720    within the rdata of any type not listed above MUST NOT be compressed.   
 2722    Implementations receiving Multicast DNS messages MUST correctly         
 2723    decode compressed names appearing in the Question Section, and          
 2724    compressed names of resource records appearing in other sections.       
 2726    In addition, implementations MUST correctly decode compressed names     
 2727    appearing within the *rdata* of the rrtypes listed above.  Where        
 2728    possible, implementations SHOULD also correctly decode compressed       
 2729    names appearing within the *rdata* of other rrtypes known to the        
 2730    implementers at the time of implementation, because such forward-       
 2731    thinking planning helps facilitate the deployment of future             
 2732    implementations that may have reason to compress those rrtypes.  It     
 2733    is possible that no future IETF Standards Action [RFC5226] will be      
 2734    created that mandates or permits the compression of rdata in new        
 2735    types, but having implementations designed such that they are capable   
 2736    of decompressing all known types helps keep future options open.        
 2738    One specific difference between Unicast DNS and Multicast DNS is that   
 2739    Unicast DNS does not allow name compression for the target host in an   
 2740    SRV record, because Unicast DNS implementations before the first SRV    
 2741    specification in 1996 [RFC2052] may not decode these compressed         
 2747 Cheshire & Krochmal          Standards Track                   [Page 50]   

 2748 RFC 6762                      Multicast DNS                February 2013   
 2751    records properly.  Since all Multicast DNS implementations were         
 2752    created after 1996, all Multicast DNS implementations are REQUIRED to   
 2753    decode compressed SRV records correctly.                                
 2755    In legacy unicast responses generated to answer legacy queries, name    
 2756    compression MUST NOT be performed on SRV records.                       
 2758 19.  Summary of Differences between Multicast DNS and Unicast DNS          
 2760    Multicast DNS shares, as much as possible, the familiar APIs, naming    
 2761    syntax, resource record types, etc., of Unicast DNS.  There are, of     
 2762    course, necessary differences by virtue of it using multicast, and by   
 2763    virtue of it operating in a community of cooperating peers, rather      
 2764    than a precisely defined hierarchy controlled by a strict chain of      
 2765    formal delegations from the root.  These differences are summarized     
 2766    below:                                                                  
 2768    Multicast DNS...                                                        
 2769    * uses multicast                                                        
 2770    * uses UDP port 5353 instead of port 53                                 
 2771    * operates in well-defined parts of the DNS namespace                   
 2772    * has no SOA (Start of Authority) records                               
 2773    * uses UTF-8, and only UTF-8, to encode resource record names           
 2774    * allows names up to 255 bytes plus a terminating zero byte             
 2775    * allows name compression in rdata for SRV and other record types       
 2776    * allows larger UDP packets                                             
 2777    * allows more than one question in a query message                      
 2778    * defines consistent results for qtype "ANY" and qclass "ANY" queries   
 2779    * uses the Answer Section of a query to list Known Answers              
 2780    * uses the TC bit in a query to indicate additional Known Answers       
 2781    * uses the Authority Section of a query for probe tiebreaking           
 2782    * ignores the Query ID field (except for generating legacy responses)   
 2783    * doesn't require the question to be repeated in the response message   
 2784    * uses unsolicited responses to announce new records                    
 2785    * uses NSEC records to signal nonexistence of records                   
 2786    * defines a unicast-response bit in the rrclass of query questions      
 2787    * defines a cache-flush bit in the rrclass of response records          
 2788    * uses DNS RR TTL 0 to indicate that a record has been deleted          
 2789    * recommends AAAA records in the additional section when responding     
 2790      to rrtype "A" queries, and vice versa                                 
 2791    * monitors queries to perform Duplicate Question Suppression            
 2792    * monitors responses to perform Duplicate Answer Suppression...         
 2793    * ... and Ongoing Conflict Detection                                    
 2794    * ... and Opportunistic Caching                                         
 2802 Cheshire & Krochmal          Standards Track                   [Page 51]   

 2803 RFC 6762                      Multicast DNS                February 2013   
 2806 20.  IPv6 Considerations                                                   
 2808    An IPv4-only host and an IPv6-only host behave as "ships that pass in   
 2809    the night".  Even if they are on the same Ethernet, neither is aware    
 2810    of the other's traffic.  For this reason, each physical link may have   
 2811    *two* unrelated ".local." zones, one for IPv4 and one for IPv6.         
 2812    Since for practical purposes, a group of IPv4-only hosts and a group    
 2813    of IPv6-only hosts on the same Ethernet act as if they were on two      
 2814    entirely separate Ethernet segments, it is unsurprising that their      
 2815    use of the ".local." zone should occur exactly as it would if they      
 2816    really were on two entirely separate Ethernet segments.                 
 2818    A dual-stack (v4/v6) host can participate in both ".local." zones,      
 2819    and should register its name(s) and perform its lookups both using      
 2820    IPv4 and IPv6.  This enables it to reach, and be reached by, both       
 2821    IPv4-only and IPv6-only hosts.  In effect, this acts like a             
 2822    multihomed host, with one connection to the logical "IPv4 Ethernet      
 2823    segment", and a connection to the logical "IPv6 Ethernet segment".      
 2824    When such a host generates NSEC records, if it is using the same host   
 2825    name for its IPv4 addresses and its IPv6 addresses on that network      
 2826    interface, its NSEC records should indicate that the host name has      
 2827    both A and AAAA records.                                                
 2829 21.  Security Considerations                                               
 2831    The algorithm for detecting and resolving name conflicts is, by its     
 2832    very nature, an algorithm that assumes cooperating participants.  Its   
 2833    purpose is to allow a group of hosts to arrive at a mutually disjoint   
 2834    set of host names and other DNS resource record names, in the absence   
 2835    of any central authority to coordinate this or mediate disputes.  In    
 2836    the absence of any higher authority to resolve disputes, the only       
 2837    alternative is that the participants must work together cooperatively   
 2838    to arrive at a resolution.                                              
 2840    In an environment where the participants are mutually antagonistic      
 2841    and unwilling to cooperate, other mechanisms are appropriate, like      
 2842    manually configured DNS.                                                
 2844    In an environment where there is a group of cooperating participants,   
 2845    but clients cannot be sure that there are no antagonistic hosts on      
 2846    the same physical link, the cooperating participants need to use        
 2847    IPsec signatures and/or DNSSEC [RFC4033] signatures so that they can    
 2848    distinguish Multicast DNS messages from trusted participants (which     
 2849    they process as usual) from Multicast DNS messages from untrusted       
 2850    participants (which they silently discard).                             
 2857 Cheshire & Krochmal          Standards Track                   [Page 52]   

 2858 RFC 6762                      Multicast DNS                February 2013   
 2861    If DNS queries for *global* DNS names are sent to the mDNS multicast    
 2862    address (during network outages which disrupt communication with the    
 2863    greater Internet) it is *especially* important to use DNSSEC, because   
 2864    the user may have the impression that he or she is communicating with   
 2865    some authentic host, when in fact he or she is really communicating     
 2866    with some local host that is merely masquerading as that name.  This    
 2867    is less critical for names ending with ".local.", because the user      
 2868    should be aware that those names have only local significance and no    
 2869    global authority is implied.                                            
 2871    Most computer users neglect to type the trailing dot at the end of a    
 2872    fully qualified domain name, making it a relative domain name (e.g.,    
 2873    "www.example.com").  In the event of network outage, attempts to        
 2874    positively resolve the name as entered will fail, resulting in          
 2875    application of the search list, including ".local.", if present.  A     
 2876    malicious host could masquerade as "www.example.com." by answering      
 2877    the resulting Multicast DNS query for "www.example.com.local.".  To     
 2878    avoid this, a host MUST NOT append the search suffix ".local.", if      
 2879    present, to any relative (partially qualified) host name containing     
 2880    two or more labels.  Appending ".local." to single-label relative       
 2881    host names is acceptable, since the user should have no expectation     
 2882    that a single-label host name will resolve as is.  However, users who   
 2883    have both "example.com" and "local" in their search lists should be     
 2884    aware that if they type "www" into their web browser, it may not be     
 2885    immediately clear to them whether the page that appears is              
 2886    "www.example.com" or "www.local".                                       
 2888    Multicast DNS uses UDP port 5353.  On operating systems where only      
 2889    privileged processes are allowed to use ports below 1024, no such       
 2890    privilege is required to use port 5353.                                 
 2892 22.  IANA Considerations                                                   
 2894    IANA has allocated the UDP port 5353 for the Multicast DNS protocol     
 2895    described in this document [SN].                                        
 2897    IANA has allocated the IPv4 link-local multicast address    
 2898    for the use described in this document [MC4].                           
 2900    IANA has allocated the IPv6 multicast address set FF0X::FB (where "X"   
 2901    indicates any hexadecimal digit from '1' to 'F') for the use            
 2902    described in this document [MC6].  Only address FF02::FB (link-local    
 2903    scope) is currently in use by deployed software, but it is possible     
 2904    that in the future implementers may experiment with Multicast DNS       
 2905    using larger-scoped addresses, such as FF05::FB (site-local scope)      
 2906    [RFC4291].                                                              
 2912 Cheshire & Krochmal          Standards Track                   [Page 53]   

 2913 RFC 6762                      Multicast DNS                February 2013   
 2916    IANA has implemented the following DNS records:                         
 2918       MDNS.MCAST.NET.            IN  A                      
 2919  IN  PTR  MDNS.MCAST.NET.                  
 2921    Entries for the AAAA and corresponding PTR records have not been made   
 2922    as there is not yet an RFC providing direction for the management of    
 2923    the IP6.ARPA domain relating to the IPv6 multicast address space.       
 2925    The reuse of the top bit of the rrclass field in the Question and       
 2926    Resource Record Sections means that Multicast DNS can only carry DNS    
 2927    records with classes in the range 0-32767.  Classes in the range        
 2928    32768 to 65535 are incompatible with Multicast DNS.  IANA has noted     
 2929    this fact, and if IANA receives a request to allocate a DNS class       
 2930    value above 32767, IANA will make sure the requester is aware of this   
 2931    implication before proceeding.  This does not mean that allocations     
 2932    of DNS class values above 32767 should be denied, only that they        
 2933    should not be allowed until the requester has indicated that they are   
 2934    aware of how this allocation will interact with Multicast DNS.          
 2935    However, to date, only three DNS classes have been assigned by IANA     
 2936    (1, 3, and 4), and only one (1, "Internet") is actually in widespread   
 2937    use, so this issue is likely to remain a purely theoretical one.        
 2939    IANA has recorded the list of domains below as being Special-Use        
 2940    Domain Names [RFC6761]:                                                 
 2942       .local.                                                              
 2943       .254.169.in-addr.arpa.                                               
 2944       .8.e.f.ip6.arpa.                                                     
 2945       .9.e.f.ip6.arpa.                                                     
 2946       .a.e.f.ip6.arpa.                                                     
 2947       .b.e.f.ip6.arpa.                                                     
 2949 22.1.  Domain Name Reservation Considerations                              
 2951    The six domains listed above, and any names falling within those        
 2952    domains (e.g., "MyPrinter.local.", "",       
 2953    "Ink-Jet._pdl-datastream._tcp.local.") are special [RFC6761] in the     
 2954    following ways:                                                         
 2956       1. Users may use these names as they would other DNS names,          
 2957          entering them anywhere that they would otherwise enter a          
 2958          conventional DNS name, or a dotted decimal IPv4 address, or a     
 2959          literal IPv6 address.                                             
 2961          Since there is no central authority responsible for assigning     
 2962          dot-local names, and all devices on the local network are         
 2963          equally entitled to claim any dot-local name, users SHOULD be     
 2967 Cheshire & Krochmal          Standards Track                   [Page 54]   

 2968 RFC 6762                      Multicast DNS                February 2013   
 2971          aware of this and SHOULD exercise appropriate caution.  In an     
 2972          untrusted or unfamiliar network environment, users SHOULD be      
 2973          aware that using a name like "www.local" may not actually         
 2974          connect them to the web site they expected, and could easily      
 2975          connect them to a different web page, or even a fake or spoof     
 2976          of their intended web site, designed to trick them into           
 2977          revealing confidential information.  As always with networking,   
 2978          end-to-end cryptographic security can be a useful tool.  For      
 2979          example, when connecting with ssh, the ssh host key               
 2980          verification process will inform the user if it detects that      
 2981          the identity of the entity they are communicating with has        
 2982          changed since the last time they connected to that name.          
 2984       2. Application software may use these names as they would other      
 2985          similar DNS names, and is not required to recognize the names     
 2986          and treat them specially.  Due to the relative ease of spoofing   
 2987          dot-local names, end-to-end cryptographic security remains        
 2988          important when communicating across a local network, just as it   
 2989          is when communicating across the global Internet.                 
 2991       3. Name resolution APIs and libraries SHOULD recognize these names   
 2992          as special and SHOULD NOT send queries for these names to their   
 2993          configured (unicast) caching DNS server(s).  This is to avoid     
 2994          unnecessary load on the root name servers and other name          
 2995          servers, caused by queries for which those name servers do not    
 2996          have useful non-negative answers to give, and will not ever       
 2997          have useful non-negative answers to give.                         
 2999       4. Caching DNS servers SHOULD recognize these names as special and   
 3000          SHOULD NOT attempt to look up NS records for them, or otherwise   
 3001          query authoritative DNS servers in an attempt to resolve these    
 3002          names.  Instead, caching DNS servers SHOULD generate immediate    
 3003          NXDOMAIN responses for all such queries they may receive (from    
 3004          misbehaving name resolver libraries).  This is to avoid           
 3005          unnecessary load on the root name servers and other name          
 3006          servers.                                                          
 3008       5. Authoritative DNS servers SHOULD NOT by default be configurable   
 3009          to answer queries for these names, and, like caching DNS          
 3010          servers, SHOULD generate immediate NXDOMAIN responses for all     
 3011          such queries they may receive.  DNS server software MAY provide   
 3012          a configuration option to override this default, for testing      
 3013          purposes or other specialized uses.                               
 3015       6. DNS server operators SHOULD NOT attempt to configure              
 3016          authoritative DNS servers to act as authoritative for any of      
 3017          these names.  Configuring an authoritative DNS server to act as   
 3018          authoritative for any of these names may not, in many cases,      
 3022 Cheshire & Krochmal          Standards Track                   [Page 55]   

 3023 RFC 6762                      Multicast DNS                February 2013   
 3026          yield the expected result.  Since name resolver libraries and     
 3027          caching DNS servers SHOULD NOT send queries for those names       
 3028          (see 3 and 4 above), such queries SHOULD be suppressed before     
 3029          they even reach the authoritative DNS server in question, and     
 3030          consequently it will not even get an opportunity to answer        
 3031          them.                                                             
 3033       7. DNS Registrars MUST NOT allow any of these names to be            
 3034          registered in the normal way to any person or entity.  These      
 3035          names are reserved protocol identifiers with special meaning      
 3036          and fall outside the set of names available for allocation by     
 3037          registrars.  Attempting to allocate one of these names as if it   
 3038          were a normal domain name will probably not work as desired,      
 3039          for reasons 3, 4, and 6 above.                                    
 3041 23.  Acknowledgments                                                       
 3043    The concepts described in this document have been explored,             
 3044    developed, and implemented with help from Ran Atkinson, Richard         
 3045    Brown, Freek Dijkstra, Erik Guttman, Kyle McKay, Pasi Sarolahti,        
 3046    Pekka Savola, Robby Simpson, Mark Townsley, Paul Vixie, Bill            
 3047    Woodcock, and others.  Special thanks go to Bob Bradley, Josh           
 3048    Graessley, Scott Herscher, Rory McGuire, Roger Pantos, and Kiren        
 3049    Sekar for their significant contributions.  Special thanks also to      
 3050    Kerry Lynn for converting the document to xml2rfc form in May 2010,     
 3051    and to Area Director Ralph Droms for shepherding the document through   
 3052    its final steps.                                                        
 3054 24.  References                                                            
 3056 24.1.  Normative References                                                
 3058    [MC4]      IANA, "IPv4 Multicast Address Space Registry",               
 3059               <http://www.iana.org/assignments/multicast-addresses/>.      
 3061    [MC6]      IANA, "IPv6 Multicast Address Space Registry",               
 3062               <http://www.iana.org/assignments/                            
 3063               ipv6-multicast-addresses/>.                                  
 3065    [RFC0020]  Cerf, V., "ASCII format for network interchange", RFC 20,    
 3066               October 1969.                                                
 3068    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",   
 3069               STD 13, RFC 1034, November 1987.                             
 3071    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
 3072               specification", STD 13, RFC 1035, November 1987.             
 3077 Cheshire & Krochmal          Standards Track                   [Page 56]   

 3078 RFC 6762                      Multicast DNS                February 2013   
 3081    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
 3082               Requirement Levels", BCP 14, RFC 2119, March 1997.           
 3084    [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO          
 3085               10646", STD 63, RFC 3629, November 2003.                     
 3087    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
 3088               Rose, "Resource Records for the DNS Security Extensions",    
 3089               RFC 4034, March 2005.                                        
 3091    [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network    
 3092               Interchange", RFC 5198, March 2008.                          
 3094    [RFC6195]  Eastlake 3rd, D., "Domain Name System (DNS) IANA             
 3095               Considerations", BCP 42, RFC 6195, March 2011.               
 3097    [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",    
 3098               RFC 6761, February 2013.                                     
 3100    [SN]       IANA, "Service Name and Transport Protocol Port Number       
 3101               Registry", <http://www.iana.org/assignments/                 
 3102               service-names-port-numbers/>.                                
 3104 24.2.  Informative References                                              
 3106    [B4W]      "Bonjour for Windows",                                       
 3107               <http://en.wikipedia.org/wiki/Bonjour_(software)>.           
 3109    [BJ]       Apple Bonjour Open Source Software,                          
 3110               <http://developer.apple.com/bonjour/>.                       
 3112    [IEEE.802.3]                                                            
 3113               "Information technology - Telecommunications and             
 3114               information exchange between systems - Local and             
 3115               metropolitan area networks - Specific requirements - Part    
 3116               3: Carrier Sense Multiple Access with Collision Detection    
 3117               (CMSA/CD) Access Method and Physical Layer                   
 3118               Specifications", IEEE Std 802.3-2008, December 2008,         
 3119               <http://standards.ieee.org/getieee802/802.3.html>.           
 3121    [IEEE.802.11]                                                           
 3122               "Information technology - Telecommunications and             
 3123               information exchange between systems - Local and             
 3124               metropolitan area networks - Specific requirements - Part    
 3125               11: Wireless LAN Medium Access Control (MAC) and Physical    
 3126               Layer (PHY) Specifications", IEEE Std 802.11-2007, June      
 3127               2007, <http://standards.ieee.org/getieee802/802.11.html>.    
 3132 Cheshire & Krochmal          Standards Track                   [Page 57]   

 3133 RFC 6762                      Multicast DNS                February 2013   
 3136    [Jumbo]    "Ethernet Jumbo Frames", November 2009,                      
 3137               <http://www.ethernetalliance.org/library/whitepaper/         
 3138               ethernet-jumbo-frames/>.                                     
 3140    [NIAS]     Cheshire, S. "Discovering Named Instances of Abstract        
 3141               Services using DNS", Work in Progress, July 2001.            
 3143    [NSD]      "NsdManager | Android Developer", June 2012,                 
 3144               <http://developer.android.com/reference/                     
 3145               android/net/nsd/NsdManager.html>.                            
 3147    [RFC2052]  Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the   
 3148               location of services (DNS SRV)", RFC 2052, October 1996.     
 3150    [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor   
 3151               Extensions", RFC 2132, March 1997.                           
 3153    [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,      
 3154               "Dynamic Updates in the Domain Name System (DNS UPDATE)",    
 3155               RFC 2136, April 1997.                                        
 3157    [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS              
 3158               Specification", RFC 2181, July 1997.                         
 3160    [RFC2535]  Eastlake 3rd, D., "Domain Name System Security               
 3161               Extensions", RFC 2535, March 1999.                           
 3163    [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC       
 3164               2671, August 1999.                                           
 3166    [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.         
 3167               Wellington, "Secret Key Transaction Authentication for DNS   
 3168               (TSIG)", RFC 2845, May 2000.                                 
 3170    [RFC2930]  Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY    
 3171               RR)", RFC 2930, September 2000.                              
 3173    [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures    
 3174               ( SIG(0)s )", RFC 2931, September 2000.                      
 3176    [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic     
 3177               Update", RFC 3007, November 2000.                            
 3179    [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode    
 3180               for Internationalized Domain Names in Applications           
 3181               (IDNA)", RFC 3492, March 2003.                               
 3187 Cheshire & Krochmal          Standards Track                   [Page 58]   

 3188 RFC 6762                      Multicast DNS                February 2013   
 3191    [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic            
 3192               Configuration of IPv4 Link-Local Addresses", RFC 3927, May   
 3193               2005.                                                        
 3195    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
 3196               Rose, "DNS Security Introduction and Requirements", RFC      
 3197               4033, March 2005.                                            
 3199    [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing          
 3200               Architecture", RFC 4291, February 2006.                      
 3202    [RFC4795]  Aboba, B., Thaler, D., and L. Esibov, "Link-local            
 3203               Multicast Name Resolution (LLMNR)", RFC 4795, January        
 3204               2007.                                                        
 3206    [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,       
 3207               "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,      
 3208               September 2007.                                              
 3210    [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless      
 3211               Address Autoconfiguration", RFC 4862, September 2007.        
 3213    [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an     
 3214               IANA Considerations Section in RFCs", BCP 26, RFC 5226,      
 3215               May 2008.                                                    
 3217    [RFC5890]  Klensin, J., "Internationalized Domain Names for             
 3218               Applications (IDNA): Definitions and Document Framework",    
 3219               RFC 5890, August 2010.                                       
 3221    [RFC6281]  Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,           
 3222               "Understanding Apple's Back to My Mac (BTMM) Service", RFC   
 3223               6281, June 2011.                                             
 3225    [RFC6760]  Cheshire, S. and M. Krochmal, "Requirements for a Protocol   
 3226               to Replace the AppleTalk Name Binding Protocol (NBP)", RFC   
 3227               6760, February 2013.                                         
 3229    [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service             
 3230               Discovery", RFC 6763, February 2013.                         
 3232    [Zeroconf] Cheshire, S. and D. Steinberg, "Zero Configuration           
 3233               Networking: The Definitive Guide", O'Reilly Media, Inc.,     
 3234               ISBN 0-596-10100-7, December 2005.                           
 3242 Cheshire & Krochmal          Standards Track                   [Page 59]   

 3243 RFC 6762                      Multicast DNS                February 2013   
 3246 Appendix A.  Design Rationale for Choice of UDP Port Number                
 3248    Arguments were made for and against using UDP port 53, the standard     
 3249    Unicast DNS port.  Some of the arguments are given below.  The          
 3250    arguments for using a different port were greater in number and more    
 3251    compelling, so that option was ultimately selected.  The UDP port       
 3252    "5353" was selected for its mnemonic similarity to "53".                
 3254    Arguments for using UDP port 53:                                        
 3256    * This is "just DNS", so it should be the same port.                    
 3258    * There is less work to be done updating old resolver libraries to do   
 3259      simple Multicast DNS queries.  Only the destination address need be   
 3260      changed.  In some cases, this can be achieved without any code        
 3261      changes, just by adding the address to a configuration    
 3262      file.                                                                 
 3264    Arguments for using a different port (UDP port 5353):                   
 3266    * This is not "just DNS".  This is a DNS-like protocol, but             
 3267      different.                                                            
 3269    * Changing resolver library code to use a different port number is      
 3270      not hard.  In some cases, this can be achieved without any code       
 3271      changes, just by adding the address to a             
 3272      configuration file.                                                   
 3274    * Using the same port number makes it hard to run a Multicast DNS       
 3275      responder and a conventional Unicast DNS server on the same           
 3276      machine.  If a conventional Unicast DNS server wishes to implement    
 3277      Multicast DNS as well, it can still do that, by opening two           
 3278      sockets.  Having two different port numbers allows this               
 3279      flexibility.                                                          
 3281    * Some VPN software hijacks all outgoing traffic to port 53 and         
 3282      redirects it to a special DNS server set up to serve those VPN        
 3283      clients while they are connected to the corporate network.  It is     
 3284      questionable whether this is the right thing to do, but it is         
 3285      common, and redirecting link-local multicast DNS packets to a         
 3286      remote server rarely produces any useful results.  It does mean,      
 3287      for example, that a user of such VPN software becomes unable to       
 3288      access their local network printer sitting on their desk right next   
 3289      to their computer.  Using a different UDP port helps avoid this       
 3290      particular problem.                                                   
 3297 Cheshire & Krochmal          Standards Track                   [Page 60]   

 3298 RFC 6762                      Multicast DNS                February 2013   
 3301    * On many operating systems, unprivileged software may not send or      
 3302      receive packets on low-numbered ports.  This means that any           
 3303      software sending or receiving Multicast DNS packets on port 53        
 3304      would have to run as "root", which is an undesirable security risk.   
 3305      Using a higher-numbered UDP port avoids this restriction.             
 3307 Appendix B.  Design Rationale for Not Using Hashed Multicast Addresses     
 3309    Some discovery protocols use a range of multicast addresses, and        
 3310    determine the address to be used by a hash function of the name being   
 3311    sought.  Queries are sent via multicast to the address as indicated     
 3312    by the hash function, and responses are returned to the querier via     
 3313    unicast.  Particularly in IPv6, where multicast addresses are           
 3314    extremely plentiful, this approach is frequently advocated.  For        
 3315    example, IPv6 Neighbor Discovery [RFC4861] sends Neighbor               
 3316    Solicitation messages to the "solicited-node multicast address",        
 3317    which is computed as a function of the solicited IPv6 address.          
 3319    There are some disadvantages to using hashed multicast addresses like   
 3320    this in a service discovery protocol:                                   
 3322    * When a host has a large number of records with different names, the   
 3323      host may have to join a large number of multicast groups.  Each       
 3324      time a host joins or leaves a multicast group, this results in        
 3325      Internet Group Management Protocol (IGMP) or Multicast Listener       
 3326      Discovery (MLD) traffic on the network announcing this fact.          
 3327      Joining a large number of multicast groups can place undue burden     
 3328      on the Ethernet hardware, which typically supports a limited number   
 3329      of multicast addresses efficiently.  When this number is exceeded,    
 3330      the Ethernet hardware may have to resort to receiving all             
 3331      multicasts and passing them up to the host networking code for        
 3332      filtering in software, thereby defeating much of the point of using   
 3333      a multicast address range in the first place.  Finally, many IPv6     
 3334      stacks have a fixed limit IPV6_MAX_MEMBERSHIPS, and the code simply   
 3335      fails with an error if a client attempts to exceed this limit.        
 3336      Common values for IPV6_MAX_MEMBERSHIPS are 20 or 31.                  
 3338    * Multiple questions cannot be placed in one packet if they don't all   
 3339      hash to the same multicast address.                                   
 3341    * Duplicate Question Suppression doesn't work if queriers are not       
 3342      seeing each other's queries.                                          
 3344    * Duplicate Answer Suppression doesn't work if responders are not       
 3345      seeing each other's responses.                                        
 3347    * Opportunistic Caching doesn't work.                                   
 3352 Cheshire & Krochmal          Standards Track                   [Page 61]   

 3353 RFC 6762                      Multicast DNS                February 2013   
 3356    * Ongoing Conflict Detection doesn't work.                              
 3358 Appendix C.  Design Rationale for Maximum Multicast DNS Name Length        
 3360    Multicast DNS names may be up to 255 bytes long (in the on-the-wire     
 3361    message format), not counting the terminating zero byte at the end.     
 3363    "Domain Names - Implementation and Specification" [RFC1035] says:       
 3365       Various objects and parameters in the DNS have size limits.  They    
 3366       are listed below.  Some could be easily changed, others are more     
 3367       fundamental.                                                         
 3369       labels          63 octets or less                                    
 3371       names           255 octets or less                                   
 3373       ...                                                                  
 3375       the total length of a domain name (i.e., label octets and label      
 3376       length octets) is restricted to 255 octets or less.                  
 3378    This text does not state whether this 255-byte limit includes the       
 3379    terminating zero at the end of every name.                              
 3381    Several factors lead us to conclude that the 255-byte limit does        
 3382    *not* include the terminating zero:                                     
 3384    o It is common in software engineering to have size limits that are a   
 3385      power of two, or a multiple of a power of two, for efficiency.  For   
 3386      example, an integer on a modern processor is typically 2, 4, or 8     
 3387      bytes, not 3 or 5 bytes.  The number 255 is not a power of two, nor   
 3388      is it to most people a particularly noteworthy number.  It is         
 3389      noteworthy to computer scientists for only one reason -- because it   
 3390      is exactly one *less* than a power of two.  When a size limit is      
 3391      exactly one less than a power of two, that suggests strongly that     
 3392      the one extra byte is being reserved for some specific reason -- in   
 3393      this case reserved, perhaps, to leave room for a terminating zero     
 3394      at the end.                                                           
 3396    o In the case of DNS label lengths, the stated limit is 63 bytes.  As   
 3397      with the total name length, this limit is exactly one less than a     
 3398      power of two.  This label length limit also excludes the label        
 3399      length byte at the start of every label.  Including that extra        
 3400      byte, a 63-byte label takes 64 bytes of space in memory or in a DNS   
 3401      message.                                                              
 3407 Cheshire & Krochmal          Standards Track                   [Page 62]   

 3408 RFC 6762                      Multicast DNS                February 2013   
 3411    o It is common in software engineering for the semantic "length" of     
 3412      an object to be one less than the number of bytes it takes to store   
 3413      that object.  For example, in C, strlen("foo") is 3, but              
 3414      sizeof("foo") (which includes the terminating zero byte at the end)   
 3415      is 4.                                                                 
 3417    o The text describing the total length of a domain name mentions        
 3418      explicitly that label length and data octets are included, but does   
 3419      not mention the terminating zero at the end.  The zero byte at the    
 3420      end of a domain name is not a label length.  Indeed, the value zero   
 3421      is chosen as the terminating marker precisely because it is not a     
 3422      legal length byte value -- DNS prohibits empty labels.  For           
 3423      example, a name like "bad..name." is not a valid domain name          
 3424      because it contains a zero-length label in the middle, which cannot   
 3425      be expressed in a DNS message, because software parsing the message   
 3426      would misinterpret a zero label-length byte as being a zero "end of   
 3427      name" marker instead.                                                 
 3429    Finally, "Clarifications to the DNS Specification" [RFC2181] offers     
 3430    additional confirmation that, in the context of DNS specifications,     
 3431    the stated "length" of a domain name does not include the terminating   
 3432    zero byte at the end.  That document refers to the root name, which     
 3433    is typically written as "." and is represented in a DNS message by a    
 3434    single lone zero byte (i.e., zero bytes of data plus a terminating      
 3435    zero), as the "zero length full name":                                  
 3437       The zero length full name is defined as representing the root of     
 3438       the DNS tree, and is typically written and displayed as ".".         
 3440    This wording supports the interpretation that, in a DNS context, when   
 3441    talking about lengths of names, the terminating zero byte at the end    
 3442    is not counted.  If the root name (".") is considered to be zero        
 3443    length, then to be consistent, the length (for example) of "org" has    
 3444    to be 4 and the length of "ietf.org" has to be 9, as shown below:       
 3446                                                   ------                   
 3447                                                  | 0x00 |   length = 0     
 3448                                                   ------                   
 3450                              ------------------   ------                   
 3451                             | 0x03 | o | r | g | | 0x00 |   length = 4     
 3452                              ------------------   ------                   
 3454       -----------------------------------------   ------                   
 3455      | 0x04 | i | e | t | f | 0x03 | o | r | g | | 0x00 |   length = 9     
 3456       -----------------------------------------   ------                   
 3462 Cheshire & Krochmal          Standards Track                   [Page 63]   

 3463 RFC 6762                      Multicast DNS                February 2013   
 3466    This means that the maximum length of a domain name, as represented     
 3467    in a Multicast DNS message, up to but not including the final           
 3468    terminating zero, must not exceed 255 bytes.                            
 3470    However, many Unicast DNS implementers have read these RFCs             
 3471    differently, and argue that the 255-byte limit does include the         
 3472    terminating zero, and that the "Clarifications to the DNS               
 3473    Specification" [RFC2181] statement that "." is the "zero length full    
 3474    name" was simply a mistake.                                             
 3476    Hence, implementers should be aware that other Unicast DNS              
 3477    implementations may limit the maximum domain name to 254 bytes plus a   
 3478    terminating zero, depending on how that implementer interpreted the     
 3479    DNS specifications.                                                     
 3481    Compliant Multicast DNS implementations MUST support names up to 255    
 3482    bytes plus a terminating zero, i.e., 256 bytes total.                   
 3484 Appendix D.  Benefits of Multicast Responses                               
 3486    Some people have argued that sending responses via multicast is         
 3487    inefficient on the network.  In fact, using multicast responses can     
 3488    result in a net lowering of overall multicast traffic for a variety     
 3489    of reasons, and provides other benefits too:                            
 3491    * Opportunistic Caching.  One multicast response can update the         
 3492      caches on all machines on the network.  If another machine later      
 3493      wants to issue the same query, and it already has the answer in its   
 3494      cache, it may not need to even transmit that multicast query on the   
 3495      network at all.                                                       
 3497    * Duplicate Query Suppression.  When more than one machine has the      
 3498      same ongoing long-lived query running, every machine does not have    
 3499      to transmit its own independent query.  When one machine transmits    
 3500      a query, all the other hosts see the answers, so they can suppress    
 3501      their own queries.                                                    
 3503    * Passive Observation Of Failures (POOF).  When a host sees a           
 3504      multicast query, but does not see the corresponding multicast         
 3505      response, it can use this information to promptly delete stale data   
 3506      from its cache.  To achieve the same level of user-interface          
 3507      quality and responsiveness without multicast responses would          
 3508      require lower cache lifetimes and more frequent network polling,      
 3509      resulting in a higher packet rate.                                    
 3511    * Passive Conflict Detection.  Just because a name has been             
 3512      previously verified to be unique does not guarantee it will           
 3513      continue to be so indefinitely.  By allowing all Multicast DNS        
 3517 Cheshire & Krochmal          Standards Track                   [Page 64]   

 3518 RFC 6762                      Multicast DNS                February 2013   
 3521      responders to constantly monitor their peers' responses, conflicts    
 3522      arising out of network topology changes can be promptly detected      
 3523      and resolved.  If responses were not sent via multicast, some other   
 3524      conflict detection mechanism would be needed, imposing its own        
 3525      additional burden on the network.                                     
 3527    * Use on devices with constrained memory resources: When using          
 3528      delayed responses to reduce network collisions, responders need to    
 3529      maintain a list recording to whom each answer should be sent.  The    
 3530      option of multicast responses allows responders with limited          
 3531      storage, which cannot store an arbitrarily long list of response      
 3532      addresses, to choose to fail-over to a single multicast response in   
 3533      place of multiple unicast responses, when appropriate.                
 3535    * Overlayed Subnets.  In the case of overlayed subnets, multicast       
 3536      responses allow a receiver to know with certainty that a response     
 3537      originated on the local link, even when its source address may        
 3538      apparently suggest otherwise.                                         
 3540    * Robustness in the face of misconfiguration: Link-local multicast      
 3541      transcends virtually every conceivable network misconfiguration.      
 3542      Even if you have a collection of devices where every device's IP      
 3543      address, subnet mask, default gateway, and DNS server address are     
 3544      all wrong, packets sent by any of those devices addressed to a        
 3545      link-local multicast destination address will still be delivered to   
 3546      all peers on the local link.  This can be extremely helpful when      
 3547      diagnosing and rectifying network problems, since it facilitates a    
 3548      direct communication channel between client and server that works     
 3549      without reliance on ARP, IP routing tables, etc.  Being able to       
 3550      discover what IP address a device has (or thinks it has) is           
 3551      frequently a very valuable first step in diagnosing why it is         
 3552      unable to communicate on the local network.                           
 3554 Appendix E.  Design Rationale for Encoding Negative Responses              
 3556    Alternative methods of asserting nonexistence were considered, such     
 3557    as using an NXDOMAIN response, or emitting a resource record with       
 3558    zero-length rdata.                                                      
 3560    Using an NXDOMAIN response does not work well with Multicast DNS.  A    
 3561    Unicast DNS NXDOMAIN response applies to the entire message, but for    
 3562    efficiency Multicast DNS allows (and encourages) multiple responses     
 3563    in a single message.  If the error code in the header were NXDOMAIN,    
 3564    it would not be clear to which name(s) that error code applied.         
 3566    Asserting nonexistence by emitting a resource record with zero-length   
 3567    rdata would mean that there would be no way to differentiate between    
 3568    a record that doesn't exist, and a record that does exist, with zero-   
 3572 Cheshire & Krochmal          Standards Track                   [Page 65]   

 3573 RFC 6762                      Multicast DNS                February 2013   
 3576    length rdata.  By analogy, most file systems today allow empty files,   
 3577    so a file that exists with zero bytes of data is not considered         
 3578    equivalent to a filename that does not exist.                           
 3580    A benefit of asserting nonexistence through NSEC records instead of     
 3581    through NXDOMAIN responses is that NSEC records can be added to the     
 3582    Additional Section of a DNS response to offer additional information    
 3583    beyond what the querier explicitly requested.  For example, in          
 3584    response to an SRV query, a responder should include A record(s)        
 3585    giving its IPv4 addresses in the Additional Section, and an NSEC        
 3586    record indicating which other types it does or does not have for this   
 3587    name.  If the responder is running on a host that does not support      
 3588    IPv6 (or does support IPv6 but currently has no IPv6 address on that    
 3589    interface) then this NSEC record in the Additional Section will         
 3590    indicate this absence of AAAA records.  In effect, the responder is     
 3591    saying, "Here's my SRV record, and here are my IPv4 addresses, and      
 3592    no, I don't have any IPv6 addresses, so don't waste your time           
 3593    asking".  Without this information in the Additional Section, it        
 3594    would take the querier an additional round-trip to perform an           
 3595    additional query to ascertain that the target host has no AAAA          
 3596    records.  (Arguably Unicast DNS could also benefit from this ability    
 3597    to express nonexistence in the Additional Section, but that is          
 3598    outside the scope of this document.)                                    
 3600 Appendix F.  Use of UTF-8                                                  
 3602    After many years of debate, as a result of the perceived need to        
 3603    accommodate certain DNS implementations that apparently couldn't        
 3604    handle any character that's not a letter, digit, or hyphen (and         
 3605    apparently never would be updated to remedy this limitation), the       
 3606    Unicast DNS community settled on an extremely baroque encoding called   
 3607    "Punycode" [RFC3492].  Punycode is a remarkably ingenious encoding      
 3608    solution, but it is complicated, hard to understand, and hard to        
 3609    implement, using sophisticated techniques including insertion unsort    
 3610    coding, generalized variable-length integers, and bias adaptation.      
 3611    The resulting encoding is remarkably compact given the constraints,     
 3612    but it's still not as good as simple straightforward UTF-8, and it's    
 3613    hard even to predict whether a given input string will encode to a      
 3614    Punycode string that fits within DNS's 63-byte limit, except by         
 3615    simply trying the encoding and seeing whether it fits.  Indeed, the     
 3616    encoded size depends not only on the input characters, but on the       
 3617    order they appear, so the same set of characters may or may not         
 3618    encode to a legal Punycode string that fits within DNS's 63-byte        
 3619    limit, depending on the order the characters appear.  This is           
 3620    extremely hard to present in a user interface that explains to users    
 3621    why one name is allowed, but another name containing the exact same     
 3622    characters is not.  Neither Punycode nor any other of the "ASCII-       
 3623    Compatible Encodings" [RFC5890] proposed for Unicast DNS may be used    
 3627 Cheshire & Krochmal          Standards Track                   [Page 66]   

 3628 RFC 6762                      Multicast DNS                February 2013   
 3631    in Multicast DNS messages.  Any text being represented internally in    
 3632    some other representation must be converted to canonical precomposed    
 3633    UTF-8 before being placed in any Multicast DNS message.                 
line-905 Nathan Osman(Technical Erratum #4977) [Reported]
based on outdated version
The 'Next Domain Name' field contains the record's own name. When
used with name compression, this means that the 'Next Domain Name'
field always takes exactly two bytes in the message.
It should say:
The 'Next Domain Name' field contains the record's own name. When
used with name compression, this means that the 'Next Domain Name'
field always takes exactly two bytes in the message.

Section 4.1.1 of RFC 4034 states:

"A sender MUST NOT use DNS name compression on the Next Domain Name field when transmitting an NSEC RR."

In order to comply with the existing RFC, name compression should not be suggested.
 3635 Appendix G.  Private DNS Namespaces                                        
 3637    The special treatment of names ending in ".local." has been             
 3638    implemented in Macintosh computers since the days of Mac OS 9, and      
 3639    continues today in Mac OS X and iOS.  There are also implementations    
 3640    for Microsoft Windows [B4W], Linux, and other platforms.                
 3642    Some network operators setting up private internal networks             
 3643    ("intranets") have used unregistered top-level domains, and some may    
 3644    have used the ".local" top-level domain.  Using ".local" as a private   
 3645    top-level domain conflicts with Multicast DNS and may cause problems    
 3646    for users.  Clients can be configured to send both Multicast and        
 3647    Unicast DNS queries in parallel for these names, and this does allow    
 3648    names to be looked up both ways, but this results in additional         
 3649    network traffic and additional delays in name resolution, as well as    
 3650    potentially creating user confusion when it is not clear whether any    
 3651    given result was received via link-local multicast from a peer on the   
 3652    same link, or from the configured unicast name server.  Because of      
 3653    this, we recommend against using ".local" as a private Unicast DNS      
 3654    top-level domain.  We do not recommend use of unregistered top-level    
 3655    domains at all, but should network operators decide to do this, the     
 3656    following top-level domains have been used on private internal          
 3657    networks without the problems caused by trying to reuse ".local." for   
 3658    this purpose:                                                           
 3660       .intranet.                                                           
 3661       .internal.                                                           
 3662       .private.                                                            
 3663       .corp.                                                               
 3664       .home.                                                               
 3665       .lan.                                                                
 3667 Appendix H.  Deployment History                                            
 3669    In July 1997, in an email to the net-thinkers@thumper.vmeng.com         
 3670    mailing list, Stuart Cheshire first proposed the idea of running the    
 3671    AppleTalk Name Binding Protocol [RFC6760] over IP.  As a result of      
 3672    this and related IETF discussions, the IETF Zeroconf working group      
 3673    was chartered September 1999.  After various working group              
 3674    discussions and other informal IETF discussions, several Internet-      
 3675    Drafts were written that were loosely related to the general themes     
 3676    of DNS and multicast, but did not address the service discovery         
 3677    aspect of NBP.                                                          
 3682 Cheshire & Krochmal          Standards Track                   [Page 67]   

 3683 RFC 6762                      Multicast DNS                February 2013   
 3686    In April 2000, Stuart Cheshire registered IPv4 multicast address        
 3687 with IANA [MC4] and began writing code to test and          
 3688    develop the idea of performing NBP-like service discovery using         
 3689    Multicast DNS, which was documented in a group of three Internet-       
 3690    Drafts:                                                                 
 3692    o "Requirements for a Protocol to Replace the AppleTalk Name Binding    
 3693      Protocol (NBP)" [RFC6760] is an overview explaining the AppleTalk     
 3694      Name Binding Protocol, because many in the IETF community had         
 3695      little first-hand experience using AppleTalk, and confusion in the    
 3696      IETF community about what AppleTalk NBP did was causing confusion     
 3697      about what would be required in an IP-based replacement.              
 3699    o "Discovering Named Instances of Abstract Services using DNS" [NIAS]   
 3700      proposed a way to perform NBP-like service discovery using DNS-       
 3701      compatible names and record types.                                    
 3703    o "Multicast DNS" (this document) specifies a way to transport those    
 3704      DNS-compatible queries and responses using IP multicast, for zero-    
 3705      configuration environments where no conventional Unicast DNS server   
 3706      was available.                                                        
 3708    In 2001, an update to Mac OS 9 added resolver library support for       
 3709    host name lookup using Multicast DNS.  If the user typed a name such    
 3710    as "MyPrinter.local." into any piece of networking software that used   
 3711    the standard Mac OS 9 name lookup APIs, then those name lookup APIs     
 3712    would recognize the name as a dot-local name and query for it by        
 3713    sending simple one-shot Multicast DNS queries to      
 3714    This enabled the user to, for example, enter the name                   
 3715    "MyPrinter.local." into their web browser in order to view a            
 3716    printer's status and configuration web page, or enter the name          
 3717    "MyPrinter.local." into the printer setup utility to create a print     
 3718    queue for printing documents on that printer.                           
 3720    Multicast DNS responder software, with full service discovery, first    
 3721    began shipping to end users in volume with the launch of Mac OS X       
 3722    10.2 "Jaguar" in August 2002, and network printer makers (who had       
 3723    historically supported AppleTalk in their network printers and were     
 3724    receptive to IP-based technologies that could offer them similar        
 3725    ease-of-use) started adopting Multicast DNS shortly thereafter.         
 3727    In September 2002, Apple released the source code for the               
 3728    mDNSResponder daemon as Open Source under Apple's standard Apple        
 3729    Public Source License (APSL).                                           
 3731    Multicast DNS responder software became available for Microsoft         
 3732    Windows users in June 2004 with the launch of Apple's "Rendezvous for   
 3733    Windows" (now "Bonjour for Windows"), both in executable form (a        
 3737 Cheshire & Krochmal          Standards Track                   [Page 68]   

 3738 RFC 6762                      Multicast DNS                February 2013   
 3741    downloadable installer for end users) and as Open Source (one of the    
 3742    supported platforms within Apple's body of cross-platform code in the   
 3743    publicly accessible mDNSResponder CVS source code repository) [BJ].     
 3745    In August 2006, Apple re-licensed the cross-platform mDNSResponder      
 3746    source code under the Apache License, Version 2.0.                      
 3748    In addition to desktop and laptop computers running Mac OS X and        
 3749    Microsoft Windows, Multicast DNS is now implemented in a wide range     
 3750    of hardware devices, such as Apple's "AirPort" wireless base            
 3751    stations, iPhone and iPad, and in home gateways from other vendors,     
 3752    network printers, network cameras, TiVo DVRs, etc.                      
 3754    The Open Source community has produced many independent                 
 3755    implementations of Multicast DNS, some in C like Apple's                
 3756    mDNSResponder daemon, and others in a variety of different languages    
 3757    including Java, Python, Perl, and C#/Mono.                              
 3759    In January 2007, the IETF published the Informational RFC "Link-Local   
 3760    Multicast Name Resolution (LLMNR)" [RFC4795], which is substantially    
 3761    similar to Multicast DNS, but incompatible in some small but            
 3762    important ways.  In particular, the LLMNR design explicitly excluded    
 3763    support for service discovery, which made it an unsuitable candidate    
 3764    for a protocol to replace AppleTalk NBP [RFC6760].                      
 3766    While the original focus of Multicast DNS and DNS-Based Service         
 3767    Discovery was for zero-configuration environments without a             
 3768    conventional Unicast DNS server, DNS-Based Service Discovery also       
 3769    works using Unicast DNS servers, using DNS Update [RFC2136] [RFC3007]   
 3770    to create service discovery records and standard DNS queries to query   
 3771    for them.  Apple's Back to My Mac service, launched with Mac OS X       
 3772    10.5 "Leopard" in October 2007, uses DNS-Based Service Discovery over   
 3773    Unicast DNS [RFC6281].                                                  
 3775    In June 2012, Google's Android operating system added native support    
 3776    for DNS-SD and Multicast DNS with the android.net.nsd.NsdManager        
 3777    class in Android 4.1 "Jelly Bean" (API Level 16) [NSD].                 
 3792 Cheshire & Krochmal          Standards Track                   [Page 69]   

 3793 RFC 6762                      Multicast DNS                February 2013   
 3796 Authors' Addresses                                                         
 3798    Stuart Cheshire                                                         
 3799    Apple Inc.                                                              
 3800    1 Infinite Loop                                                         
 3801    Cupertino, CA  95014                                                    
 3802    USA                                                                     
 3804    Phone: +1 408 974 3207                                                  
 3805    EMail: cheshire@apple.com                                               
 3808    Marc Krochmal                                                           
 3809    Apple Inc.                                                              
 3810    1 Infinite Loop                                                         
 3811    Cupertino, CA  95014                                                    
 3812    USA                                                                     
 3814    Phone: +1 408 974 4368                                                  
 3815    EMail: marc@apple.com                                                   
 3847 Cheshire & Krochmal          Standards Track                   [Page 70]   
appendix-G Willem Bermon(Technical Erratum #4529) [Rejected]
based on outdated version
We do not recommend use of unregistered top-level
   domains at all, but should network operators decide to do this, the
   following top-level domains have been used on private internal
   networks without the problems caused by trying to reuse ".local." for
   this purpose:

It should say:
We do not recommend use of unregistered top-level domains.

Since TLDs like .private are currently available for register. Appendix
G is outdated and I would strongly advise the IETF to remove the
suggested TLDs since they are no longer problem free. I believe that it
is wise to make a harder statement in the RFC.
During the development of this RFC, the text is consistent with the
consensus of the community. Later developments by ICANN superseded the
appendix, but that is not applicable for an erratum. Updates to the text
should be proposed via the draft publication process.