tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6762

 Errata 
Proposed STD
Pages: 70
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~dns

Multicast DNS

Part 1 of 4, p. 1 to 22
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                       S. Cheshire
Request for Comments: 6762                                   M. Krochmal
Category: Standards Track                                     Apple Inc.
ISSN: 2070-1721                                            February 2013


                             Multicast DNS

Abstract

   As networked devices become smaller, more portable, and more
   ubiquitous, the ability to operate with less configured
   infrastructure is increasingly important.  In particular, the ability
   to look up DNS resource record data types (including, but not limited
   to, host names) in the absence of a conventional managed DNS server
   is useful.

   Multicast DNS (mDNS) provides the ability to perform DNS-like
   operations on the local link in the absence of any conventional
   Unicast DNS server.  In addition, Multicast DNS designates a portion
   of the DNS namespace to be free for local use, without the need to
   pay any annual fee, and without the need to set up delegations or
   otherwise configure a conventional DNS server to answer for those
   names.

   The primary benefits of Multicast DNS names are that (i) they require
   little or no administration or configuration to set them up, (ii)
   they work when no infrastructure is present, and (iii) they work
   during infrastructure failures.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6762.

Page 2 
Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Top       Page 3 
Table of Contents

   1. Introduction ....................................................4
   2. Conventions and Terminology Used in This Document ...............4
   3. Multicast DNS Names .............................................5
   4. Reverse Address Mapping .........................................7
   5. Querying ........................................................8
   6. Responding .....................................................13
   7. Traffic Reduction ..............................................22
   8. Probing and Announcing on Startup ..............................25
   9. Conflict Resolution ............................................31
   10. Resource Record TTL Values and Cache Coherency ................33
   11. Source Address Check ..........................................38
   12. Special Characteristics of Multicast DNS Domains ..............40
   13. Enabling and Disabling Multicast DNS ..........................41
   14. Considerations for Multiple Interfaces ........................42
   15. Considerations for Multiple Responders on the Same Machine ....43
   16. Multicast DNS Character Set ...................................45
   17. Multicast DNS Message Size ....................................46
   18. Multicast DNS Message Format ..................................47
   19. Summary of Differences between Multicast DNS and Unicast DNS ..51
   20. IPv6 Considerations ...........................................52
   21. Security Considerations .......................................52
   22. IANA Considerations ...........................................53
   23. Acknowledgments ...............................................56
   24. References ....................................................56
   Appendix A. Design Rationale for Choice of UDP Port Number ........60
   Appendix B. Design Rationale for Not Using Hashed Multicast
               Addresses .............................................61
   Appendix C. Design Rationale for Maximum Multicast DNS Name
               Length ................................................62
   Appendix D. Benefits of Multicast Responses .......................64
   Appendix E. Design Rationale for Encoding Negative Responses ......65
   Appendix F. Use of UTF-8 ..........................................66
   Appendix G. Private DNS Namespaces ................................67
   Appendix H. Deployment History ....................................67

Top      ToC       Page 4 
1.  Introduction

   Multicast DNS and its companion technology DNS-Based Service
   Discovery [RFC6763] were created to provide IP networking with the
   ease-of-use and autoconfiguration for which AppleTalk was well-known
   [RFC6760].  When reading this document, familiarity with the concepts
   of Zero Configuration Networking [Zeroconf] and automatic link-local
   addressing [RFC3927] [RFC4862] is helpful.

   Multicast DNS borrows heavily from the existing DNS protocol
   [RFC1034] [RFC1035] [RFC6195], using the existing DNS message
   structure, name syntax, and resource record types.  This document
   specifies no new operation codes or response codes.  This document
   describes how clients send DNS-like queries via IP multicast, and how
   a collection of hosts cooperate to collectively answer those queries
   in a useful manner.

2.  Conventions and Terminology Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in "Key words for use in
   RFCs to Indicate Requirement Levels" [RFC2119].

   When this document uses the term "Multicast DNS", it should be taken
   to mean: "Clients performing DNS-like queries for DNS-like resource
   records by sending DNS-like UDP query and response messages over IP
   Multicast to UDP port 5353".  The design rationale for selecting UDP
   port 5353 is discussed in Appendix A.

   This document uses the term "host name" in the strict sense to mean a
   fully qualified domain name that has an IPv4 or IPv6 address record.
   It does not use the term "host name" in the commonly used but
   incorrect sense to mean just the first DNS label of a host's fully
   qualified domain name.

   A DNS (or mDNS) packet contains an IP Time to Live (TTL) in the IP
   header, which is effectively a hop-count limit for the packet, to
   guard against routing loops.  Each resource record also contains a
   TTL, which is the number of seconds for which the resource record may
   be cached.  This document uses the term "IP TTL" to refer to the IP
   header TTL (hop limit), and the term "RR TTL" or just "TTL" to refer
   to the resource record TTL (cache lifetime).

   DNS-format messages contain a header, a Question Section, then
   Answer, Authority, and Additional Record Sections.  The Answer,
   Authority, and Additional Record Sections all hold resource records

Top      ToC       Page 5 
   in the same format.  Where this document describes issues that apply
   equally to all three sections, it uses the term "Resource Record
   Sections" to refer collectively to these three sections.

   This document uses the terms "shared" and "unique" when referring to
   resource record sets [RFC1034]:

      A "shared" resource record set is one where several Multicast DNS
      responders may have records with the same name, rrtype, and
      rrclass, and several responders may respond to a particular query.

      A "unique" resource record set is one where all the records with
      that name, rrtype, and rrclass are conceptually under the control
      or ownership of a single responder, and it is expected that at
      most one responder should respond to a query for that name,
      rrtype, and rrclass.  Before claiming ownership of a unique
      resource record set, a responder MUST probe to verify that no
      other responder already claims ownership of that set, as described
      in Section 8.1, "Probing".  (For fault-tolerance and other
      reasons, sometimes it is permissible to have more than one
      responder answering for a particular "unique" resource record set,
      but such cooperating responders MUST give answers containing
      identical rdata for these records.  If they do not give answers
      containing identical rdata, then the probing step will reject the
      data as being inconsistent with what is already being advertised
      on the network for those names.)

   Strictly speaking, the terms "shared" and "unique" apply to resource
   record sets, not to individual resource records.  However, it is
   sometimes convenient to talk of "shared resource records" and "unique
   resource records".  When used this way, the terms should be
   understood to mean a record that is a member of a "shared" or
   "unique" resource record set, respectively.

3.  Multicast DNS Names

   A host that belongs to an organization or individual who has control
   over some portion of the DNS namespace can be assigned a globally
   unique name within that portion of the DNS namespace, such as,
   "cheshire.example.com.".  For those of us who have this luxury, this
   works very well.  However, the majority of home computer users do not
   have easy access to any portion of the global DNS namespace within
   which they have the authority to create names.  This leaves the
   majority of home computers effectively anonymous for practical
   purposes.

Top      ToC       Page 6 
   To remedy this problem, this document allows any computer user to
   elect to give their computers link-local Multicast DNS host names of
   the form: "single-dns-label.local.".  For example, a laptop computer
   may answer to the name "MyComputer.local.".  Any computer user is
   granted the authority to name their computer this way, provided that
   the chosen host name is not already in use on that link.  Having
   named their computer this way, the user has the authority to continue
   utilizing that name until such time as a name conflict occurs on the
   link that is not resolved in the user's favor.  If this happens, the
   computer (or its human user) MUST cease using the name, and SHOULD
   attempt to allocate a new unique name for use on that link.  These
   conflicts are expected to be relatively rare for people who choose
   reasonably imaginative names, but it is still important to have a
   mechanism in place to handle them when they happen.

   This document specifies that the DNS top-level domain ".local." is a
   special domain with special semantics, namely that any fully
   qualified name ending in ".local." is link-local, and names within
   this domain are meaningful only on the link where they originate.
   This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6
   addresses in the FE80::/10 prefix, which are link-local and
   meaningful only on the link where they originate.

   Any DNS query for a name ending with ".local." MUST be sent to the
   mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6
   equivalent FF02::FB).  The design rationale for using a fixed
   multicast address instead of selecting from a range of multicast
   addresses using a hash function is discussed in Appendix B.
   Implementers MAY choose to look up such names concurrently via other
   mechanisms (e.g., Unicast DNS) and coalesce the results in some
   fashion.  Implementers choosing to do this should be aware of the
   potential for user confusion when a given name can produce different
   results depending on external network conditions (such as, but not
   limited to, which name lookup mechanism responds faster).

   It is unimportant whether a name ending with ".local." occurred
   because the user explicitly typed in a fully qualified domain name
   ending in ".local.", or because the user entered an unqualified
   domain name and the host software appended the suffix ".local."
   because that suffix appears in the user's search list.  The ".local."
   suffix could appear in the search list because the user manually
   configured it, or because it was received via DHCP [RFC2132] or via
   any other mechanism for configuring the DNS search list.  In this
   respect the ".local." suffix is treated no differently from any other
   search domain that might appear in the DNS search list.

Top      ToC       Page 7 
   DNS queries for names that do not end with ".local." MAY be sent to
   the mDNS multicast address, if no other conventional DNS server is
   available.  This can allow hosts on the same link to continue
   communicating using each other's globally unique DNS names during
   network outages that disrupt communication with the greater Internet.
   When resolving global names via local multicast, it is even more
   important to use DNS Security Extensions (DNSSEC) [RFC4033] or other
   security mechanisms to ensure that the response is trustworthy.
   Resolving global names via local multicast is a contentious issue,
   and this document does not discuss it further, instead concentrating
   on the issue of resolving local names using DNS messages sent to a
   multicast address.

   This document recommends a single flat namespace for dot-local host
   names, (i.e., the names of DNS "A" and "AAAA" records, which map
   names to IPv4 and IPv6 addresses), but other DNS record types (such
   as those used by DNS-Based Service Discovery [RFC6763]) may contain
   as many labels as appropriate for the desired usage, up to a maximum
   of 255 bytes, plus a terminating zero byte at the end.  Name length
   issues are discussed further in Appendix C.

   Enforcing uniqueness of host names is probably desirable in the
   common case, but this document does not mandate that.  It is
   permissible for a collection of coordinated hosts to agree to
   maintain multiple DNS address records with the same name, possibly
   for load-balancing or fault-tolerance reasons.  This document does
   not take a position on whether that is sensible.  It is important
   that both modes of operation be supported.  The Multicast DNS
   protocol allows hosts to verify and maintain unique names for
   resource records where that behavior is desired, and it also allows
   hosts to maintain multiple resource records with a single shared name
   where that behavior is desired.  This consideration applies to all
   resource records, not just address records (host names).  In summary:
   It is required that the protocol have the ability to detect and
   handle name conflicts, but it is not required that this ability be
   used for every record.

4.  Reverse Address Mapping

   Like ".local.", the IPv4 and IPv6 reverse mapping domains are also
   defined to be link-local:

      Any DNS query for a name ending with "254.169.in-addr.arpa." MUST
      be sent to the mDNS IPv4 link-local multicast address 224.0.0.251
      or the mDNS IPv6 multicast address FF02::FB.  Since names under
      this domain correspond to IPv4 link-local addresses, it is logical
      that the local link is the best place to find information
      pertaining to those names.

Top      ToC       Page 8 
      Likewise, any DNS query for a name within the reverse mapping
      domains for IPv6 link-local addresses ("8.e.f.ip6.arpa.",
      "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.") MUST
      be sent to the mDNS IPv6 link-local multicast address FF02::FB or
      the mDNS IPv4 link-local multicast address 224.0.0.251.

5.  Querying

   There are two kinds of Multicast DNS queries: one-shot queries of the
   kind made by legacy DNS resolvers, and continuous, ongoing Multicast
   DNS queries made by fully compliant Multicast DNS queriers, which
   support asynchronous operations including DNS-Based Service Discovery
   [RFC6763].

   Except in the rare case of a Multicast DNS responder that is
   advertising only shared resource records and no unique records, a
   Multicast DNS responder MUST also implement a Multicast DNS querier
   so that it can first verify the uniqueness of those records before it
   begins answering queries for them.

5.1.  One-Shot Multicast DNS Queries

   The most basic kind of Multicast DNS client may simply send standard
   DNS queries blindly to 224.0.0.251:5353, without necessarily even
   being aware of what a multicast address is.  This change can
   typically be implemented with just a few lines of code in an existing
   DNS resolver library.  If a name being queried falls within one of
   the reserved Multicast DNS domains (see Sections 3 and 4), then,
   rather than using the configured Unicast DNS server address, the
   query is instead sent to 224.0.0.251:5353 (or its IPv6 equivalent
   [FF02::FB]:5353).  Typically, the timeout would also be shortened to
   two or three seconds.  It's possible to make a minimal Multicast DNS
   resolver with only these simple changes.  These queries are typically
   done using a high-numbered ephemeral UDP source port, but regardless
   of whether they are sent from a dynamic port or from a fixed port,
   these queries MUST NOT be sent using UDP source port 5353, since
   using UDP source port 5353 signals the presence of a fully compliant
   Multicast DNS querier, as described below.

   A simple DNS resolver like this will typically just take the first
   response it receives.  It will not listen for additional UDP
   responses, but in many instances this may not be a serious problem.
   If a user types "http://MyPrinter.local." into their web browser, and
   their simple DNS resolver just takes the first response it receives,
   and the user gets to see the status and configuration web page for
   their printer, then the protocol has met the user's needs in this
   case.

Top      ToC       Page 9 
   While a basic DNS resolver like this may be adequate for simple host
   name lookup, it may not get ideal behavior in other cases.
   Additional refinements to create a fully compliant Multicast DNS
   querier are described below.

5.2.  Continuous Multicast DNS Querying

   In one-shot queries, the underlying assumption is that the
   transaction begins when the application issues a query, and ends when
   the first response is received.  There is another type of query
   operation that is more asynchronous, in which having received one
   response is not necessarily an indication that there will be no more
   relevant responses, and the querying operation continues until no
   further responses are required.  Determining when no further
   responses are required depends on the type of operation being
   performed.  If the operation is looking up the IPv4 and IPv6
   addresses of another host, then no further responses are required
   once a successful connection has been made to one of those IPv4 or
   IPv6 addresses.  If the operation is browsing to present the user
   with a list of DNS-SD services found on the network [RFC6763], then
   no further responses are required once the user indicates this to the
   user-interface software, e.g., by closing the network browsing window
   that was displaying the list of discovered services.

   Imagine some hypothetical software that allows users to discover
   network printers.  The user wishes to discover all printers on the
   local network, not only the printer that is quickest to respond.
   When the user is actively looking for a network printer to use, they
   open a network browsing window that displays the list of discovered
   printers.  It would be convenient for the user if they could rely on
   this list of network printers to stay up to date as network printers
   come and go, rather than displaying out-of-date stale information,
   and requiring the user explicitly to click a "refresh" button any
   time they want to see accurate information (which, from the moment it
   is displayed, is itself already beginning to become out-of-date and
   stale).  If we are to display a continuously updated live list like
   this, we need to be able to do it efficiently, without naive constant
   polling, which would be an unreasonable burden on the network.  It is
   not expected that all users will be browsing to discover new printers
   all the time, but when a user is browsing to discover service
   instances for an extended period, we want to be able to support that
   operation efficiently.

   Therefore, when retransmitting Multicast DNS queries to implement
   this kind of continuous monitoring, the interval between the first
   two queries MUST be at least one second, the intervals between
   successive queries MUST increase by at least a factor of two, and the
   querier MUST implement Known-Answer Suppression, as described below

Top      ToC       Page 10 
   in Section 7.1.  The Known-Answer Suppression mechanism tells
   responders which answers are already known to the querier, thereby
   allowing responders to avoid wasting network capacity with pointless
   repeated transmission of those answers.  A querier retransmits its
   question because it wishes to receive answers it may have missed the
   first time, not because it wants additional duplicate copies of
   answers it already received.  Failure to implement Known-Answer
   Suppression can result in unacceptable levels of network traffic.
   When the interval between queries reaches or exceeds 60 minutes, a
   querier MAY cap the interval to a maximum of 60 minutes, and perform
   subsequent queries at a steady-state rate of one query per hour.  To
   avoid accidental synchronization when, for some reason, multiple
   clients begin querying at exactly the same moment (e.g., because of
   some common external trigger event), a Multicast DNS querier SHOULD
   also delay the first query of the series by a randomly chosen amount
   in the range 20-120 ms.

   When a Multicast DNS querier receives an answer, the answer contains
   a TTL value that indicates for how many seconds this answer is valid.
   After this interval has passed, the answer will no longer be valid
   and SHOULD be deleted from the cache.  Before the record expiry time
   is reached, a Multicast DNS querier that has local clients with an
   active interest in the state of that record (e.g., a network browsing
   window displaying a list of discovered services to the user) SHOULD
   reissue its query to determine whether the record is still valid.

   To perform this cache maintenance, a Multicast DNS querier should
   plan to retransmit its query after at least 50% of the record
   lifetime has elapsed.  This document recommends the following
   specific strategy.

   The querier should plan to issue a query at 80% of the record
   lifetime, and then if no answer is received, at 85%, 90%, and 95%.
   If an answer is received, then the remaining TTL is reset to the
   value given in the answer, and this process repeats for as long as
   the Multicast DNS querier has an ongoing interest in the record.  If
   no answer is received after four queries, the record is deleted when
   it reaches 100% of its lifetime.  A Multicast DNS querier MUST NOT
   perform this cache maintenance for records for which it has no local
   clients with an active interest.  If the expiry of a particular
   record from the cache would result in no net effect to any client
   software running on the querier device, and no visible effect to the
   human user, then there is no reason for the Multicast DNS querier to
   waste network capacity checking whether the record remains valid.

Top      ToC       Page 11 
   To avoid the case where multiple Multicast DNS queriers on a network
   all issue their queries simultaneously, a random variation of 2% of
   the record TTL should be added, so that queries are scheduled to be
   performed at 80-82%, 85-87%, 90-92%, and then 95-97% of the TTL.

   An additional efficiency optimization SHOULD be performed when a
   Multicast DNS response is received containing a unique answer (as
   indicated by the cache-flush bit being set, described in Section
   10.2, "Announcements to Flush Outdated Cache Entries").  In this
   case, there is no need for the querier to continue issuing a stream
   of queries with exponentially increasing intervals, since the receipt
   of a unique answer is a good indication that no other answers will be
   forthcoming.  In this case, the Multicast DNS querier SHOULD plan to
   issue its next query for this record at 80-82% of the record's TTL,
   as described above.

   A compliant Multicast DNS querier, which implements the rules
   specified in this document, MUST send its Multicast DNS queries from
   UDP source port 5353 (the well-known port assigned to mDNS), and MUST
   listen for Multicast DNS replies sent to UDP destination port 5353 at
   the mDNS link-local multicast address (224.0.0.251 and/or its IPv6
   equivalent FF02::FB).

5.3.  Multiple Questions per Query

   Multicast DNS allows a querier to place multiple questions in the
   Question Section of a single Multicast DNS query message.

   The semantics of a Multicast DNS query message containing multiple
   questions is identical to a series of individual DNS query messages
   containing one question each.  Combining multiple questions into a
   single message is purely an efficiency optimization and has no other
   semantic significance.

5.4.  Questions Requesting Unicast Responses

   Sending Multicast DNS responses via multicast has the benefit that
   all the other hosts on the network get to see those responses,
   enabling them to keep their caches up to date and detect conflicting
   responses.

   However, there are situations where all the other hosts on the
   network don't need to see every response.  Some examples are a laptop
   computer waking from sleep, the Ethernet cable being connected to a
   running machine, or a previously inactive interface being activated
   through a configuration change.  At the instant of wake-up or link
   activation, the machine is a brand new participant on a new network.
   Its Multicast DNS cache for that interface is empty, and it has no

Top      ToC       Page 12 
   knowledge of its peers on that link.  It may have a significant
   number of questions that it wants answered right away, to discover
   information about its new surroundings and present that information
   to the user.  As a new participant on the network, it has no idea
   whether the exact same questions may have been asked and answered
   just seconds ago.  In this case, triggering a large sudden flood of
   multicast responses may impose an unreasonable burden on the network.

   To avoid large floods of potentially unnecessary responses in these
   cases, Multicast DNS defines the top bit in the class field of a DNS
   question as the unicast-response bit.  When this bit is set in a
   question, it indicates that the querier is willing to accept unicast
   replies in response to this specific query, as well as the usual
   multicast responses.  These questions requesting unicast responses
   are referred to as "QU" questions, to distinguish them from the more
   usual questions requesting multicast responses ("QM" questions).  A
   Multicast DNS querier sending its initial batch of questions
   immediately on wake from sleep or interface activation SHOULD set the
   unicast-response bit in those questions.

   When a question is retransmitted (as described in Section 5.2), the
   unicast-response bit SHOULD NOT be set in subsequent retransmissions
   of that question.  Subsequent retransmissions SHOULD be usual "QM"
   questions.  After the first question has received its responses, the
   querier should have a large Known-Answer list (Section 7.1) so that
   subsequent queries should elicit few, if any, further responses.
   Reverting to multicast responses as soon as possible is important
   because of the benefits that multicast responses provide (see
   Appendix D).  In addition, the unicast-response bit SHOULD be set
   only for questions that are active and ready to be sent the moment of
   wake from sleep or interface activation.  New questions created by
   local clients afterwards should be treated as normal "QM" questions
   and SHOULD NOT have the unicast-response bit set on the first
   question of the series.

   When receiving a question with the unicast-response bit set, a
   responder SHOULD usually respond with a unicast packet directed back
   to the querier.  However, if the responder has not multicast that
   record recently (within one quarter of its TTL), then the responder
   SHOULD instead multicast the response so as to keep all the peer
   caches up to date, and to permit passive conflict detection.  In the
   case of answering a probe question (Section 8.1) with the unicast-
   response bit set, the responder should always generate the requested
   unicast response, but it may also send a multicast announcement if
   the time since the last multicast announcement of that record is more
   than a quarter of its TTL.

Top      ToC       Page 13 
   Unicast replies are subject to all the same packet generation rules
   as multicast replies, including the cache-flush bit (Section 10.2)
   and (except when defending a unique name against a probe from another
   host) randomized delays to reduce network collisions (Section 6).

5.5.  Direct Unicast Queries to Port 5353

   In specialized applications there may be rare situations where it
   makes sense for a Multicast DNS querier to send its query via unicast
   to a specific machine.  When a Multicast DNS responder receives a
   query via direct unicast, it SHOULD respond as it would for "QU"
   questions, as described above in Section 5.4.  Since it is possible
   for a unicast query to be received from a machine outside the local
   link, responders SHOULD check that the source address in the query
   packet matches the local subnet for that link (or, in the case of
   IPv6, the source address has an on-link prefix) and silently ignore
   the packet if not.

   There may be specialized situations, outside the scope of this
   document, where it is intended and desirable to create a responder
   that does answer queries originating outside the local link.  Such a
   responder would need to ensure that these non-local queries are
   always answered via unicast back to the querier, since an answer sent
   via link-local multicast would not reach a querier outside the local
   link.

6.  Responding

   When a Multicast DNS responder constructs and sends a Multicast DNS
   response message, the Resource Record Sections of that message must
   contain only records for which that responder is explicitly
   authoritative.  These answers may be generated because the record
   answers a question received in a Multicast DNS query message, or at
   certain other times that the responder determines than an unsolicited
   announcement is warranted.  A Multicast DNS responder MUST NOT place
   records from its cache, which have been learned from other responders
   on the network, in the Resource Record Sections of outgoing response
   messages.  Only an authoritative source for a given record is allowed
   to issue responses containing that record.

   The determination of whether a given record answers a given question
   is made using the standard DNS rules: the record name must match the
   question name, the record rrtype must match the question qtype unless
   the qtype is "ANY" (255) or the rrtype is "CNAME" (5), and the record
   rrclass must match the question qclass unless the qclass is "ANY"
   (255).  As with Unicast DNS, generally only DNS class 1 ("Internet")
   is used, but should client software use classes other than 1, the
   matching rules described above MUST be used.

Top      ToC       Page 14 
   A Multicast DNS responder MUST only respond when it has a positive,
   non-null response to send, or it authoritatively knows that a
   particular record does not exist.  For unique records, where the host
   has already established sole ownership of the name, it MUST return
   negative answers to queries for records that it knows not to exist.
   For example, a host with no IPv6 address, that has claimed sole
   ownership of the name "host.local." for all rrtypes, MUST respond to
   AAAA queries for "host.local." by sending a negative answer
   indicating that no AAAA records exist for that name.  See Section
   6.1, "Negative Responses".  For shared records, which are owned by no
   single host, the nonexistence of a given record is ascertained by the
   failure of any machine to respond to the Multicast DNS query, not by
   any explicit negative response.  For shared records, NXDOMAIN and
   other error responses MUST NOT be sent.

   Multicast DNS responses MUST NOT contain any questions in the
   Question Section.  Any questions in the Question Section of a
   received Multicast DNS response MUST be silently ignored.  Multicast
   DNS queriers receiving Multicast DNS responses do not care what
   question elicited the response; they care only that the information
   in the response is true and accurate.

   A Multicast DNS responder on Ethernet [IEEE.802.3] and similar shared
   multiple access networks SHOULD have the capability of delaying its
   responses by up to 500 ms, as described below.

   If a large number of Multicast DNS responders were all to respond
   immediately to a particular query, a collision would be virtually
   guaranteed.  By imposing a small random delay, the number of
   collisions is dramatically reduced.  On a full-sized Ethernet using
   the maximum cable lengths allowed and the maximum number of repeaters
   allowed, an Ethernet frame is vulnerable to collisions during the
   transmission of its first 256 bits.  On 10 Mb/s Ethernet, this
   equates to a vulnerable time window of 25.6 microseconds.  On higher-
   speed variants of Ethernet, the vulnerable time window is shorter.

   In the case where a Multicast DNS responder has good reason to
   believe that it will be the only responder on the link that will send
   a response (i.e., because it is able to answer every question in the
   query message, and for all of those answer records it has previously
   verified that the name, rrtype, and rrclass are unique on the link),
   it SHOULD NOT impose any random delay before responding, and SHOULD
   normally generate its response within at most 10 ms.  In particular,
   this applies to responding to probe queries with the unicast-response
   bit set.  Since receiving a probe query gives a clear indication that
   some other responder is planning to start using this name in the very
   near future, answering such probe queries to defend a unique record
   is a high priority and needs to be done without delay.  A probe query

Top      ToC       Page 15 
   can be distinguished from a normal query by the fact that a probe
   query contains a proposed record in the Authority Section that
   answers the question in the Question Section (for more details, see
   Section 8.2, "Simultaneous Probe Tiebreaking").

   Responding without delay is appropriate for records like the address
   record for a particular host name, when the host name has been
   previously verified unique.  Responding without delay is *not*
   appropriate for things like looking up PTR records used for DNS-Based
   Service Discovery [RFC6763], where a large number of responses may be
   anticipated.

   In any case where there may be multiple responses, such as queries
   where the answer is a member of a shared resource record set, each
   responder SHOULD delay its response by a random amount of time
   selected with uniform random distribution in the range 20-120 ms.
   The reason for requiring that the delay be at least 20 ms is to
   accommodate the situation where two or more query packets are sent
   back-to-back, because in that case we want a responder with answers
   to more than one of those queries to have the opportunity to
   aggregate all of its answers into a single response message.

   In the case where the query has the TC (truncated) bit set,
   indicating that subsequent Known-Answer packets will follow,
   responders SHOULD delay their responses by a random amount of time
   selected with uniform random distribution in the range 400-500 ms, to
   allow enough time for all the Known-Answer packets to arrive, as
   described in Section 7.2, "Multipacket Known-Answer Suppression".

   The source UDP port in all Multicast DNS responses MUST be 5353 (the
   well-known port assigned to mDNS).  Multicast DNS implementations
   MUST silently ignore any Multicast DNS responses they receive where
   the source UDP port is not 5353.

   The destination UDP port in all Multicast DNS responses MUST be 5353,
   and the destination address MUST be the mDNS IPv4 link-local
   multicast address 224.0.0.251 or its IPv6 equivalent FF02::FB, except
   when generating a reply to a query that explicitly requested a
   unicast response:

      * via the unicast-response bit,
      * by virtue of being a legacy query (Section 6.7), or
      * by virtue of being a direct unicast query.

   Except for these three specific cases, responses MUST NOT be sent via
   unicast, because then the "Passive Observation of Failures"
   mechanisms described in Section 10.5 would not work correctly.  Other

Top      ToC       Page 16 
   benefits of sending responses via multicast are discussed in Appendix
   D.  A Multicast DNS querier MUST only accept unicast responses if
   they answer a recently sent query (e.g., sent within the last two
   seconds) that explicitly requested unicast responses.  A Multicast
   DNS querier MUST silently ignore all other unicast responses.

   To protect the network against excessive packet flooding due to
   software bugs or malicious attack, a Multicast DNS responder MUST NOT
   (except in the one special case of answering probe queries) multicast
   a record on a given interface until at least one second has elapsed
   since the last time that record was multicast on that particular
   interface.  A legitimate querier on the network should have seen the
   previous transmission and cached it.  A querier that did not receive
   and cache the previous transmission will retry its request and
   receive a subsequent response.  In the special case of answering
   probe queries, because of the limited time before the probing host
   will make its decision about whether or not to use the name, a
   Multicast DNS responder MUST respond quickly.  In this special case
   only, when responding via multicast to a probe, a Multicast DNS
   responder is only required to delay its transmission as necessary to
   ensure an interval of at least 250 ms since the last time the record
   was multicast on that interface.

6.1.  Negative Responses

   In the early design of Multicast DNS it was assumed that explicit
   negative responses would never be needed.  A host can assert the
   existence of the set of records that it claims to exist, and the
   union of all such sets on a link is the set of Multicast DNS records
   that exist on that link.  Asserting the nonexistence of every record
   in the complement of that set -- i.e., all possible Multicast DNS
   records that could exist on this link but do not at this moment --
   was felt to be impractical and unnecessary.  The nonexistence of a
   record would be ascertained by a querier querying for it and failing
   to receive a response from any of the hosts currently attached to the
   link.

   However, operational experience showed that explicit negative
   responses can sometimes be valuable.  One such example is when a
   querier is querying for a AAAA record, and the host name in question
   has no associated IPv6 addresses.  In this case, the responding host
   knows it currently has exclusive ownership of that name, and it knows
   that it currently does not have any IPv6 addresses, so an explicit
   negative response is preferable to the querier having to retransmit
   its query multiple times, and eventually give up with a timeout,
   before it can conclude that a given AAAA record does not exist.

Top      ToC       Page 17 
   Any time a responder receives a query for a name for which it has
   verified exclusive ownership, for a type for which that name has no
   records, the responder MUST (except as allowed in (a) below) respond
   asserting the nonexistence of that record using a DNS NSEC record
   [RFC4034].  In the case of Multicast DNS the NSEC record is not being
   used for its usual DNSSEC [RFC4033] security properties, but simply
   as a way of expressing which records do or do not exist with a given
   name.

   On receipt of a question for a particular name, rrtype, and rrclass,
   for which a responder does have one or more unique answers, the
   responder MAY also include an NSEC record in the Additional Record
   Section indicating the nonexistence of other rrtypes for that name
   and rrclass.

   Implementers working with devices with sufficient memory and CPU
   resources MAY choose to implement code to handle the full generality
   of the DNS NSEC record [RFC4034], including bitmaps up to 65,536 bits
   long.  To facilitate use by devices with limited memory and CPU
   resources, Multicast DNS queriers are only REQUIRED to be able to
   parse a restricted form of the DNS NSEC record.  All compliant
   Multicast DNS implementations MUST at least correctly generate and
   parse the restricted DNS NSEC record format described below:

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

      o The Type Bit Map block number is 0.

      o The Type Bit Map block length byte is a value in the range 1-32.

      o The Type Bit Map data is 1-32 bytes, as indicated by length
        byte.

   Because this restricted form of the DNS NSEC record is limited to
   Type Bit Map block number zero, it cannot express the existence of
   rrtypes above 255.  Consequently, if a Multicast DNS responder were
   to have records with rrtypes above 255, it MUST NOT generate these
   restricted-form NSEC records for those names, since to do so would
   imply that the name has no records with rrtypes above 255, which
   would be false.  In such cases a Multicast DNS responder MUST either
   (a) emit no NSEC record for that name, or (b) emit a full NSEC record
   containing the appropriate Type Bit Map block(s) with the correct
   bits set for all the record types that exist.  In practice this is
   not a significant limitation, since rrtypes above 255 are not
   currently in widespread use.

Top      ToC       Page 18 
   If a Multicast DNS implementation receives an NSEC record where the
   'Next Domain Name' field is not the record's own name, then the
   implementation SHOULD ignore the 'Next Domain Name' field and process
   the remainder of the NSEC record as usual.  In Multicast DNS the
   'Next Domain Name' field is not currently used, but it could be used
   in a future version of this protocol, which is why a Multicast DNS
   implementation MUST NOT reject or ignore an NSEC record it receives
   just because it finds an unexpected value in the 'Next Domain Name'
   field.

   If a Multicast DNS implementation receives an NSEC record containing
   more than one Type Bit Map, or where the Type Bit Map block number is
   not zero, or where the block length is not in the range 1-32, then
   the Multicast DNS implementation MAY silently ignore the entire NSEC
   record.  A Multicast DNS implementation MUST NOT ignore an entire
   message just because that message contains one or more NSEC record(s)
   that the Multicast DNS implementation cannot parse.  This provision
   is to allow future enhancements to the protocol to be introduced in a
   backwards-compatible way that does not break compatibility with older
   Multicast DNS implementations.

   To help differentiate these synthesized NSEC records (generated
   programmatically on-the-fly) from conventional Unicast DNS NSEC
   records (which actually exist in a signed DNS zone), the synthesized
   Multicast DNS NSEC records MUST NOT have the NSEC bit set in the Type
   Bit Map, whereas conventional Unicast DNS NSEC records do have the
   NSEC bit set.

   The TTL of the NSEC record indicates the intended lifetime of the
   negative cache entry.  In general, the TTL given for an NSEC record
   SHOULD be the same as the TTL that the record would have had, had it
   existed.  For example, the TTL for address records in Multicast DNS
   is typically 120 seconds (see Section 10), so the negative cache
   lifetime for an address record that does not exist should also be 120
   seconds.

   A responder MUST only generate negative responses to queries for
   which it has legitimate ownership of the name, rrtype, and rrclass in
   question, and can legitimately assert that no record with that name,
   rrtype, and rrclass exists.  A responder can assert that a specified
   rrtype does not exist for one of its names if it knows a priori that
   it has exclusive ownership of that name (e.g., names of reverse
   address mapping PTR records, which are derived from IP addresses,
   which should be unique on the local link) or if it previously claimed
   unique ownership of that name using probe queries for rrtype "ANY".
   (If it were to use probe queries for a specific rrtype, then it would
   only own the name for that rrtype, and could not assert that other
   rrtypes do not exist.)

Top      ToC       Page 19 
   The design rationale for this mechanism for encoding negative
   responses is discussed further in Appendix E.

6.2.  Responding to Address Queries

   When a Multicast DNS responder sends a Multicast DNS response message
   containing its own address records, it MUST include all addresses
   that are valid on the interface on which it is sending the message,
   and MUST NOT include addresses that are not valid on that interface
   (such as addresses that may be configured on the host's other
   interfaces).  For example, if an interface has both an IPv6 link-
   local and an IPv6 routable address, both should be included in the
   response message so that queriers receive both and can make their own
   choice about which to use.  This allows a querier that only has an
   IPv6 link-local address to connect to the link-local address, and a
   different querier that has an IPv6 routable address to connect to the
   IPv6 routable address instead.

   When a Multicast DNS responder places an IPv4 or IPv6 address record
   (rrtype "A" or "AAAA") into a response message, it SHOULD also place
   any records of the other address type with the same name into the
   additional section, if there is space in the message.  This is to
   provide fate sharing, so that all a device's addresses are delivered
   atomically in a single message, to reduce the risk that packet loss
   could cause a querier to receive only the IPv4 addresses and not the
   IPv6 addresses, or vice versa.

   In the event that a device has only IPv4 addresses but no IPv6
   addresses, or vice versa, then the appropriate NSEC record SHOULD be
   placed into the additional section, so that queriers can know with
   certainty that the device has no addresses of that kind.

   Some Multicast DNS responders treat a physical interface with both
   IPv4 and IPv6 address as a single interface with two addresses.
   Other Multicast DNS responders may treat this case as logically two
   interfaces (one with one or more IPv4 addresses, and the other with
   one or more IPv6 addresses), but responders that operate this way
   MUST NOT put the corresponding automatic NSEC records in replies they
   send (i.e., a negative IPv4 assertion in their IPv6 responses, and a
   negative IPv6 assertion in their IPv4 responses) because this would
   cause incorrect operation in responders on the network that work the
   former way.

6.3.  Responding to Multiquestion Queries

   Multicast DNS responders MUST correctly handle DNS query messages
   containing more than one question, by answering any or all of the
   questions to which they have answers.  Unlike single-question

Top      ToC       Page 20 
   queries, where responding without delay is allowed in appropriate
   cases, for query messages containing more than one question, all
   (non-defensive) answers SHOULD be randomly delayed in the range
   20-120 ms, or 400-500 ms if the TC (truncated) bit is set.  This is
   because when a query message contains more than one question, a
   Multicast DNS responder cannot generally be certain that other
   responders will not also be simultaneously generating answers to
   other questions in that query message.  (Answers defending a name, in
   response to a probe for that name, are not subject to this delay rule
   and are still sent immediately.)

6.4.  Response Aggregation

   When possible, a responder SHOULD, for the sake of network
   efficiency, aggregate as many responses as possible into a single
   Multicast DNS response message.  For example, when a responder has
   several responses it plans to send, each delayed by a different
   interval, then earlier responses SHOULD be delayed by up to an
   additional 500 ms if that will permit them to be aggregated with
   other responses scheduled to go out a little later.

6.5.  Wildcard Queries (qtype "ANY" and qclass "ANY")

   When responding to queries using qtype "ANY" (255) and/or qclass
   "ANY" (255), a Multicast DNS responder MUST respond with *ALL* of its
   records that match the query.  This is subtly different from how
   qtype "ANY" and qclass "ANY" work in Unicast DNS.

   A common misconception is that a Unicast DNS query for qtype "ANY"
   will elicit a response containing all matching records.  This is
   incorrect.  If there are any records that match the query, the
   response is required only to contain at least one of them, not
   necessarily all of them.

   This somewhat surprising behavior is commonly seen with caching
   (i.e., "recursive") name servers.  If a caching server receives a
   qtype "ANY" query for which it has at least one valid answer, it is
   allowed to return only those matching answers it happens to have
   already in its cache, and it is not required to reconsult the
   authoritative name server to check if there are any more records that
   also match the qtype "ANY" query.

   For example, one might imagine that a query for qtype "ANY" for name
   "host.example.com" would return both the IPv4 (A) and the IPv6 (AAAA)
   address records for that host.  In reality, what happens is that it
   depends on the history of what queries have been previously received
   by intervening caching servers.  If a caching server has no records
   for "host.example.com", then it will consult another server (usually

Top      ToC       Page 21 
   the authoritative name server for the name in question), and, in that
   case, it will typically return all IPv4 and IPv6 address records.
   However, if some other host has recently done a query for qtype "A"
   for name "host.example.com", so that the caching server already has
   IPv4 address records for "host.example.com" in its cache but no IPv6
   address records, then it will return only the IPv4 address records it
   already has cached, and no IPv6 address records.

   Multicast DNS does not share this property that qtype "ANY" and
   qclass "ANY" queries return some undefined subset of the matching
   records.  When responding to queries using qtype "ANY" (255) and/or
   qclass "ANY" (255), a Multicast DNS responder MUST respond with *ALL*
   of its records that match the query.

6.6.  Cooperating Multicast DNS Responders

   If a Multicast DNS responder ("A") observes some other Multicast DNS
   responder ("B") send a Multicast DNS response message containing a
   resource record with the same name, rrtype, and rrclass as one of A's
   resource records, but *different* rdata, then:

      o If A's resource record is intended to be a shared resource
        record, then this is no conflict, and no action is required.

      o If A's resource record is intended to be a member of a unique
        resource record set owned solely by that responder, then this is
        a conflict and MUST be handled as described in Section 9,
        "Conflict Resolution".

   If a Multicast DNS responder ("A") observes some other Multicast DNS
   responder ("B") send a Multicast DNS response message containing a
   resource record with the same name, rrtype, and rrclass as one of A's
   resource records, and *identical* rdata, then:

      o If the TTL of B's resource record given in the message is at
        least half the true TTL from A's point of view, then no action
        is required.

      o If the TTL of B's resource record given in the message is less
        than half the true TTL from A's point of view, then A MUST mark
        its record to be announced via multicast.  Queriers receiving
        the record from B would use the TTL given by B and, hence, may
        delete the record sooner than A expects.  By sending its own
        multicast response correcting the TTL, A ensures that the record
        will be retained for the desired time.

Top      ToC       Page 22 
   These rules allow multiple Multicast DNS responders to offer the same
   data on the network (perhaps for fault-tolerance reasons) without
   conflicting with each other.

6.7.  Legacy Unicast Responses

   If the source UDP port in a received Multicast DNS query is not port
   5353, this indicates that the querier originating the query is a
   simple resolver such as described in Section 5.1, "One-Shot Multicast
   DNS Queries", which does not fully implement all of Multicast DNS.
   In this case, the Multicast DNS responder MUST send a UDP response
   directly back to the querier, via unicast, to the query packet's
   source IP address and port.  This unicast response MUST be a
   conventional unicast response as would be generated by a conventional
   Unicast DNS server; for example, it MUST repeat the query ID and the
   question given in the query message.  In addition, the cache-flush
   bit described in Section 10.2, "Announcements to Flush Outdated Cache
   Entries", MUST NOT be set in legacy unicast responses.

   The resource record TTL given in a legacy unicast response SHOULD NOT
   be greater than ten seconds, even if the true TTL of the Multicast
   DNS resource record is higher.  This is because Multicast DNS
   responders that fully participate in the protocol use the cache
   coherency mechanisms described in Section 10, "Resource Record TTL
   Values and Cache Coherency", to update and invalidate stale data.
   Were unicast responses sent to legacy resolvers to use the same high
   TTLs, these legacy resolvers, which do not implement these cache
   coherency mechanisms, could retain stale cached resource record data
   long after it is no longer valid.



(page 22 continued on part 2)

Next RFC Part