|
@@ -0,0 +1,3923 @@
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 1]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 2]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+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
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 3]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+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
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 4]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 5]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 6]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 7]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 8]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 9]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 10]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 11]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 12]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 13]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 14]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 15]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 16]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 17]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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.)
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 18]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 19]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 20]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 21]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ 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.
|
|
|
+
|
|
|
+7. Traffic Reduction
|
|
|
+
|
|
|
+ A variety of techniques are used to reduce the amount of traffic on
|
|
|
+ the network.
|
|
|
+
|
|
|
+7.1. Known-Answer Suppression
|
|
|
+
|
|
|
+ When a Multicast DNS querier sends a query to which it already knows
|
|
|
+ some answers, it populates the Answer Section of the DNS query
|
|
|
+ message with those answers.
|
|
|
+
|
|
|
+ Generally, this applies only to Shared records, not Unique records,
|
|
|
+ since if a Multicast DNS querier already has at least one Unique
|
|
|
+ record in its cache then it should not be expecting further different
|
|
|
+ answers to this question, since the Unique record(s) it already has
|
|
|
+ comprise the complete answer, so it has no reason to be sending the
|
|
|
+ query at all. In contrast, having some Shared records in its cache
|
|
|
+ does not necessarily imply that a Multicast DNS querier will not
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 22]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ receive further answers to this query, and it is in this case that it
|
|
|
+ is beneficial to use the Known-Answer list to suppress repeated
|
|
|
+ sending of redundant answers that the querier already knows.
|
|
|
+
|
|
|
+ A Multicast DNS responder MUST NOT answer a Multicast DNS query if
|
|
|
+ the answer it would give is already included in the Answer Section
|
|
|
+ with an RR TTL at least half the correct value. If the RR TTL of the
|
|
|
+ answer as given in the Answer Section is less than half of the true
|
|
|
+ RR TTL as known by the Multicast DNS responder, the responder MUST
|
|
|
+ send an answer so as to update the querier's cache before the record
|
|
|
+ becomes in danger of expiration.
|
|
|
+
|
|
|
+ Because a Multicast DNS responder will respond if the remaining TTL
|
|
|
+ given in the Known-Answer list is less than half the true TTL, it is
|
|
|
+ superfluous for the querier to include such records in the Known-
|
|
|
+ Answer list. Therefore, a Multicast DNS querier SHOULD NOT include
|
|
|
+ records in the Known-Answer list whose remaining TTL is less than
|
|
|
+ half of their original TTL. Doing so would simply consume space in
|
|
|
+ the message without achieving the goal of suppressing responses and
|
|
|
+ would, therefore, be a pointless waste of network capacity.
|
|
|
+
|
|
|
+ A Multicast DNS querier MUST NOT cache resource records observed in
|
|
|
+ the Known-Answer Section of other Multicast DNS queries. The Answer
|
|
|
+ Section of Multicast DNS queries is not authoritative. By placing
|
|
|
+ information in the Answer Section of a Multicast DNS query, the
|
|
|
+ querier is stating that it *believes* the information to be true. It
|
|
|
+ is not asserting that the information *is* true. Some of those
|
|
|
+ records may have come from other hosts that are no longer on the
|
|
|
+ network. Propagating that stale information to other Multicast DNS
|
|
|
+ queriers on the network would not be helpful.
|
|
|
+
|
|
|
+7.2. Multipacket Known-Answer Suppression
|
|
|
+
|
|
|
+ Sometimes a Multicast DNS querier will already have too many answers
|
|
|
+ to fit in the Known-Answer Section of its query packets. In this
|
|
|
+ case, it should issue a Multicast DNS query containing a question and
|
|
|
+ as many Known-Answer records as will fit. It MUST then set the TC
|
|
|
+ (Truncated) bit in the header before sending the query. It MUST
|
|
|
+ immediately follow the packet with another query packet containing no
|
|
|
+ questions and as many more Known-Answer records as will fit. If
|
|
|
+ there are still too many records remaining to fit in the packet, it
|
|
|
+ again sets the TC bit and continues until all the Known-Answer
|
|
|
+ records have been sent.
|
|
|
+
|
|
|
+ A Multicast DNS responder seeing a Multicast DNS query with the TC
|
|
|
+ bit set defers its response for a time period randomly selected in
|
|
|
+ the interval 400-500 ms. This gives the Multicast DNS querier time
|
|
|
+ to send additional Known-Answer packets before the responder
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 23]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ responds. If the responder sees any of its answers listed in the
|
|
|
+ Known-Answer lists of subsequent packets from the querying host, it
|
|
|
+ MUST delete that answer from the list of answers it is planning to
|
|
|
+ give (provided that no other host on the network has also issued a
|
|
|
+ query for that record and is waiting to receive an answer).
|
|
|
+
|
|
|
+ If the responder receives additional Known-Answer packets with the TC
|
|
|
+ bit set, it SHOULD extend the delay as necessary to ensure a pause of
|
|
|
+ 400-500 ms after the last such packet before it sends its answer.
|
|
|
+ This opens the potential risk that a continuous stream of Known-
|
|
|
+ Answer packets could, theoretically, prevent a responder from
|
|
|
+ answering indefinitely. In practice, answers are never actually
|
|
|
+ delayed significantly, and should a situation arise where significant
|
|
|
+ delays did happen, that would be a scenario where the network is so
|
|
|
+ overloaded that it would be desirable to err on the side of caution.
|
|
|
+ The consequence of delaying an answer may be that it takes a user
|
|
|
+ longer than usual to discover all the services on the local network;
|
|
|
+ in contrast, the consequence of incorrectly answering before all the
|
|
|
+ Known-Answer packets have been received would be wasted capacity
|
|
|
+ sending unnecessary answers on an already overloaded network. In
|
|
|
+ this (rare) situation, sacrificing speed to preserve reliable network
|
|
|
+ operation is the right trade-off.
|
|
|
+
|
|
|
+7.3. Duplicate Question Suppression
|
|
|
+
|
|
|
+ If a host is planning to transmit (or retransmit) a query, and it
|
|
|
+ sees another host on the network send a query containing the same
|
|
|
+ "QM" question, and the Known-Answer Section of that query does not
|
|
|
+ contain any records that this host would not also put in its own
|
|
|
+ Known-Answer Section, then this host SHOULD treat its own query as
|
|
|
+ having been sent. When multiple queriers on the network are querying
|
|
|
+ for the same resource records, there is no need for them to all be
|
|
|
+ repeatedly asking the same question.
|
|
|
+
|
|
|
+7.4. Duplicate Answer Suppression
|
|
|
+
|
|
|
+ If a host is planning to send an answer, and it sees another host on
|
|
|
+ the network send a response message containing the same answer
|
|
|
+ record, and the TTL in that record is not less than the TTL this host
|
|
|
+ would have given, then this host SHOULD treat its own answer as
|
|
|
+ having been sent, and not also send an identical answer itself. When
|
|
|
+ multiple responders on the network have the same data, there is no
|
|
|
+ need for all of them to respond.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 24]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ The opportunity for duplicate answer suppression occurs when a host
|
|
|
+ has received a query, and is delaying its response for some pseudo-
|
|
|
+ random interval up to 500 ms, as described elsewhere in this
|
|
|
+ document, and then, before the host sends its response, it sees some
|
|
|
+ other host on the network send a response message containing the same
|
|
|
+ answer record.
|
|
|
+
|
|
|
+ This feature is particularly useful when Multicast DNS Proxy Servers
|
|
|
+ are in use, where there could be more than one proxy on the network
|
|
|
+ giving Multicast DNS answers on behalf of some other host (e.g.,
|
|
|
+ because that other host is currently asleep and is not itself
|
|
|
+ responding to queries).
|
|
|
+
|
|
|
+8. Probing and Announcing on Startup
|
|
|
+
|
|
|
+ Typically a Multicast DNS responder should have, at the very least,
|
|
|
+ address records for all of its active interfaces. Creating and
|
|
|
+ advertising an HINFO record on each interface as well can be useful
|
|
|
+ to network administrators.
|
|
|
+
|
|
|
+ Whenever a Multicast DNS responder starts up, wakes up from sleep,
|
|
|
+ receives an indication of a network interface "Link Change" event, or
|
|
|
+ has any other reason to believe that its network connectivity may
|
|
|
+ have changed in some relevant way, it MUST perform the two startup
|
|
|
+ steps below: Probing (Section 8.1) and Announcing (Section 8.3).
|
|
|
+
|
|
|
+8.1. Probing
|
|
|
+
|
|
|
+ The first startup step is that, for all those resource records that a
|
|
|
+ Multicast DNS responder desires to be unique on the local link, it
|
|
|
+ MUST send a Multicast DNS query asking for those resource records, to
|
|
|
+ see if any of them are already in use. The primary example of this
|
|
|
+ is a host's address records, which map its unique host name to its
|
|
|
+ unique IPv4 and/or IPv6 addresses. All probe queries SHOULD be done
|
|
|
+ using the desired resource record name and class (usually class 1,
|
|
|
+ "Internet"), and query type "ANY" (255), to elicit answers for all
|
|
|
+ types of records with that name. This allows a single question to be
|
|
|
+ used in place of several questions, which is more efficient on the
|
|
|
+ network. It also allows a host to verify exclusive ownership of a
|
|
|
+ name for all rrtypes, which is desirable in most cases. It would be
|
|
|
+ confusing, for example, if one host owned the "A" record for
|
|
|
+ "myhost.local.", but a different host owned the "AAAA" record for
|
|
|
+ that name.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 25]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ The ability to place more than one question in a Multicast DNS query
|
|
|
+ is useful here, because it can allow a host to use a single message
|
|
|
+ to probe for all of its resource records instead of needing a
|
|
|
+ separate message for each. For example, a host can simultaneously
|
|
|
+ probe for uniqueness of its "A" record and all its SRV records
|
|
|
+ [RFC6763] in the same query message.
|
|
|
+
|
|
|
+ When ready to send its Multicast DNS probe packet(s) the host should
|
|
|
+ first wait for a short random delay time, uniformly distributed in
|
|
|
+ the range 0-250 ms. This random delay is to guard against the case
|
|
|
+ where several devices are powered on simultaneously, or several
|
|
|
+ devices are connected to an Ethernet hub, which is then powered on,
|
|
|
+ or some other external event happens that might cause a group of
|
|
|
+ hosts to all send synchronized probes.
|
|
|
+
|
|
|
+ 250 ms after the first query, the host should send a second; then,
|
|
|
+ 250 ms after that, a third. If, by 250 ms after the third probe, no
|
|
|
+ conflicting Multicast DNS responses have been received, the host may
|
|
|
+ move to the next step, announcing. (Note that probing is the one
|
|
|
+ exception from the normal rule that there should be at least one
|
|
|
+ second between repetitions of the same question, and the interval
|
|
|
+ between subsequent repetitions should at least double.)
|
|
|
+
|
|
|
+ When sending probe queries, a host MUST NOT consult its cache for
|
|
|
+ potential answers. Only conflicting Multicast DNS responses received
|
|
|
+ "live" from the network are considered valid for the purposes of
|
|
|
+ determining whether probing has succeeded or failed.
|
|
|
+
|
|
|
+ In order to allow services to announce their presence without
|
|
|
+ unreasonable delay, the time window for probing is intentionally set
|
|
|
+ quite short. As a result of this, from the time the first probe
|
|
|
+ packet is sent, another device on the network using that name has
|
|
|
+ just 750 ms to respond to defend its name. On networks that are
|
|
|
+ slow, or busy, or both, it is possible for round-trip latency to
|
|
|
+ account for a few hundred milliseconds, and software delays in slow
|
|
|
+ devices can add additional delay. Hence, it is important that when a
|
|
|
+ device receives a probe query for a name that it is currently using,
|
|
|
+ it SHOULD generate its response to defend that name immediately and
|
|
|
+ send it as quickly as possible. The usual rules about random delays
|
|
|
+ before responding, to avoid sudden bursts of simultaneous answers
|
|
|
+ from different hosts, do not apply here since normally at most one
|
|
|
+ host should ever respond to a given probe question. Even when a
|
|
|
+ single DNS query message contains multiple probe questions, it would
|
|
|
+ be unusual for that message to elicit a defensive response from more
|
|
|
+ than one other host. Because of the mDNS multicast rate-limiting
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 26]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ rules, the probes SHOULD be sent as "QU" questions with the unicast-
|
|
|
+ response bit set, to allow a defending host to respond immediately
|
|
|
+ via unicast, instead of potentially having to wait before replying
|
|
|
+ via multicast.
|
|
|
+
|
|
|
+ During probing, from the time the first probe packet is sent until
|
|
|
+ 250 ms after the third probe, if any conflicting Multicast DNS
|
|
|
+ response is received, then the probing host MUST defer to the
|
|
|
+ existing host, and SHOULD choose new names for some or all of its
|
|
|
+ resource records as appropriate. Apparently conflicting Multicast
|
|
|
+ DNS responses received *before* the first probe packet is sent MUST
|
|
|
+ be silently ignored (see discussion of stale probe packets in Section
|
|
|
+ 8.2, "Simultaneous Probe Tiebreaking", below). In the case of a host
|
|
|
+ probing using query type "ANY" as recommended above, any answer
|
|
|
+ containing a record with that name, of any type, MUST be considered a
|
|
|
+ conflicting response and handled accordingly.
|
|
|
+
|
|
|
+ If fifteen conflicts occur within any ten-second period, then the
|
|
|
+ host MUST wait at least five seconds before each successive
|
|
|
+ additional probe attempt. This is to help ensure that, in the event
|
|
|
+ of software bugs or other unanticipated problems, errant hosts do not
|
|
|
+ flood the network with a continuous stream of multicast traffic. For
|
|
|
+ very simple devices, a valid way to comply with this requirement is
|
|
|
+ to always wait five seconds after any failed probe attempt before
|
|
|
+ trying again.
|
|
|
+
|
|
|
+ If a responder knows by other means that its unique resource record
|
|
|
+ set name, rrtype, and rrclass cannot already be in use by any other
|
|
|
+ responder on the network, then it SHOULD skip the probing step for
|
|
|
+ that resource record set. For example, when creating the reverse
|
|
|
+ address mapping PTR records, the host can reasonably assume that no
|
|
|
+ other host will be trying to create those same PTR records, since
|
|
|
+ that would imply that the two hosts were trying to use the same IP
|
|
|
+ address, and if that were the case, the two hosts would be suffering
|
|
|
+ communication problems beyond the scope of what Multicast DNS is
|
|
|
+ designed to solve. Similarly, if a responder is acting as a proxy,
|
|
|
+ taking over from another Multicast DNS responder that has already
|
|
|
+ verified the uniqueness of the record, then the proxy SHOULD NOT
|
|
|
+ repeat the probing step for those records.
|
|
|
+
|
|
|
+8.2. Simultaneous Probe Tiebreaking
|
|
|
+
|
|
|
+ The astute reader will observe that there is a race condition
|
|
|
+ inherent in the previous description. If two hosts are probing for
|
|
|
+ the same name simultaneously, neither will receive any response to
|
|
|
+ the probe, and the hosts could incorrectly conclude that they may
|
|
|
+ both proceed to use the name. To break this symmetry, each host
|
|
|
+ populates the query message's Authority Section with the record or
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 27]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ records with the rdata that it would be proposing to use, should its
|
|
|
+ probing be successful. The Authority Section is being used here in a
|
|
|
+ way analogous to the way it is used as the "Update Section" in a DNS
|
|
|
+ Update message [RFC2136] [RFC3007].
|
|
|
+
|
|
|
+ When a host is probing for a group of related records with the same
|
|
|
+ name (e.g., the SRV and TXT record describing a DNS-SD service), only
|
|
|
+ a single question need be placed in the Question Section, since query
|
|
|
+ type "ANY" (255) is used, which will elicit answers for all records
|
|
|
+ with that name. However, for tiebreaking to work correctly in all
|
|
|
+ cases, the Authority Section must contain *all* the records and
|
|
|
+ proposed rdata being probed for uniqueness.
|
|
|
+
|
|
|
+ When a host that is probing for a record sees another host issue a
|
|
|
+ query for the same record, it consults the Authority Section of that
|
|
|
+ query. If it finds any resource record(s) there which answers the
|
|
|
+ query, then it compares the data of that (those) resource record(s)
|
|
|
+ with its own tentative data. We consider first the simple case of a
|
|
|
+ host probing for a single record, receiving a simultaneous probe from
|
|
|
+ another host also probing for a single record. The two records are
|
|
|
+ compared and the lexicographically later data wins. This means that
|
|
|
+ if the host finds that its own data is lexicographically later, it
|
|
|
+ simply ignores the other host's probe. If the host finds that its
|
|
|
+ own data is lexicographically earlier, then it defers to the winning
|
|
|
+ host by waiting one second, and then begins probing for this record
|
|
|
+ again. The logic for waiting one second and then trying again is to
|
|
|
+ guard against stale probe packets on the network (possibly even stale
|
|
|
+ probe packets sent moments ago by this host itself, before some
|
|
|
+ configuration change, which may be echoed back after a short delay by
|
|
|
+ some Ethernet switches and some 802.11 base stations). If the
|
|
|
+ winning simultaneous probe was from a real other host on the network,
|
|
|
+ then after one second it will have completed its probing, and will
|
|
|
+ answer subsequent probes. If the apparently winning simultaneous
|
|
|
+ probe was in fact just an old stale packet on the network (maybe from
|
|
|
+ the host itself), then when it retries its probing in one second, its
|
|
|
+ probes will go unanswered, and it will successfully claim the name.
|
|
|
+
|
|
|
+ The determination of "lexicographically later" is performed by first
|
|
|
+ comparing the record class (excluding the cache-flush bit described
|
|
|
+ in Section 10.2), then the record type, then raw comparison of the
|
|
|
+ binary content of the rdata without regard for meaning or structure.
|
|
|
+ If the record classes differ, then the numerically greater class is
|
|
|
+ considered "lexicographically later". Otherwise, if the record types
|
|
|
+ differ, then the numerically greater type is considered
|
|
|
+ "lexicographically later". If the rrtype and rrclass both match,
|
|
|
+ then the rdata is compared.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 28]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ In the case of resource records containing rdata that is subject to
|
|
|
+ name compression [RFC1035], the names MUST be uncompressed before
|
|
|
+ comparison. (The details of how a particular name is compressed is
|
|
|
+ an artifact of how and where the record is written into the DNS
|
|
|
+ message; it is not an intrinsic property of the resource record
|
|
|
+ itself.)
|
|
|
+
|
|
|
+ The bytes of the raw uncompressed rdata are compared in turn,
|
|
|
+ interpreting the bytes as eight-bit UNSIGNED values, until a byte is
|
|
|
+ found whose value is greater than that of its counterpart (in which
|
|
|
+ case, the rdata whose byte has the greater value is deemed
|
|
|
+ lexicographically later) or one of the resource records runs out of
|
|
|
+ rdata (in which case, the resource record which still has remaining
|
|
|
+ data first is deemed lexicographically later). The following is an
|
|
|
+ example of a conflict:
|
|
|
+
|
|
|
+ MyPrinter.local. A 169.254.99.200
|
|
|
+ MyPrinter.local. A 169.254.200.50
|
|
|
+
|
|
|
+ In this case, 169.254.200.50 is lexicographically later (the third
|
|
|
+ byte, with value 200, is greater than its counterpart with value 99),
|
|
|
+ so it is deemed the winner.
|
|
|
+
|
|
|
+ Note that it is vital that the bytes are interpreted as UNSIGNED
|
|
|
+ values in the range 0-255, or the wrong outcome may result. In the
|
|
|
+ example above, if the byte with value 200 had been incorrectly
|
|
|
+ interpreted as a signed eight-bit value, then it would be interpreted
|
|
|
+ as value -56, and the wrong address record would be deemed the
|
|
|
+ winner.
|
|
|
+
|
|
|
+8.2.1. Simultaneous Probe Tiebreaking for Multiple Records
|
|
|
+
|
|
|
+ When a host is probing for a set of records with the same name, or a
|
|
|
+ message is received containing multiple tiebreaker records answering
|
|
|
+ a given probe question in the Question Section, the host's records
|
|
|
+ and the tiebreaker records from the message are each sorted into
|
|
|
+ order, and then compared pairwise, using the same comparison
|
|
|
+ technique described above, until a difference is found.
|
|
|
+
|
|
|
+ The records are sorted using the same lexicographical order as
|
|
|
+ described above, that is, if the record classes differ, the record
|
|
|
+ with the lower class number comes first. If the classes are the same
|
|
|
+ but the rrtypes differ, the record with the lower rrtype number comes
|
|
|
+ first. If the class and rrtype match, then the rdata is compared
|
|
|
+ bytewise until a difference is found. For example, in the common
|
|
|
+ case of advertising DNS-SD services with a TXT record and an SRV
|
|
|
+ record, the TXT record comes first (the rrtype value for TXT is 16)
|
|
|
+ and the SRV record comes second (the rrtype value for SRV is 33).
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 29]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ When comparing the records, if the first records match perfectly,
|
|
|
+ then the second records are compared, and so on. If either list of
|
|
|
+ records runs out of records before any difference is found, then the
|
|
|
+ list with records remaining is deemed to have won the tiebreak. If
|
|
|
+ both lists run out of records at the same time without any difference
|
|
|
+ being found, then this indicates that two devices are advertising
|
|
|
+ identical sets of records, as is sometimes done for fault tolerance,
|
|
|
+ and there is, in fact, no conflict.
|
|
|
+
|
|
|
+8.3. Announcing
|
|
|
+
|
|
|
+ The second startup step is that the Multicast DNS responder MUST send
|
|
|
+ an unsolicited Multicast DNS response containing, in the Answer
|
|
|
+ Section, all of its newly registered resource records (both shared
|
|
|
+ records, and unique records that have completed the probing step).
|
|
|
+ If there are too many resource records to fit in a single packet,
|
|
|
+ multiple packets should be used.
|
|
|
+
|
|
|
+ In the case of shared records (e.g., the PTR records used by DNS-
|
|
|
+ Based Service Discovery [RFC6763]), the records are simply placed as
|
|
|
+ is into the Answer Section of the DNS response.
|
|
|
+
|
|
|
+ In the case of records that have been verified to be unique in the
|
|
|
+ previous step, they are placed into the Answer Section of the DNS
|
|
|
+ response with the most significant bit of the rrclass set to one.
|
|
|
+ The most significant bit of the rrclass for a record in the Answer
|
|
|
+ Section of a response message is the Multicast DNS cache-flush bit
|
|
|
+ and is discussed in more detail below in Section 10.2, "Announcements
|
|
|
+ to Flush Outdated Cache Entries".
|
|
|
+
|
|
|
+ The Multicast DNS responder MUST send at least two unsolicited
|
|
|
+ responses, one second apart. To provide increased robustness against
|
|
|
+ packet loss, a responder MAY send up to eight unsolicited responses,
|
|
|
+ provided that the interval between unsolicited responses increases by
|
|
|
+ at least a factor of two with every response sent.
|
|
|
+
|
|
|
+ A Multicast DNS responder MUST NOT send announcements in the absence
|
|
|
+ of information that its network connectivity may have changed in some
|
|
|
+ relevant way. In particular, a Multicast DNS responder MUST NOT send
|
|
|
+ regular periodic announcements as a matter of course.
|
|
|
+
|
|
|
+ Whenever a Multicast DNS responder receives any Multicast DNS
|
|
|
+ response (solicited or otherwise) containing a conflicting resource
|
|
|
+ record, the conflict MUST be resolved as described in Section 9,
|
|
|
+ "Conflict Resolution".
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 30]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+8.4. Updating
|
|
|
+
|
|
|
+ At any time, if the rdata of any of a host's Multicast DNS records
|
|
|
+ changes, the host MUST repeat the Announcing step described above to
|
|
|
+ update neighboring caches. For example, if any of a host's IP
|
|
|
+ addresses change, it MUST re-announce those address records. The
|
|
|
+ host does not need to repeat the Probing step because it has already
|
|
|
+ established unique ownership of that name.
|
|
|
+
|
|
|
+ In the case of shared records, a host MUST send a "goodbye"
|
|
|
+ announcement with RR TTL zero (see Section 10.1, "Goodbye Packets")
|
|
|
+ for the old rdata, to cause it to be deleted from peer caches, before
|
|
|
+ announcing the new rdata. In the case of unique records, a host
|
|
|
+ SHOULD omit the "goodbye" announcement, since the cache-flush bit on
|
|
|
+ the newly announced records will cause old rdata to be flushed from
|
|
|
+ peer caches anyway.
|
|
|
+
|
|
|
+ A host may update the contents of any of its records at any time,
|
|
|
+ though a host SHOULD NOT update records more frequently than ten
|
|
|
+ times per minute. Frequent rapid updates impose a burden on the
|
|
|
+ network. If a host has information to disseminate which changes more
|
|
|
+ frequently than ten times per minute, then it may be more appropriate
|
|
|
+ to design a protocol for that specific purpose.
|
|
|
+
|
|
|
+9. Conflict Resolution
|
|
|
+
|
|
|
+ A conflict occurs when a Multicast DNS responder has a unique record
|
|
|
+ for which it is currently authoritative, and it receives a Multicast
|
|
|
+ DNS response message containing a record with the same name, rrtype
|
|
|
+ and rrclass, but inconsistent rdata. What may be considered
|
|
|
+ inconsistent is context sensitive, except that resource records with
|
|
|
+ identical rdata are never considered inconsistent, even if they
|
|
|
+ originate from different hosts. This is to permit use of proxies and
|
|
|
+ other fault-tolerance mechanisms that may cause more than one
|
|
|
+ responder to be capable of issuing identical answers on the network.
|
|
|
+
|
|
|
+ A common example of a resource record type that is intended to be
|
|
|
+ unique, not shared between hosts, is the address record that maps a
|
|
|
+ host's name to its IP address. Should a host witness another host
|
|
|
+ announce an address record with the same name but a different IP
|
|
|
+ address, then that is considered inconsistent, and that address
|
|
|
+ record is considered to be in conflict.
|
|
|
+
|
|
|
+ Whenever a Multicast DNS responder receives any Multicast DNS
|
|
|
+ response (solicited or otherwise) containing a conflicting resource
|
|
|
+ record in any of the Resource Record Sections, the Multicast DNS
|
|
|
+ responder MUST immediately reset its conflicted unique record to
|
|
|
+ probing state, and go through the startup steps described above in
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 31]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ Section 8, "Probing and Announcing on Startup". The protocol used in
|
|
|
+ the Probing phase will determine a winner and a loser, and the loser
|
|
|
+ MUST cease using the name, and reconfigure.
|
|
|
+
|
|
|
+ It is very important that any host receiving a resource record that
|
|
|
+ conflicts with one of its own MUST take action as described above.
|
|
|
+ In the case of two hosts using the same host name, where one has been
|
|
|
+ configured to require a unique host name and the other has not, the
|
|
|
+ one that has not been configured to require a unique host name will
|
|
|
+ not perceive any conflict, and will not take any action. By
|
|
|
+ reverting to Probing state, the host that desires a unique host name
|
|
|
+ will go through the necessary steps to ensure that a unique host name
|
|
|
+ is obtained.
|
|
|
+
|
|
|
+ The recommended course of action after probing and failing is as
|
|
|
+ follows:
|
|
|
+
|
|
|
+ 1. Programmatically change the resource record name in an attempt
|
|
|
+ to find a new name that is unique. This could be done by
|
|
|
+ adding some further identifying information (e.g., the model
|
|
|
+ name of the hardware) if it is not already present in the name,
|
|
|
+ or appending the digit "2" to the name, or incrementing a
|
|
|
+ number at the end of the name if one is already present.
|
|
|
+
|
|
|
+ 2. Probe again, and repeat as necessary until a unique name is
|
|
|
+ found.
|
|
|
+
|
|
|
+ 3. Once an available unique name has been determined, by probing
|
|
|
+ without receiving any conflicting response, record this newly
|
|
|
+ chosen name in persistent storage so that the device will use
|
|
|
+ the same name the next time it is power-cycled.
|
|
|
+
|
|
|
+ 4. Display a message to the user or operator informing them of the
|
|
|
+ name change. For example:
|
|
|
+
|
|
|
+ The name "Bob's Music" is in use by another music server on
|
|
|
+ the network. Your music collection has been renamed to
|
|
|
+ "Bob's Music (2)". If you want to change this name, use
|
|
|
+ [describe appropriate menu item or preference dialog here].
|
|
|
+
|
|
|
+ The details of how the user or operator is informed of the new
|
|
|
+ name depends on context. A desktop computer with a screen
|
|
|
+ might put up a dialog box. A headless server in the closet may
|
|
|
+ write a message to a log file, or use whatever mechanism
|
|
|
+ (email, SNMP trap, etc.) it uses to inform the administrator of
|
|
|
+ error conditions. On the other hand, a headless server in the
|
|
|
+ closet may not inform the user at all -- if the user cares,
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 32]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ they will notice the name has changed, and connect to the
|
|
|
+ server in the usual way (e.g., via web browser) to configure a
|
|
|
+ new name.
|
|
|
+
|
|
|
+ 5. After one minute of probing, if the Multicast DNS responder has
|
|
|
+ been unable to find any unused name, it should log an error
|
|
|
+ message to inform the user or operator of this fact. This
|
|
|
+ situation should never occur in normal operation. The only
|
|
|
+ situations that would cause this to happen would be either a
|
|
|
+ deliberate denial-of-service attack, or some kind of very
|
|
|
+ obscure hardware or software bug that acts like a deliberate
|
|
|
+ denial-of-service attack.
|
|
|
+
|
|
|
+ These considerations apply to address records (i.e., host names) and
|
|
|
+ to all resource records where uniqueness (or maintenance of some
|
|
|
+ other defined constraint) is desired.
|
|
|
+
|
|
|
+10. Resource Record TTL Values and Cache Coherency
|
|
|
+
|
|
|
+ As a general rule, the recommended TTL value for Multicast DNS
|
|
|
+ resource records with a host name as the resource record's name
|
|
|
+ (e.g., A, AAAA, HINFO) or a host name contained within the resource
|
|
|
+ record's rdata (e.g., SRV, reverse mapping PTR record) SHOULD be 120
|
|
|
+ seconds.
|
|
|
+
|
|
|
+ The recommended TTL value for other Multicast DNS resource records is
|
|
|
+ 75 minutes.
|
|
|
+
|
|
|
+ A querier with an active outstanding query will issue a query message
|
|
|
+ when one or more of the resource records in its cache are 80% of the
|
|
|
+ way to expiry. If the TTL on those records is 75 minutes, this
|
|
|
+ ongoing cache maintenance process yields a steady-state query rate of
|
|
|
+ one query every 60 minutes.
|
|
|
+
|
|
|
+ Any distributed cache needs a cache coherency protocol. If Multicast
|
|
|
+ DNS resource records follow the recommendation and have a TTL of 75
|
|
|
+ minutes, that means that stale data could persist in the system for a
|
|
|
+ little over an hour. Making the default RR TTL significantly lower
|
|
|
+ would reduce the lifetime of stale data, but would produce too much
|
|
|
+ extra traffic on the network. Various techniques are available to
|
|
|
+ minimize the impact of such stale data, outlined in the five
|
|
|
+ subsections below.
|
|
|
+
|
|
|
+10.1. Goodbye Packets
|
|
|
+
|
|
|
+ In the case where a host knows that certain resource record data is
|
|
|
+ about to become invalid (for example, when the host is undergoing a
|
|
|
+ clean shutdown), the host SHOULD send an unsolicited Multicast DNS
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 33]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ response packet, giving the same resource record name, rrtype,
|
|
|
+ rrclass, and rdata, but an RR TTL of zero. This has the effect of
|
|
|
+ updating the TTL stored in neighboring hosts' cache entries to zero,
|
|
|
+ causing that cache entry to be promptly deleted.
|
|
|
+
|
|
|
+ Queriers receiving a Multicast DNS response with a TTL of zero SHOULD
|
|
|
+ NOT immediately delete the record from the cache, but instead record
|
|
|
+ a TTL of 1 and then delete the record one second later. In the case
|
|
|
+ of multiple Multicast DNS responders on the network described in
|
|
|
+ Section 6.6 above, if one of the responders shuts down and
|
|
|
+ incorrectly sends goodbye packets for its records, it gives the other
|
|
|
+ cooperating responders one second to send out their own response to
|
|
|
+ "rescue" the records before they expire and are deleted.
|
|
|
+
|
|
|
+10.2. Announcements to Flush Outdated Cache Entries
|
|
|
+
|
|
|
+ Whenever a host has a resource record with new data, or with what
|
|
|
+ might potentially be new data (e.g., after rebooting, waking from
|
|
|
+ sleep, connecting to a new network link, or changing IP address), the
|
|
|
+ host needs to inform peers of that new data. In cases where the host
|
|
|
+ has not been continuously connected and participating on the network
|
|
|
+ link, it MUST first probe to re-verify uniqueness of its unique
|
|
|
+ records, as described above in Section 8.1, "Probing".
|
|
|
+
|
|
|
+ Having completed the Probing step, if necessary, the host MUST then
|
|
|
+ send a series of unsolicited announcements to update cache entries in
|
|
|
+ its neighbor hosts. In these unsolicited announcements, if the
|
|
|
+ record is one that has been verified unique, the host sets the most
|
|
|
+ significant bit of the rrclass field of the resource record. This
|
|
|
+ bit, the cache-flush bit, tells neighboring hosts that this is not a
|
|
|
+ shared record type. Instead of merging this new record additively
|
|
|
+ into the cache in addition to any previous records with the same
|
|
|
+ name, rrtype, and rrclass, all old records with that name, rrtype,
|
|
|
+ and rrclass that were received more than one second ago are declared
|
|
|
+ invalid, and marked to expire from the cache in one second.
|
|
|
+
|
|
|
+ The semantics of the cache-flush bit are as follows: normally when a
|
|
|
+ resource record appears in a Resource Record Section of the DNS
|
|
|
+ response it means, "This is an assertion that this information is
|
|
|
+ true". When a resource record appears in a Resource Record Section
|
|
|
+ of the DNS response with the cache-flush bit set, it means, "This is
|
|
|
+ an assertion that this information is the truth and the whole truth,
|
|
|
+ and anything you may have heard more than a second ago regarding
|
|
|
+ records of this name/rrtype/rrclass is no longer true".
|
|
|
+
|
|
|
+ To accommodate the case where the set of records from one host
|
|
|
+ constituting a single unique RRSet is too large to fit in a single
|
|
|
+ packet, only cache records that are more than one second old are
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 34]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ flushed. This allows the announcing host to generate a quick burst
|
|
|
+ of packets back-to-back on the wire containing all the members of the
|
|
|
+ RRSet. When receiving records with the cache-flush bit set, all
|
|
|
+ records older than one second are marked to be deleted one second in
|
|
|
+ the future. One second after the end of the little packet burst, any
|
|
|
+ records not represented within that packet burst will then be expired
|
|
|
+ from all peer caches.
|
|
|
+
|
|
|
+ Any time a host sends a response packet containing some members of a
|
|
|
+ unique RRSet, it MUST send the entire RRSet, preferably in a single
|
|
|
+ packet, or if the entire RRSet will not fit in a single packet, in a
|
|
|
+ quick burst of packets sent as close together as possible. The host
|
|
|
+ MUST set the cache-flush bit on all members of the unique RRSet.
|
|
|
+
|
|
|
+ Another reason for waiting one second before deleting stale records
|
|
|
+ from the cache is to accommodate bridged networks. For example, a
|
|
|
+ host's address record announcement on a wireless interface may be
|
|
|
+ bridged onto a wired Ethernet and may cause that same host's Ethernet
|
|
|
+ address records to be flushed from peer caches. The one-second delay
|
|
|
+ gives the host the chance to see its own announcement arrive on the
|
|
|
+ wired Ethernet, and immediately re-announce its Ethernet interface's
|
|
|
+ address records so that both sets remain valid and live in peer
|
|
|
+ caches.
|
|
|
+
|
|
|
+ These rules, about when to set the cache-flush bit and about sending
|
|
|
+ the entire rrset, apply regardless of *why* the response message is
|
|
|
+ being generated. They apply to startup announcements as described in
|
|
|
+ Section 8.3, "Announcing", and to responses generated as a result of
|
|
|
+ receiving query messages.
|
|
|
+
|
|
|
+ The cache-flush bit is only set in records in the Resource Record
|
|
|
+ Sections of Multicast DNS responses sent to UDP port 5353.
|
|
|
+
|
|
|
+ The cache-flush bit MUST NOT be set in any resource records in a
|
|
|
+ response message sent in legacy unicast responses to UDP ports other
|
|
|
+ than 5353.
|
|
|
+
|
|
|
+ The cache-flush bit MUST NOT be set in any resource records in the
|
|
|
+ Known-Answer list of any query message.
|
|
|
+
|
|
|
+ The cache-flush bit MUST NOT ever be set in any shared resource
|
|
|
+ record. To do so would cause all the other shared versions of this
|
|
|
+ resource record with different rdata from different responders to be
|
|
|
+ immediately deleted from all the caches on the network.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 35]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ The cache-flush bit does *not* apply to questions listed in the
|
|
|
+ Question Section of a Multicast DNS message. The top bit of the
|
|
|
+ rrclass field in questions is used for an entirely different purpose
|
|
|
+ (see Section 5.4, "Questions Requesting Unicast Responses").
|
|
|
+
|
|
|
+ Note that the cache-flush bit is NOT part of the resource record
|
|
|
+ class. The cache-flush bit is the most significant bit of the second
|
|
|
+ 16-bit word of a resource record in a Resource Record Section of a
|
|
|
+ Multicast DNS message (the field conventionally referred to as the
|
|
|
+ rrclass field), and the actual resource record class is the least
|
|
|
+ significant fifteen bits of this field. There is no Multicast DNS
|
|
|
+ resource record class 0x8001. The value 0x8001 in the rrclass field
|
|
|
+ of a resource record in a Multicast DNS response message indicates a
|
|
|
+ resource record with class 1, with the cache-flush bit set. When
|
|
|
+ receiving a resource record with the cache-flush bit set,
|
|
|
+ implementations should take care to mask off that bit before storing
|
|
|
+ the resource record in memory, or otherwise ensure that it is given
|
|
|
+ the correct semantic interpretation.
|
|
|
+
|
|
|
+ The reuse of the top bit of the rrclass field only applies to
|
|
|
+ conventional resource record types that are subject to caching, not
|
|
|
+ to pseudo-RRs like OPT [RFC2671], TSIG [RFC2845], TKEY [RFC2930],
|
|
|
+ SIG0 [RFC2931], etc., that pertain only to a particular transport
|
|
|
+ level message and not to any actual DNS data. Since pseudo-RRs
|
|
|
+ should never go into the Multicast DNS cache, the concept of a cache-
|
|
|
+ flush bit for these types is not applicable. In particular, the
|
|
|
+ rrclass field of an OPT record encodes the sender's UDP payload size,
|
|
|
+ and should be interpreted as a sixteen-bit length value in the range
|
|
|
+ 0-65535, not a one-bit flag and a fifteen-bit length.
|
|
|
+
|
|
|
+10.3. Cache Flush on Topology change
|
|
|
+
|
|
|
+ If the hardware on a given host is able to indicate physical changes
|
|
|
+ of connectivity, then when the hardware indicates such a change, the
|
|
|
+ host should take this information into account in its Multicast DNS
|
|
|
+ cache management strategy. For example, a host may choose to
|
|
|
+ immediately flush all cache records received on a particular
|
|
|
+ interface when that cable is disconnected. Alternatively, a host may
|
|
|
+ choose to adjust the remaining TTL on all those records to a few
|
|
|
+ seconds so that if the cable is not reconnected quickly, those
|
|
|
+ records will expire from the cache.
|
|
|
+
|
|
|
+ Likewise, when a host reboots, wakes from sleep, or undergoes some
|
|
|
+ other similar discontinuous state change, the cache management
|
|
|
+ strategy should take that information into account.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 36]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+10.4. Cache Flush on Failure Indication
|
|
|
+
|
|
|
+ Sometimes a cache record can be determined to be stale when a client
|
|
|
+ attempts to use the rdata it contains, and the client finds that
|
|
|
+ rdata to be incorrect.
|
|
|
+
|
|
|
+ For example, the rdata in an address record can be determined to be
|
|
|
+ incorrect if attempts to contact that host fail, either because (for
|
|
|
+ an IPv4 address on a local subnet) ARP requests for that address go
|
|
|
+ unanswered, because (for an IPv6 address with an on-link prefix) ND
|
|
|
+ requests for that address go unanswered, or because (for an address
|
|
|
+ on a remote network) a router returns an ICMP "Host Unreachable"
|
|
|
+ error.
|
|
|
+
|
|
|
+ The rdata in an SRV record can be determined to be incorrect if
|
|
|
+ attempts to communicate with the indicated service at the host and
|
|
|
+ port number indicated are not successful.
|
|
|
+
|
|
|
+ The rdata in a DNS-SD PTR record can be determined to be incorrect if
|
|
|
+ attempts to look up the SRV record it references are not successful.
|
|
|
+
|
|
|
+ The software implementing the Multicast DNS resource record cache
|
|
|
+ should provide a mechanism so that clients detecting stale rdata can
|
|
|
+ inform the cache.
|
|
|
+
|
|
|
+ When the cache receives this hint that it should reconfirm some
|
|
|
+ record, it MUST issue two or more queries for the resource record in
|
|
|
+ dispute. If no response is received within ten seconds, then, even
|
|
|
+ though its TTL may indicate that it is not yet due to expire, that
|
|
|
+ record SHOULD be promptly flushed from the cache.
|
|
|
+
|
|
|
+ The end result of this is that if a printer suffers a sudden power
|
|
|
+ failure or other abrupt disconnection from the network, its name may
|
|
|
+ continue to appear in DNS-SD browser lists displayed on users'
|
|
|
+ screens. Eventually, that entry will expire from the cache
|
|
|
+ naturally, but if a user tries to access the printer before that
|
|
|
+ happens, the failure to successfully contact the printer will trigger
|
|
|
+ the more hasty demise of its cache entries. This is a sensible
|
|
|
+ trade-off between good user experience and good network efficiency.
|
|
|
+ If we were to insist that printers should disappear from the printer
|
|
|
+ list within 30 seconds of becoming unavailable, for all failure
|
|
|
+ modes, the only way to achieve this would be for the client to poll
|
|
|
+ the printer at least every 30 seconds, or for the printer to announce
|
|
|
+ its presence at least every 30 seconds, both of which would be an
|
|
|
+ unreasonable burden on most networks.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 37]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+10.5. Passive Observation Of Failures (POOF)
|
|
|
+
|
|
|
+ A host observes the multicast queries issued by the other hosts on
|
|
|
+ the network. One of the major benefits of also sending responses
|
|
|
+ using multicast is that it allows all hosts to see the responses (or
|
|
|
+ lack thereof) to those queries.
|
|
|
+
|
|
|
+ If a host sees queries, for which a record in its cache would be
|
|
|
+ expected to be given as an answer in a multicast response, but no
|
|
|
+ such answer is seen, then the host may take this as an indication
|
|
|
+ that the record may no longer be valid.
|
|
|
+
|
|
|
+ After seeing two or more of these queries, and seeing no multicast
|
|
|
+ response containing the expected answer within ten seconds, then even
|
|
|
+ though its TTL may indicate that it is not yet due to expire, that
|
|
|
+ record SHOULD be flushed from the cache. The host SHOULD NOT perform
|
|
|
+ its own queries to reconfirm that the record is truly gone. If every
|
|
|
+ host on a large network were to do this, it would cause a lot of
|
|
|
+ unnecessary multicast traffic. If host A sends multicast queries
|
|
|
+ that remain unanswered, then there is no reason to suppose that host
|
|
|
+ B or any other host is likely to be any more successful.
|
|
|
+
|
|
|
+ The previous section, "Cache Flush on Failure Indication", describes
|
|
|
+ a situation where a user trying to print discovers that the printer
|
|
|
+ is no longer available. By implementing the passive observation
|
|
|
+ described here, when one user fails to contact the printer, all hosts
|
|
|
+ on the network observe that failure and update their caches
|
|
|
+ accordingly.
|
|
|
+
|
|
|
+11. Source Address Check
|
|
|
+
|
|
|
+ All Multicast DNS responses (including responses sent via unicast)
|
|
|
+ SHOULD be sent with IP TTL set to 255. This is recommended to
|
|
|
+ provide backwards-compatibility with older Multicast DNS queriers
|
|
|
+ (implementing a draft version of this document, posted in February
|
|
|
+ 2004) that check the IP TTL on reception to determine whether the
|
|
|
+ packet originated on the local link. These older queriers discard
|
|
|
+ all packets with TTLs other than 255.
|
|
|
+
|
|
|
+ A host sending Multicast DNS queries to a link-local destination
|
|
|
+ address (including the 224.0.0.251 and FF02::FB link-local multicast
|
|
|
+ addresses) MUST only accept responses to that query that originate
|
|
|
+ from the local link, and silently discard any other response packets.
|
|
|
+ Without this check, it could be possible for remote rogue hosts to
|
|
|
+ send spoof answer packets (perhaps unicast to the victim host), which
|
|
|
+ the receiving machine could misinterpret as having originated on the
|
|
|
+ local link.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 38]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ The test for whether a response originated on the local link is done
|
|
|
+ in two ways:
|
|
|
+
|
|
|
+ * All responses received with a destination address in the IP
|
|
|
+ header that is the mDNS IPv4 link-local multicast address
|
|
|
+ 224.0.0.251 or the mDNS IPv6 link-local multicast address
|
|
|
+ FF02::FB are necessarily deemed to have originated on the local
|
|
|
+ link, regardless of source IP address. This is essential to
|
|
|
+ allow devices to work correctly and reliably in unusual
|
|
|
+ configurations, such as multiple logical IP subnets overlayed on
|
|
|
+ a single link, or in cases of severe misconfiguration, where
|
|
|
+ devices are physically connected to the same link, but are
|
|
|
+ currently misconfigured with completely unrelated IP addresses
|
|
|
+ and subnet masks.
|
|
|
+
|
|
|
+ * For responses received with a unicast destination address in the
|
|
|
+ IP header, the source IP address in the packet is checked to see
|
|
|
+ if it is an address on a local subnet. An IPv4 source address
|
|
|
+ is determined to be on a local subnet if, for (one of) the
|
|
|
+ address(es) configured on the interface receiving the packet, (I
|
|
|
+ & M) == (P & M), where I and M are the interface address and
|
|
|
+ subnet mask respectively, P is the source IP address from the
|
|
|
+ packet, '&' represents the bitwise logical 'and' operation, and
|
|
|
+ '==' represents a bitwise equality test. An IPv6 source address
|
|
|
+ is determined to be on the local link if, for any of the on-link
|
|
|
+ IPv6 prefixes on the interface receiving the packet (learned via
|
|
|
+ IPv6 router advertisements or otherwise configured on the host),
|
|
|
+ the first 'n' bits of the IPv6 source address match the first
|
|
|
+ 'n' bits of the prefix address, where 'n' is the length of the
|
|
|
+ prefix being considered.
|
|
|
+
|
|
|
+ Since queriers will ignore responses apparently originating outside
|
|
|
+ the local subnet, a responder SHOULD avoid generating responses that
|
|
|
+ it can reasonably predict will be ignored. This applies particularly
|
|
|
+ in the case of overlayed subnets. If a responder receives a query
|
|
|
+ addressed to the mDNS IPv4 link-local multicast address 224.0.0.251,
|
|
|
+ from a source address not apparently on the same subnet as the
|
|
|
+ responder (or, in the case of IPv6, from a source IPv6 address for
|
|
|
+ which the responder does not have any address with the same prefix on
|
|
|
+ that interface), then even if the query indicates that a unicast
|
|
|
+ response is preferred (see Section 5.4, "Questions Requesting Unicast
|
|
|
+ Responses"), the responder SHOULD elect to respond by multicast
|
|
|
+ anyway, since it can reasonably predict that a unicast response with
|
|
|
+ an apparently non-local source address will probably be ignored.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 39]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+12. Special Characteristics of Multicast DNS Domains
|
|
|
+
|
|
|
+ Unlike conventional DNS names, names that end in ".local." have only
|
|
|
+ local significance. The same is true of names within the IPv4 link-
|
|
|
+ local reverse mapping domain "254.169.in-addr.arpa." and the IPv6
|
|
|
+ link-local reverse mapping domains "8.e.f.ip6.arpa.",
|
|
|
+ "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.".
|
|
|
+
|
|
|
+ These names function primarily as protocol identifiers, rather than
|
|
|
+ as user-visible identifiers. Even though they may occasionally be
|
|
|
+ visible to end users, that is not their primary purpose. As such,
|
|
|
+ these names should be treated as opaque identifiers. In particular,
|
|
|
+ the string "local" should not be translated or localized into
|
|
|
+ different languages, much as the name "localhost" is not translated
|
|
|
+ or localized into different languages.
|
|
|
+
|
|
|
+ Conventional Unicast DNS seeks to provide a single unified namespace,
|
|
|
+ where a given DNS query yields the same answer no matter where on the
|
|
|
+ planet it is performed or to which recursive DNS server the query is
|
|
|
+ sent. In contrast, each IP link has its own private ".local.",
|
|
|
+ "254.169.in-addr.arpa." and IPv6 link-local reverse mapping
|
|
|
+ namespaces, and the answer to any query for a name within those
|
|
|
+ domains depends on where that query is asked. (This characteristic
|
|
|
+ is not unique to Multicast DNS. Although the original concept of DNS
|
|
|
+ was a single global namespace, in recent years, split views,
|
|
|
+ firewalls, intranets, DNS geolocation, and the like have increasingly
|
|
|
+ meant that the answer to a given DNS query has become dependent on
|
|
|
+ the location of the querier.)
|
|
|
+
|
|
|
+ The IPv4 name server address for a Multicast DNS domain is
|
|
|
+ 224.0.0.251. The IPv6 name server address for a Multicast DNS domain
|
|
|
+ is FF02::FB. These are multicast addresses; therefore, they identify
|
|
|
+ not a single host but a collection of hosts, working in cooperation
|
|
|
+ to maintain some reasonable facsimile of a competently managed DNS
|
|
|
+ zone. Conceptually, a Multicast DNS domain is a single DNS zone;
|
|
|
+ however, its server is implemented as a distributed process running
|
|
|
+ on a cluster of loosely cooperating CPUs rather than as a single
|
|
|
+ process running on a single CPU.
|
|
|
+
|
|
|
+ Multicast DNS domains are not delegated from their parent domain via
|
|
|
+ use of NS (Name Server) records, and there is also no concept of
|
|
|
+ delegation of subdomains within a Multicast DNS domain. Just because
|
|
|
+ a particular host on the network may answer queries for a particular
|
|
|
+ record type with the name "example.local." does not imply anything
|
|
|
+ about whether that host will answer for the name
|
|
|
+ "child.example.local.", or indeed for other record types with the
|
|
|
+ name "example.local.".
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 40]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ There are no NS records anywhere in Multicast DNS domains. Instead,
|
|
|
+ the Multicast DNS domains are reserved by IANA, and there is
|
|
|
+ effectively an implicit delegation of all Multicast DNS domains to
|
|
|
+ the 224.0.0.251:5353 and [FF02::FB]:5353 multicast groups, by virtue
|
|
|
+ of client software implementing the protocol rules specified in this
|
|
|
+ document.
|
|
|
+
|
|
|
+ Multicast DNS zones have no SOA (Start of Authority) record. A
|
|
|
+ conventional DNS zone's SOA record contains information such as the
|
|
|
+ email address of the zone administrator and the monotonically
|
|
|
+ increasing serial number of the last zone modification. There is no
|
|
|
+ single human administrator for any given Multicast DNS zone, so there
|
|
|
+ is no email address. Because the hosts managing any given Multicast
|
|
|
+ DNS zone are only loosely coordinated, there is no readily available
|
|
|
+ monotonically increasing serial number to determine whether or not
|
|
|
+ the zone contents have changed. A host holding part of the shared
|
|
|
+ zone could crash or be disconnected from the network at any time
|
|
|
+ without informing the other hosts. There is no reliable way to
|
|
|
+ provide a zone serial number that would, whenever such a crash or
|
|
|
+ disconnection occurred, immediately change to indicate that the
|
|
|
+ contents of the shared zone had changed.
|
|
|
+
|
|
|
+ Zone transfers are not possible for any Multicast DNS zone.
|
|
|
+
|
|
|
+13. Enabling and Disabling Multicast DNS
|
|
|
+
|
|
|
+ The option to fail-over to Multicast DNS for names not ending in
|
|
|
+ ".local." SHOULD be a user-configured option, and SHOULD be disabled
|
|
|
+ by default because of the possible security issues related to
|
|
|
+ unintended local resolution of apparently global names. Enabling
|
|
|
+ Multicast DNS for names not ending in ".local." may be appropriate on
|
|
|
+ a secure isolated network, or on some future network were machines
|
|
|
+ exclusively use DNSSEC for all DNS queries, and have Multicast DNS
|
|
|
+ responders capable of generating the appropriate cryptographic DNSSEC
|
|
|
+ signatures, thereby guarding against spoofing.
|
|
|
+
|
|
|
+ The option to look up unqualified (relative) names by appending
|
|
|
+ ".local." (or not) is controlled by whether ".local." appears (or
|
|
|
+ not) in the client's DNS search list.
|
|
|
+
|
|
|
+ No special control is needed for enabling and disabling Multicast DNS
|
|
|
+ for names explicitly ending with ".local." as entered by the user.
|
|
|
+ The user doesn't need a way to disable Multicast DNS for names ending
|
|
|
+ with ".local.", because if the user doesn't want to use Multicast
|
|
|
+ DNS, they can achieve this by simply not using those names. If a
|
|
|
+ user *does* enter a name ending in ".local.", then we can safely
|
|
|
+ assume the user's intention was probably that it should work. Having
|
|
|
+ user configuration options that can be (intentionally or
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 41]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ unintentionally) set so that local names don't work is just one more
|
|
|
+ way of frustrating the user's ability to perform the tasks they want,
|
|
|
+ perpetuating the view that, "IP networking is too complicated to
|
|
|
+ configure and too hard to use".
|
|
|
+
|
|
|
+14. Considerations for Multiple Interfaces
|
|
|
+
|
|
|
+ A host SHOULD defend its dot-local host name on all active interfaces
|
|
|
+ on which it is answering Multicast DNS queries.
|
|
|
+
|
|
|
+ In the event of a name conflict on *any* interface, a host should
|
|
|
+ configure a new host name, if it wishes to maintain uniqueness of its
|
|
|
+ host name.
|
|
|
+
|
|
|
+ A host may choose to use the same name (or set of names) for all of
|
|
|
+ its address records on all interfaces, or it may choose to manage its
|
|
|
+ Multicast DNS interfaces independently, potentially answering to a
|
|
|
+ different name (or set of names) on different interfaces.
|
|
|
+
|
|
|
+ Except in the case of proxying and other similar specialized uses,
|
|
|
+ addresses in IPv4 or IPv6 address records in Multicast DNS responses
|
|
|
+ MUST be valid for use on the interface on which the response is being
|
|
|
+ sent.
|
|
|
+
|
|
|
+ Just as the same link-local IP address may validly be in use
|
|
|
+ simultaneously on different links by different hosts, the same link-
|
|
|
+ local host name may validly be in use simultaneously on different
|
|
|
+ links, and this is not an error. A multihomed host with connections
|
|
|
+ to two different links may be able to communicate with two different
|
|
|
+ hosts that are validly using the same name. While this kind of name
|
|
|
+ duplication should be rare, it means that a host that wants to fully
|
|
|
+ support this case needs network programming APIs that allow
|
|
|
+ applications to specify on what interface to perform a link-local
|
|
|
+ Multicast DNS query, and to discover on what interface a Multicast
|
|
|
+ DNS response was received.
|
|
|
+
|
|
|
+ There is one other special precaution that multihomed hosts need to
|
|
|
+ take. It's common with today's laptop computers to have an Ethernet
|
|
|
+ connection and an 802.11 [IEEE.802.11] wireless connection active at
|
|
|
+ the same time. What the software on the laptop computer can't easily
|
|
|
+ tell is whether the wireless connection is in fact bridged onto the
|
|
|
+ same network segment as its Ethernet connection. If the two networks
|
|
|
+ are bridged together, then packets the host sends on one interface
|
|
|
+ will arrive on the other interface a few milliseconds later, and care
|
|
|
+ must be taken to ensure that this bridging does not cause problems:
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 42]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ When the host announces its host name (i.e., its address records) on
|
|
|
+ its wireless interface, those announcement records are sent with the
|
|
|
+ cache-flush bit set, so when they arrive on the Ethernet segment,
|
|
|
+ they will cause all the peers on the Ethernet to flush the host's
|
|
|
+ Ethernet address records from their caches. The Multicast DNS
|
|
|
+ protocol has a safeguard to protect against this situation: when
|
|
|
+ records are received with the cache-flush bit set, other records are
|
|
|
+ not deleted from peer caches immediately, but are marked for deletion
|
|
|
+ in one second. When the host sees its own wireless address records
|
|
|
+ arrive on its Ethernet interface, with the cache-flush bit set, this
|
|
|
+ one-second grace period gives the host time to respond and re-
|
|
|
+ announce its Ethernet address records, to reinstate those records in
|
|
|
+ peer caches before they are deleted.
|
|
|
+
|
|
|
+ As described, this solves one problem, but creates another, because
|
|
|
+ when those Ethernet announcement records arrive back on the wireless
|
|
|
+ interface, the host would again respond defensively to reinstate its
|
|
|
+ wireless records, and this process would continue forever,
|
|
|
+ continuously flooding the network with traffic. The Multicast DNS
|
|
|
+ protocol has a second safeguard, to solve this problem: the cache-
|
|
|
+ flush bit does not apply to records received very recently, within
|
|
|
+ the last second. This means that when the host sees its own Ethernet
|
|
|
+ address records arrive on its wireless interface, with the cache-
|
|
|
+ flush bit set, it knows there's no need to re-announce its wireless
|
|
|
+ address records again because it already sent them less than a second
|
|
|
+ ago, and this makes them immune from deletion from peer caches. (See
|
|
|
+ Section 10.2.)
|
|
|
+
|
|
|
+15. Considerations for Multiple Responders on the Same Machine
|
|
|
+
|
|
|
+ It is possible to have more than one Multicast DNS responder and/or
|
|
|
+ querier implementation coexist on the same machine, but there are
|
|
|
+ some known issues.
|
|
|
+
|
|
|
+15.1. Receiving Unicast Responses
|
|
|
+
|
|
|
+ In most operating systems, incoming *multicast* packets can be
|
|
|
+ delivered to *all* open sockets bound to the right port number,
|
|
|
+ provided that the clients take the appropriate steps to allow this.
|
|
|
+ For this reason, all Multicast DNS implementations SHOULD use the
|
|
|
+ SO_REUSEPORT and/or SO_REUSEADDR options (or equivalent as
|
|
|
+ appropriate for the operating system in question) so they will all be
|
|
|
+ able to bind to UDP port 5353 and receive incoming multicast packets
|
|
|
+ addressed to that port. However, unlike multicast packets, incoming
|
|
|
+ unicast UDP packets are typically delivered only to the first socket
|
|
|
+ to bind to that port. This means that "QU" responses and other
|
|
|
+ packets sent via unicast will be received only by the first Multicast
|
|
|
+ DNS responder and/or querier on a system. This limitation can be
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 43]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ partially mitigated if Multicast DNS implementations detect when they
|
|
|
+ are not the first to bind to port 5353, and in that case they do not
|
|
|
+ request "QU" responses. One way to detect if there is another
|
|
|
+ Multicast DNS implementation already running is to attempt binding to
|
|
|
+ port 5353 without using SO_REUSEPORT and/or SO_REUSEADDR, and if that
|
|
|
+ fails it indicates that some other socket is already bound to this
|
|
|
+ port.
|
|
|
+
|
|
|
+15.2. Multipacket Known-Answer lists
|
|
|
+
|
|
|
+ When a Multicast DNS querier issues a query with too many Known
|
|
|
+ Answers to fit into a single packet, it divides the Known-Answer list
|
|
|
+ into two or more packets. Multicast DNS responders associate the
|
|
|
+ initial truncated query with its continuation packets by examining
|
|
|
+ the source IP address in each packet. Since two independent
|
|
|
+ Multicast DNS queriers running on the same machine will be sending
|
|
|
+ packets with the same source IP address, from an outside perspective
|
|
|
+ they appear to be a single entity. If both queriers happened to send
|
|
|
+ the same multipacket query at the same time, with different Known-
|
|
|
+ Answer lists, then they could each end up suppressing answers that
|
|
|
+ the other needs.
|
|
|
+
|
|
|
+15.3. Efficiency
|
|
|
+
|
|
|
+ If different clients on a machine were each to have their own
|
|
|
+ independent Multicast DNS implementation, they would lose certain
|
|
|
+ efficiency benefits. Apart from the unnecessary code duplication,
|
|
|
+ memory usage, and CPU load, the clients wouldn't get the benefit of a
|
|
|
+ shared system-wide cache, and they would not be able to aggregate
|
|
|
+ separate queries into single packets to reduce network traffic.
|
|
|
+
|
|
|
+15.4. Recommendation
|
|
|
+
|
|
|
+ Because of these issues, this document encourages implementers to
|
|
|
+ design systems with a single Multicast DNS implementation that
|
|
|
+ provides Multicast DNS services shared by all clients on that
|
|
|
+ machine, much as most operating systems today have a single TCP
|
|
|
+ implementation, which is shared between all clients on that machine.
|
|
|
+ Due to engineering constraints, there may be situations where
|
|
|
+ embedding a "user-level" Multicast DNS implementation in the client
|
|
|
+ application software is the most expedient solution, and while this
|
|
|
+ will usually work in practice, implementers should be aware of the
|
|
|
+ issues outlined in this section.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 44]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+16. Multicast DNS Character Set
|
|
|
+
|
|
|
+ Historically, Unicast DNS has been used with a very restricted set of
|
|
|
+ characters. Indeed, conventional DNS is usually limited to just
|
|
|
+ twenty-six letters, ten digits and the hyphen character, not even
|
|
|
+ allowing spaces or other punctuation. Attempts to remedy this for
|
|
|
+ Unicast DNS have been badly constrained by the perceived need to
|
|
|
+ accommodate old buggy legacy DNS implementations. In reality, the
|
|
|
+ DNS specification itself actually imposes no limits on what
|
|
|
+ characters may be used in names, and good DNS implementations handle
|
|
|
+ any arbitrary eight-bit data without trouble. "Clarifications to the
|
|
|
+ DNS Specification" [RFC2181] directly discusses the subject of
|
|
|
+ allowable character set in Section 11 ("Name syntax"), and explicitly
|
|
|
+ states that DNS names may contain arbitrary eight-bit data. However,
|
|
|
+ the old rules for ARPANET host names back in the 1980s required host
|
|
|
+ names to be just letters, digits, and hyphens [RFC1034], and since
|
|
|
+ the predominant use of DNS is to store host address records, many
|
|
|
+ have assumed that the DNS protocol itself suffers from the same
|
|
|
+ limitation. It might be accurate to say that there could be
|
|
|
+ hypothetical bad implementations that do not handle eight-bit data
|
|
|
+ correctly, but it would not be accurate to say that the protocol
|
|
|
+ doesn't allow names containing eight-bit data.
|
|
|
+
|
|
|
+ Multicast DNS is a new protocol and doesn't (yet) have old buggy
|
|
|
+ legacy implementations to constrain the design choices. Accordingly,
|
|
|
+ it adopts the simple obvious elegant solution: all names in Multicast
|
|
|
+ DNS MUST be encoded as precomposed UTF-8 [RFC3629] "Net-Unicode"
|
|
|
+ [RFC5198] text.
|
|
|
+
|
|
|
+ Some users of 16-bit Unicode have taken to stuffing a "zero-width
|
|
|
+ nonbreaking space" character (U+FEFF) at the start of each UTF-16
|
|
|
+ file, as a hint to identify whether the data is big-endian or little-
|
|
|
+ endian, and calling it a "Byte Order Mark" (BOM). Since there is
|
|
|
+ only one possible byte order for UTF-8 data, a BOM is neither
|
|
|
+ necessary nor permitted. Multicast DNS names MUST NOT contain a
|
|
|
+ "Byte Order Mark". Any occurrence of the Unicode character U+FEFF at
|
|
|
+ the start or anywhere else in a Multicast DNS name MUST be
|
|
|
+ interpreted as being an actual intended part of the name,
|
|
|
+ representing (just as for any other legal unicode value) an actual
|
|
|
+ literal instance of that character (in this case a zero-width non-
|
|
|
+ breaking space character).
|
|
|
+
|
|
|
+ For names that are restricted to US-ASCII [RFC0020] letters, digits,
|
|
|
+ and hyphens, the UTF-8 encoding is identical to the US-ASCII
|
|
|
+ encoding, so this is entirely compatible with existing host names.
|
|
|
+ For characters outside the US-ASCII range, UTF-8 encoding is used.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 45]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ Multicast DNS implementations MUST NOT use any other encodings apart
|
|
|
+ from precomposed UTF-8 (US-ASCII being considered a compatible subset
|
|
|
+ of UTF-8). The reasons for selecting UTF-8 instead of Punycode
|
|
|
+ [RFC3492] are discussed further in Appendix F.
|
|
|
+
|
|
|
+ The simple rules for case-insensitivity in Unicast DNS [RFC1034]
|
|
|
+ [RFC1035] also apply in Multicast DNS; that is to say, in name
|
|
|
+ comparisons, the lowercase letters "a" to "z" (0x61 to 0x7A) match
|
|
|
+ their uppercase equivalents "A" to "Z" (0x41 to 0x5A). Hence, if a
|
|
|
+ querier issues a query for an address record with the name
|
|
|
+ "myprinter.local.", then a responder having an address record with
|
|
|
+ the name "MyPrinter.local." should issue a response. No other
|
|
|
+ automatic equivalences should be assumed. In particular, all UTF-8
|
|
|
+ multibyte characters (codes 0x80 and higher) are compared by simple
|
|
|
+ binary comparison of the raw byte values. Accented characters are
|
|
|
+ *not* defined to be automatically equivalent to their unaccented
|
|
|
+ counterparts. Where automatic equivalences are desired, this may be
|
|
|
+ achieved through the use of programmatically generated CNAME records.
|
|
|
+ For example, if a responder has an address record for an accented
|
|
|
+ name Y, and a querier issues a query for a name X, where X is the
|
|
|
+ same as Y with all the accents removed, then the responder may issue
|
|
|
+ a response containing two resource records: a CNAME record "X CNAME
|
|
|
+ Y", asserting that the requested name X (unaccented) is an alias for
|
|
|
+ the true (accented) name Y, followed by the address record for Y.
|
|
|
+
|
|
|
+17. Multicast DNS Message Size
|
|
|
+
|
|
|
+ The 1987 DNS specification [RFC1035] restricts DNS messages carried
|
|
|
+ by UDP to no more than 512 bytes (not counting the IP or UDP
|
|
|
+ headers). For UDP packets carried over the wide-area Internet in
|
|
|
+ 1987, this was appropriate. For link-local multicast packets on
|
|
|
+ today's networks, there is no reason to retain this restriction.
|
|
|
+ Given that the packets are by definition link-local, there are no
|
|
|
+ Path MTU issues to consider.
|
|
|
+
|
|
|
+ Multicast DNS messages carried by UDP may be up to the IP MTU of the
|
|
|
+ physical interface, less the space required for the IP header (20
|
|
|
+ bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes).
|
|
|
+
|
|
|
+ In the case of a single Multicast DNS resource record that is too
|
|
|
+ large to fit in a single MTU-sized multicast response packet, a
|
|
|
+ Multicast DNS responder SHOULD send the resource record alone, in a
|
|
|
+ single IP datagram, using multiple IP fragments. Resource records
|
|
|
+ this large SHOULD be avoided, except in the very rare cases where
|
|
|
+ they really are the appropriate solution to the problem at hand.
|
|
|
+ Implementers should be aware that many simple devices do not
|
|
|
+ reassemble fragmented IP datagrams, so large resource records SHOULD
|
|
|
+ NOT be used except in specialized cases where the implementer knows
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 46]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ that all receivers implement reassembly, or where the large resource
|
|
|
+ record contains optional data which is not essential for correct
|
|
|
+ operation of the client.
|
|
|
+
|
|
|
+ A Multicast DNS packet larger than the interface MTU, which is sent
|
|
|
+ using fragments, MUST NOT contain more than one resource record.
|
|
|
+
|
|
|
+ Even when fragmentation is used, a Multicast DNS packet, including IP
|
|
|
+ and UDP headers, MUST NOT exceed 9000 bytes.
|
|
|
+
|
|
|
+ Note that 9000 bytes is also the maximum payload size of an Ethernet
|
|
|
+ "Jumbo" packet [Jumbo]. However, in practice Ethernet "Jumbo"
|
|
|
+ packets are not widely used, so it is advantageous to keep packets
|
|
|
+ under 1500 bytes whenever possible. Even on hosts that normally
|
|
|
+ handle Ethernet "Jumbo" packets and IP fragment reassembly, it is
|
|
|
+ becoming more common for these hosts to implement power-saving modes
|
|
|
+ where the main CPU goes to sleep and hands off packet reception tasks
|
|
|
+ to a more limited processor in the network interface hardware, which
|
|
|
+ may not support Ethernet "Jumbo" packets or IP fragment reassembly.
|
|
|
+
|
|
|
+18. Multicast DNS Message Format
|
|
|
+
|
|
|
+ This section describes specific rules pertaining to the allowable
|
|
|
+ values for the header fields of a Multicast DNS message, and other
|
|
|
+ message format considerations.
|
|
|
+
|
|
|
+18.1. ID (Query Identifier)
|
|
|
+
|
|
|
+ Multicast DNS implementations SHOULD listen for unsolicited responses
|
|
|
+ issued by hosts booting up (or waking up from sleep or otherwise
|
|
|
+ joining the network). Since these unsolicited responses may contain
|
|
|
+ a useful answer to a question for which the querier is currently
|
|
|
+ awaiting an answer, Multicast DNS implementations SHOULD examine all
|
|
|
+ received Multicast DNS response messages for useful answers, without
|
|
|
+ regard to the contents of the ID field or the Question Section. In
|
|
|
+ Multicast DNS, knowing which particular query message (if any) is
|
|
|
+ responsible for eliciting a particular response message is less
|
|
|
+ interesting than knowing whether the response message contains useful
|
|
|
+ information.
|
|
|
+
|
|
|
+ Multicast DNS implementations MAY cache data from any or all
|
|
|
+ Multicast DNS response messages they receive, for possible future
|
|
|
+ use, provided of course that normal TTL aging is performed on these
|
|
|
+ cached resource records.
|
|
|
+
|
|
|
+ In multicast query messages, the Query Identifier SHOULD be set to
|
|
|
+ zero on transmission.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 47]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ In multicast responses, including unsolicited multicast responses,
|
|
|
+ the Query Identifier MUST be set to zero on transmission, and MUST be
|
|
|
+ ignored on reception.
|
|
|
+
|
|
|
+ In legacy unicast response messages generated specifically in
|
|
|
+ response to a particular (unicast or multicast) query, the Query
|
|
|
+ Identifier MUST match the ID from the query message.
|
|
|
+
|
|
|
+18.2. QR (Query/Response) Bit
|
|
|
+
|
|
|
+ In query messages the QR bit MUST be zero.
|
|
|
+ In response messages the QR bit MUST be one.
|
|
|
+
|
|
|
+18.3. OPCODE
|
|
|
+
|
|
|
+ In both multicast query and multicast response messages, the OPCODE
|
|
|
+ MUST be zero on transmission (only standard queries are currently
|
|
|
+ supported over multicast). Multicast DNS messages received with an
|
|
|
+ OPCODE other than zero MUST be silently ignored.
|
|
|
+
|
|
|
+18.4. AA (Authoritative Answer) Bit
|
|
|
+
|
|
|
+ In query messages, the Authoritative Answer bit MUST be zero on
|
|
|
+ transmission, and MUST be ignored on reception.
|
|
|
+
|
|
|
+ In response messages for Multicast domains, the Authoritative Answer
|
|
|
+ bit MUST be set to one (not setting this bit would imply there's some
|
|
|
+ other place where "better" information may be found) and MUST be
|
|
|
+ ignored on reception.
|
|
|
+
|
|
|
+18.5. TC (Truncated) Bit
|
|
|
+
|
|
|
+ In query messages, if the TC bit is set, it means that additional
|
|
|
+ Known-Answer records may be following shortly. A responder SHOULD
|
|
|
+ record this fact, and wait for those additional Known-Answer records,
|
|
|
+ before deciding whether to respond. If the TC bit is clear, it means
|
|
|
+ that the querying host has no additional Known Answers.
|
|
|
+
|
|
|
+ In multicast response messages, the TC bit MUST be zero on
|
|
|
+ transmission, and MUST be ignored on reception.
|
|
|
+
|
|
|
+ In legacy unicast response messages, the TC bit has the same meaning
|
|
|
+ as in conventional Unicast DNS: it means that the response was too
|
|
|
+ large to fit in a single packet, so the querier SHOULD reissue its
|
|
|
+ query using TCP in order to receive the larger response.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 48]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+18.6. RD (Recursion Desired) Bit
|
|
|
+
|
|
|
+ In both multicast query and multicast response messages, the
|
|
|
+ Recursion Desired bit SHOULD be zero on transmission, and MUST be
|
|
|
+ ignored on reception.
|
|
|
+
|
|
|
+18.7. RA (Recursion Available) Bit
|
|
|
+
|
|
|
+ In both multicast query and multicast response messages, the
|
|
|
+ Recursion Available bit MUST be zero on transmission, and MUST be
|
|
|
+ ignored on reception.
|
|
|
+
|
|
|
+18.8. Z (Zero) Bit
|
|
|
+
|
|
|
+ In both query and response messages, the Zero bit MUST be zero on
|
|
|
+ transmission, and MUST be ignored on reception.
|
|
|
+
|
|
|
+18.9. AD (Authentic Data) Bit
|
|
|
+
|
|
|
+ In both multicast query and multicast response messages, the
|
|
|
+ Authentic Data bit [RFC2535] MUST be zero on transmission, and MUST
|
|
|
+ be ignored on reception.
|
|
|
+
|
|
|
+18.10. CD (Checking Disabled) Bit
|
|
|
+
|
|
|
+ In both multicast query and multicast response messages, the Checking
|
|
|
+ Disabled bit [RFC2535] MUST be zero on transmission, and MUST be
|
|
|
+ ignored on reception.
|
|
|
+
|
|
|
+18.11. RCODE (Response Code)
|
|
|
+
|
|
|
+ In both multicast query and multicast response messages, the Response
|
|
|
+ Code MUST be zero on transmission. Multicast DNS messages received
|
|
|
+ with non-zero Response Codes MUST be silently ignored.
|
|
|
+
|
|
|
+18.12. Repurposing of Top Bit of qclass in Question Section
|
|
|
+
|
|
|
+ In the Question Section of a Multicast DNS query, the top bit of the
|
|
|
+ qclass field is used to indicate that unicast responses are preferred
|
|
|
+ for this particular question. (See Section 5.4.)
|
|
|
+
|
|
|
+18.13. Repurposing of Top Bit of rrclass in Resource Record Sections
|
|
|
+
|
|
|
+ In the Resource Record Sections of a Multicast DNS response, the top
|
|
|
+ bit of the rrclass field is used to indicate that the record is a
|
|
|
+ member of a unique RRSet, and the entire RRSet has been sent together
|
|
|
+ (in the same packet, or in consecutive packets if there are too many
|
|
|
+ records to fit in a single packet). (See Section 10.2.)
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 49]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+18.14. Name Compression
|
|
|
+
|
|
|
+ When generating Multicast DNS messages, implementations SHOULD use
|
|
|
+ name compression wherever possible to compress the names of resource
|
|
|
+ records, by replacing some or all of the resource record name with a
|
|
|
+ compact two-byte reference to an appearance of that data somewhere
|
|
|
+ earlier in the message [RFC1035].
|
|
|
+
|
|
|
+ This applies not only to Multicast DNS responses, but also to
|
|
|
+ queries. When a query contains more than one question, successive
|
|
|
+ questions in the same message often contain similar names, and
|
|
|
+ consequently name compression SHOULD be used, to save bytes. In
|
|
|
+ addition, queries may also contain Known Answers in the Answer
|
|
|
+ Section, or probe tiebreaking data in the Authority Section, and
|
|
|
+ these names SHOULD similarly be compressed for network efficiency.
|
|
|
+
|
|
|
+ In addition to compressing the *names* of resource records, names
|
|
|
+ that appear within the *rdata* of the following rrtypes SHOULD also
|
|
|
+ be compressed in all Multicast DNS messages:
|
|
|
+
|
|
|
+ NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC
|
|
|
+
|
|
|
+ Until future IETF Standards Action [RFC5226] specifying that names in
|
|
|
+ the rdata of other types should be compressed, names that appear
|
|
|
+ within the rdata of any type not listed above MUST NOT be compressed.
|
|
|
+
|
|
|
+ Implementations receiving Multicast DNS messages MUST correctly
|
|
|
+ decode compressed names appearing in the Question Section, and
|
|
|
+ compressed names of resource records appearing in other sections.
|
|
|
+
|
|
|
+ In addition, implementations MUST correctly decode compressed names
|
|
|
+ appearing within the *rdata* of the rrtypes listed above. Where
|
|
|
+ possible, implementations SHOULD also correctly decode compressed
|
|
|
+ names appearing within the *rdata* of other rrtypes known to the
|
|
|
+ implementers at the time of implementation, because such forward-
|
|
|
+ thinking planning helps facilitate the deployment of future
|
|
|
+ implementations that may have reason to compress those rrtypes. It
|
|
|
+ is possible that no future IETF Standards Action [RFC5226] will be
|
|
|
+ created that mandates or permits the compression of rdata in new
|
|
|
+ types, but having implementations designed such that they are capable
|
|
|
+ of decompressing all known types helps keep future options open.
|
|
|
+
|
|
|
+ One specific difference between Unicast DNS and Multicast DNS is that
|
|
|
+ Unicast DNS does not allow name compression for the target host in an
|
|
|
+ SRV record, because Unicast DNS implementations before the first SRV
|
|
|
+ specification in 1996 [RFC2052] may not decode these compressed
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 50]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ records properly. Since all Multicast DNS implementations were
|
|
|
+ created after 1996, all Multicast DNS implementations are REQUIRED to
|
|
|
+ decode compressed SRV records correctly.
|
|
|
+
|
|
|
+ In legacy unicast responses generated to answer legacy queries, name
|
|
|
+ compression MUST NOT be performed on SRV records.
|
|
|
+
|
|
|
+19. Summary of Differences between Multicast DNS and Unicast DNS
|
|
|
+
|
|
|
+ Multicast DNS shares, as much as possible, the familiar APIs, naming
|
|
|
+ syntax, resource record types, etc., of Unicast DNS. There are, of
|
|
|
+ course, necessary differences by virtue of it using multicast, and by
|
|
|
+ virtue of it operating in a community of cooperating peers, rather
|
|
|
+ than a precisely defined hierarchy controlled by a strict chain of
|
|
|
+ formal delegations from the root. These differences are summarized
|
|
|
+ below:
|
|
|
+
|
|
|
+ Multicast DNS...
|
|
|
+ * uses multicast
|
|
|
+ * uses UDP port 5353 instead of port 53
|
|
|
+ * operates in well-defined parts of the DNS namespace
|
|
|
+ * has no SOA (Start of Authority) records
|
|
|
+ * uses UTF-8, and only UTF-8, to encode resource record names
|
|
|
+ * allows names up to 255 bytes plus a terminating zero byte
|
|
|
+ * allows name compression in rdata for SRV and other record types
|
|
|
+ * allows larger UDP packets
|
|
|
+ * allows more than one question in a query message
|
|
|
+ * defines consistent results for qtype "ANY" and qclass "ANY" queries
|
|
|
+ * uses the Answer Section of a query to list Known Answers
|
|
|
+ * uses the TC bit in a query to indicate additional Known Answers
|
|
|
+ * uses the Authority Section of a query for probe tiebreaking
|
|
|
+ * ignores the Query ID field (except for generating legacy responses)
|
|
|
+ * doesn't require the question to be repeated in the response message
|
|
|
+ * uses unsolicited responses to announce new records
|
|
|
+ * uses NSEC records to signal nonexistence of records
|
|
|
+ * defines a unicast-response bit in the rrclass of query questions
|
|
|
+ * defines a cache-flush bit in the rrclass of response records
|
|
|
+ * uses DNS RR TTL 0 to indicate that a record has been deleted
|
|
|
+ * recommends AAAA records in the additional section when responding
|
|
|
+ to rrtype "A" queries, and vice versa
|
|
|
+ * monitors queries to perform Duplicate Question Suppression
|
|
|
+ * monitors responses to perform Duplicate Answer Suppression...
|
|
|
+ * ... and Ongoing Conflict Detection
|
|
|
+ * ... and Opportunistic Caching
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 51]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+20. IPv6 Considerations
|
|
|
+
|
|
|
+ An IPv4-only host and an IPv6-only host behave as "ships that pass in
|
|
|
+ the night". Even if they are on the same Ethernet, neither is aware
|
|
|
+ of the other's traffic. For this reason, each physical link may have
|
|
|
+ *two* unrelated ".local." zones, one for IPv4 and one for IPv6.
|
|
|
+ Since for practical purposes, a group of IPv4-only hosts and a group
|
|
|
+ of IPv6-only hosts on the same Ethernet act as if they were on two
|
|
|
+ entirely separate Ethernet segments, it is unsurprising that their
|
|
|
+ use of the ".local." zone should occur exactly as it would if they
|
|
|
+ really were on two entirely separate Ethernet segments.
|
|
|
+
|
|
|
+ A dual-stack (v4/v6) host can participate in both ".local." zones,
|
|
|
+ and should register its name(s) and perform its lookups both using
|
|
|
+ IPv4 and IPv6. This enables it to reach, and be reached by, both
|
|
|
+ IPv4-only and IPv6-only hosts. In effect, this acts like a
|
|
|
+ multihomed host, with one connection to the logical "IPv4 Ethernet
|
|
|
+ segment", and a connection to the logical "IPv6 Ethernet segment".
|
|
|
+ When such a host generates NSEC records, if it is using the same host
|
|
|
+ name for its IPv4 addresses and its IPv6 addresses on that network
|
|
|
+ interface, its NSEC records should indicate that the host name has
|
|
|
+ both A and AAAA records.
|
|
|
+
|
|
|
+21. Security Considerations
|
|
|
+
|
|
|
+ The algorithm for detecting and resolving name conflicts is, by its
|
|
|
+ very nature, an algorithm that assumes cooperating participants. Its
|
|
|
+ purpose is to allow a group of hosts to arrive at a mutually disjoint
|
|
|
+ set of host names and other DNS resource record names, in the absence
|
|
|
+ of any central authority to coordinate this or mediate disputes. In
|
|
|
+ the absence of any higher authority to resolve disputes, the only
|
|
|
+ alternative is that the participants must work together cooperatively
|
|
|
+ to arrive at a resolution.
|
|
|
+
|
|
|
+ In an environment where the participants are mutually antagonistic
|
|
|
+ and unwilling to cooperate, other mechanisms are appropriate, like
|
|
|
+ manually configured DNS.
|
|
|
+
|
|
|
+ In an environment where there is a group of cooperating participants,
|
|
|
+ but clients cannot be sure that there are no antagonistic hosts on
|
|
|
+ the same physical link, the cooperating participants need to use
|
|
|
+ IPsec signatures and/or DNSSEC [RFC4033] signatures so that they can
|
|
|
+ distinguish Multicast DNS messages from trusted participants (which
|
|
|
+ they process as usual) from Multicast DNS messages from untrusted
|
|
|
+ participants (which they silently discard).
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 52]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ If DNS queries for *global* DNS names are sent to the mDNS multicast
|
|
|
+ address (during network outages which disrupt communication with the
|
|
|
+ greater Internet) it is *especially* important to use DNSSEC, because
|
|
|
+ the user may have the impression that he or she is communicating with
|
|
|
+ some authentic host, when in fact he or she is really communicating
|
|
|
+ with some local host that is merely masquerading as that name. This
|
|
|
+ is less critical for names ending with ".local.", because the user
|
|
|
+ should be aware that those names have only local significance and no
|
|
|
+ global authority is implied.
|
|
|
+
|
|
|
+ Most computer users neglect to type the trailing dot at the end of a
|
|
|
+ fully qualified domain name, making it a relative domain name (e.g.,
|
|
|
+ "www.example.com"). In the event of network outage, attempts to
|
|
|
+ positively resolve the name as entered will fail, resulting in
|
|
|
+ application of the search list, including ".local.", if present. A
|
|
|
+ malicious host could masquerade as "www.example.com." by answering
|
|
|
+ the resulting Multicast DNS query for "www.example.com.local.". To
|
|
|
+ avoid this, a host MUST NOT append the search suffix ".local.", if
|
|
|
+ present, to any relative (partially qualified) host name containing
|
|
|
+ two or more labels. Appending ".local." to single-label relative
|
|
|
+ host names is acceptable, since the user should have no expectation
|
|
|
+ that a single-label host name will resolve as is. However, users who
|
|
|
+ have both "example.com" and "local" in their search lists should be
|
|
|
+ aware that if they type "www" into their web browser, it may not be
|
|
|
+ immediately clear to them whether the page that appears is
|
|
|
+ "www.example.com" or "www.local".
|
|
|
+
|
|
|
+ Multicast DNS uses UDP port 5353. On operating systems where only
|
|
|
+ privileged processes are allowed to use ports below 1024, no such
|
|
|
+ privilege is required to use port 5353.
|
|
|
+
|
|
|
+22. IANA Considerations
|
|
|
+
|
|
|
+ IANA has allocated the UDP port 5353 for the Multicast DNS protocol
|
|
|
+ described in this document [SN].
|
|
|
+
|
|
|
+ IANA has allocated the IPv4 link-local multicast address 224.0.0.251
|
|
|
+ for the use described in this document [MC4].
|
|
|
+
|
|
|
+ IANA has allocated the IPv6 multicast address set FF0X::FB (where "X"
|
|
|
+ indicates any hexadecimal digit from '1' to 'F') for the use
|
|
|
+ described in this document [MC6]. Only address FF02::FB (link-local
|
|
|
+ scope) is currently in use by deployed software, but it is possible
|
|
|
+ that in the future implementers may experiment with Multicast DNS
|
|
|
+ using larger-scoped addresses, such as FF05::FB (site-local scope)
|
|
|
+ [RFC4291].
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 53]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ IANA has implemented the following DNS records:
|
|
|
+
|
|
|
+ MDNS.MCAST.NET. IN A 224.0.0.251
|
|
|
+ 251.0.0.224.IN-ADDR.ARPA. IN PTR MDNS.MCAST.NET.
|
|
|
+
|
|
|
+ Entries for the AAAA and corresponding PTR records have not been made
|
|
|
+ as there is not yet an RFC providing direction for the management of
|
|
|
+ the IP6.ARPA domain relating to the IPv6 multicast address space.
|
|
|
+
|
|
|
+ The reuse of the top bit of the rrclass field in the Question and
|
|
|
+ Resource Record Sections means that Multicast DNS can only carry DNS
|
|
|
+ records with classes in the range 0-32767. Classes in the range
|
|
|
+ 32768 to 65535 are incompatible with Multicast DNS. IANA has noted
|
|
|
+ this fact, and if IANA receives a request to allocate a DNS class
|
|
|
+ value above 32767, IANA will make sure the requester is aware of this
|
|
|
+ implication before proceeding. This does not mean that allocations
|
|
|
+ of DNS class values above 32767 should be denied, only that they
|
|
|
+ should not be allowed until the requester has indicated that they are
|
|
|
+ aware of how this allocation will interact with Multicast DNS.
|
|
|
+ However, to date, only three DNS classes have been assigned by IANA
|
|
|
+ (1, 3, and 4), and only one (1, "Internet") is actually in widespread
|
|
|
+ use, so this issue is likely to remain a purely theoretical one.
|
|
|
+
|
|
|
+ IANA has recorded the list of domains below as being Special-Use
|
|
|
+ Domain Names [RFC6761]:
|
|
|
+
|
|
|
+ .local.
|
|
|
+ .254.169.in-addr.arpa.
|
|
|
+ .8.e.f.ip6.arpa.
|
|
|
+ .9.e.f.ip6.arpa.
|
|
|
+ .a.e.f.ip6.arpa.
|
|
|
+ .b.e.f.ip6.arpa.
|
|
|
+
|
|
|
+22.1. Domain Name Reservation Considerations
|
|
|
+
|
|
|
+ The six domains listed above, and any names falling within those
|
|
|
+ domains (e.g., "MyPrinter.local.", "34.12.254.169.in-addr.arpa.",
|
|
|
+ "Ink-Jet._pdl-datastream._tcp.local.") are special [RFC6761] in the
|
|
|
+ following ways:
|
|
|
+
|
|
|
+ 1. Users may use these names as they would other DNS names,
|
|
|
+ entering them anywhere that they would otherwise enter a
|
|
|
+ conventional DNS name, or a dotted decimal IPv4 address, or a
|
|
|
+ literal IPv6 address.
|
|
|
+
|
|
|
+ Since there is no central authority responsible for assigning
|
|
|
+ dot-local names, and all devices on the local network are
|
|
|
+ equally entitled to claim any dot-local name, users SHOULD be
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 54]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ aware of this and SHOULD exercise appropriate caution. In an
|
|
|
+ untrusted or unfamiliar network environment, users SHOULD be
|
|
|
+ aware that using a name like "www.local" may not actually
|
|
|
+ connect them to the web site they expected, and could easily
|
|
|
+ connect them to a different web page, or even a fake or spoof
|
|
|
+ of their intended web site, designed to trick them into
|
|
|
+ revealing confidential information. As always with networking,
|
|
|
+ end-to-end cryptographic security can be a useful tool. For
|
|
|
+ example, when connecting with ssh, the ssh host key
|
|
|
+ verification process will inform the user if it detects that
|
|
|
+ the identity of the entity they are communicating with has
|
|
|
+ changed since the last time they connected to that name.
|
|
|
+
|
|
|
+ 2. Application software may use these names as they would other
|
|
|
+ similar DNS names, and is not required to recognize the names
|
|
|
+ and treat them specially. Due to the relative ease of spoofing
|
|
|
+ dot-local names, end-to-end cryptographic security remains
|
|
|
+ important when communicating across a local network, just as it
|
|
|
+ is when communicating across the global Internet.
|
|
|
+
|
|
|
+ 3. Name resolution APIs and libraries SHOULD recognize these names
|
|
|
+ as special and SHOULD NOT send queries for these names to their
|
|
|
+ configured (unicast) caching DNS server(s). This is to avoid
|
|
|
+ unnecessary load on the root name servers and other name
|
|
|
+ servers, caused by queries for which those name servers do not
|
|
|
+ have useful non-negative answers to give, and will not ever
|
|
|
+ have useful non-negative answers to give.
|
|
|
+
|
|
|
+ 4. Caching DNS servers SHOULD recognize these names as special and
|
|
|
+ SHOULD NOT attempt to look up NS records for them, or otherwise
|
|
|
+ query authoritative DNS servers in an attempt to resolve these
|
|
|
+ names. Instead, caching DNS servers SHOULD generate immediate
|
|
|
+ NXDOMAIN responses for all such queries they may receive (from
|
|
|
+ misbehaving name resolver libraries). This is to avoid
|
|
|
+ unnecessary load on the root name servers and other name
|
|
|
+ servers.
|
|
|
+
|
|
|
+ 5. Authoritative DNS servers SHOULD NOT by default be configurable
|
|
|
+ to answer queries for these names, and, like caching DNS
|
|
|
+ servers, SHOULD generate immediate NXDOMAIN responses for all
|
|
|
+ such queries they may receive. DNS server software MAY provide
|
|
|
+ a configuration option to override this default, for testing
|
|
|
+ purposes or other specialized uses.
|
|
|
+
|
|
|
+ 6. DNS server operators SHOULD NOT attempt to configure
|
|
|
+ authoritative DNS servers to act as authoritative for any of
|
|
|
+ these names. Configuring an authoritative DNS server to act as
|
|
|
+ authoritative for any of these names may not, in many cases,
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 55]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ yield the expected result. Since name resolver libraries and
|
|
|
+ caching DNS servers SHOULD NOT send queries for those names
|
|
|
+ (see 3 and 4 above), such queries SHOULD be suppressed before
|
|
|
+ they even reach the authoritative DNS server in question, and
|
|
|
+ consequently it will not even get an opportunity to answer
|
|
|
+ them.
|
|
|
+
|
|
|
+ 7. DNS Registrars MUST NOT allow any of these names to be
|
|
|
+ registered in the normal way to any person or entity. These
|
|
|
+ names are reserved protocol identifiers with special meaning
|
|
|
+ and fall outside the set of names available for allocation by
|
|
|
+ registrars. Attempting to allocate one of these names as if it
|
|
|
+ were a normal domain name will probably not work as desired,
|
|
|
+ for reasons 3, 4, and 6 above.
|
|
|
+
|
|
|
+23. Acknowledgments
|
|
|
+
|
|
|
+ The concepts described in this document have been explored,
|
|
|
+ developed, and implemented with help from Ran Atkinson, Richard
|
|
|
+ Brown, Freek Dijkstra, Erik Guttman, Kyle McKay, Pasi Sarolahti,
|
|
|
+ Pekka Savola, Robby Simpson, Mark Townsley, Paul Vixie, Bill
|
|
|
+ Woodcock, and others. Special thanks go to Bob Bradley, Josh
|
|
|
+ Graessley, Scott Herscher, Rory McGuire, Roger Pantos, and Kiren
|
|
|
+ Sekar for their significant contributions. Special thanks also to
|
|
|
+ Kerry Lynn for converting the document to xml2rfc form in May 2010,
|
|
|
+ and to Area Director Ralph Droms for shepherding the document through
|
|
|
+ its final steps.
|
|
|
+
|
|
|
+24. References
|
|
|
+
|
|
|
+24.1. Normative References
|
|
|
+
|
|
|
+ [MC4] IANA, "IPv4 Multicast Address Space Registry",
|
|
|
+ <http://www.iana.org/assignments/multicast-addresses/>.
|
|
|
+
|
|
|
+ [MC6] IANA, "IPv6 Multicast Address Space Registry",
|
|
|
+ <http://www.iana.org/assignments/
|
|
|
+ ipv6-multicast-addresses/>.
|
|
|
+
|
|
|
+ [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20,
|
|
|
+ October 1969.
|
|
|
+
|
|
|
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
|
|
|
+ STD 13, RFC 1034, November 1987.
|
|
|
+
|
|
|
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
|
|
|
+ specification", STD 13, RFC 1035, November 1987.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 56]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|
|
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
|
+
|
|
|
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
|
|
|
+ 10646", STD 63, RFC 3629, November 2003.
|
|
|
+
|
|
|
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
|
|
+ Rose, "Resource Records for the DNS Security Extensions",
|
|
|
+ RFC 4034, March 2005.
|
|
|
+
|
|
|
+ [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
|
|
|
+ Interchange", RFC 5198, March 2008.
|
|
|
+
|
|
|
+ [RFC6195] Eastlake 3rd, D., "Domain Name System (DNS) IANA
|
|
|
+ Considerations", BCP 42, RFC 6195, March 2011.
|
|
|
+
|
|
|
+ [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
|
|
|
+ RFC 6761, February 2013.
|
|
|
+
|
|
|
+ [SN] IANA, "Service Name and Transport Protocol Port Number
|
|
|
+ Registry", <http://www.iana.org/assignments/
|
|
|
+ service-names-port-numbers/>.
|
|
|
+
|
|
|
+24.2. Informative References
|
|
|
+
|
|
|
+ [B4W] "Bonjour for Windows",
|
|
|
+ <http://en.wikipedia.org/wiki/Bonjour_(software)>.
|
|
|
+
|
|
|
+ [BJ] Apple Bonjour Open Source Software,
|
|
|
+ <http://developer.apple.com/bonjour/>.
|
|
|
+
|
|
|
+ [IEEE.802.3]
|
|
|
+ "Information technology - Telecommunications and
|
|
|
+ information exchange between systems - Local and
|
|
|
+ metropolitan area networks - Specific requirements - Part
|
|
|
+ 3: Carrier Sense Multiple Access with Collision Detection
|
|
|
+ (CMSA/CD) Access Method and Physical Layer
|
|
|
+ Specifications", IEEE Std 802.3-2008, December 2008,
|
|
|
+ <http://standards.ieee.org/getieee802/802.3.html>.
|
|
|
+
|
|
|
+ [IEEE.802.11]
|
|
|
+ "Information technology - Telecommunications and
|
|
|
+ information exchange between systems - Local and
|
|
|
+ metropolitan area networks - Specific requirements - Part
|
|
|
+ 11: Wireless LAN Medium Access Control (MAC) and Physical
|
|
|
+ Layer (PHY) Specifications", IEEE Std 802.11-2007, June
|
|
|
+ 2007, <http://standards.ieee.org/getieee802/802.11.html>.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 57]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ [Jumbo] "Ethernet Jumbo Frames", November 2009,
|
|
|
+ <http://www.ethernetalliance.org/library/whitepaper/
|
|
|
+ ethernet-jumbo-frames/>.
|
|
|
+
|
|
|
+ [NIAS] Cheshire, S. "Discovering Named Instances of Abstract
|
|
|
+ Services using DNS", Work in Progress, July 2001.
|
|
|
+
|
|
|
+ [NSD] "NsdManager | Android Developer", June 2012,
|
|
|
+ <http://developer.android.com/reference/
|
|
|
+ android/net/nsd/NsdManager.html>.
|
|
|
+
|
|
|
+ [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
|
|
|
+ location of services (DNS SRV)", RFC 2052, October 1996.
|
|
|
+
|
|
|
+ [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
|
|
|
+ Extensions", RFC 2132, March 1997.
|
|
|
+
|
|
|
+ [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
|
|
|
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",
|
|
|
+ RFC 2136, April 1997.
|
|
|
+
|
|
|
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
|
|
|
+ Specification", RFC 2181, July 1997.
|
|
|
+
|
|
|
+ [RFC2535] Eastlake 3rd, D., "Domain Name System Security
|
|
|
+ Extensions", RFC 2535, March 1999.
|
|
|
+
|
|
|
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
|
|
|
+ 2671, August 1999.
|
|
|
+
|
|
|
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
|
|
|
+ Wellington, "Secret Key Transaction Authentication for DNS
|
|
|
+ (TSIG)", RFC 2845, May 2000.
|
|
|
+
|
|
|
+ [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
|
|
|
+ RR)", RFC 2930, September 2000.
|
|
|
+
|
|
|
+ [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
|
|
|
+ ( SIG(0)s )", RFC 2931, September 2000.
|
|
|
+
|
|
|
+ [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
|
|
|
+ Update", RFC 3007, November 2000.
|
|
|
+
|
|
|
+ [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
|
|
|
+ for Internationalized Domain Names in Applications
|
|
|
+ (IDNA)", RFC 3492, March 2003.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 58]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
|
|
|
+ Configuration of IPv4 Link-Local Addresses", RFC 3927, May
|
|
|
+ 2005.
|
|
|
+
|
|
|
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
|
|
+ Rose, "DNS Security Introduction and Requirements", RFC
|
|
|
+ 4033, March 2005.
|
|
|
+
|
|
|
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
|
|
|
+ Architecture", RFC 4291, February 2006.
|
|
|
+
|
|
|
+ [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
|
|
|
+ Multicast Name Resolution (LLMNR)", RFC 4795, January
|
|
|
+ 2007.
|
|
|
+
|
|
|
+ [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
|
|
|
+ "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
|
|
|
+ September 2007.
|
|
|
+
|
|
|
+ [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
|
|
|
+ Address Autoconfiguration", RFC 4862, September 2007.
|
|
|
+
|
|
|
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
|
|
|
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
|
|
|
+ May 2008.
|
|
|
+
|
|
|
+ [RFC5890] Klensin, J., "Internationalized Domain Names for
|
|
|
+ Applications (IDNA): Definitions and Document Framework",
|
|
|
+ RFC 5890, August 2010.
|
|
|
+
|
|
|
+ [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
|
|
|
+ "Understanding Apple's Back to My Mac (BTMM) Service", RFC
|
|
|
+ 6281, June 2011.
|
|
|
+
|
|
|
+ [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol
|
|
|
+ to Replace the AppleTalk Name Binding Protocol (NBP)", RFC
|
|
|
+ 6760, February 2013.
|
|
|
+
|
|
|
+ [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
|
|
|
+ Discovery", RFC 6763, February 2013.
|
|
|
+
|
|
|
+ [Zeroconf] Cheshire, S. and D. Steinberg, "Zero Configuration
|
|
|
+ Networking: The Definitive Guide", O'Reilly Media, Inc.,
|
|
|
+ ISBN 0-596-10100-7, December 2005.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 59]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+Appendix A. Design Rationale for Choice of UDP Port Number
|
|
|
+
|
|
|
+ Arguments were made for and against using UDP port 53, the standard
|
|
|
+ Unicast DNS port. Some of the arguments are given below. The
|
|
|
+ arguments for using a different port were greater in number and more
|
|
|
+ compelling, so that option was ultimately selected. The UDP port
|
|
|
+ "5353" was selected for its mnemonic similarity to "53".
|
|
|
+
|
|
|
+ Arguments for using UDP port 53:
|
|
|
+
|
|
|
+ * This is "just DNS", so it should be the same port.
|
|
|
+
|
|
|
+ * There is less work to be done updating old resolver libraries to do
|
|
|
+ simple Multicast DNS queries. Only the destination address need be
|
|
|
+ changed. In some cases, this can be achieved without any code
|
|
|
+ changes, just by adding the address 224.0.0.251 to a configuration
|
|
|
+ file.
|
|
|
+
|
|
|
+ Arguments for using a different port (UDP port 5353):
|
|
|
+
|
|
|
+ * This is not "just DNS". This is a DNS-like protocol, but
|
|
|
+ different.
|
|
|
+
|
|
|
+ * Changing resolver library code to use a different port number is
|
|
|
+ not hard. In some cases, this can be achieved without any code
|
|
|
+ changes, just by adding the address 224.0.0.251:5353 to a
|
|
|
+ configuration file.
|
|
|
+
|
|
|
+ * Using the same port number makes it hard to run a Multicast DNS
|
|
|
+ responder and a conventional Unicast DNS server on the same
|
|
|
+ machine. If a conventional Unicast DNS server wishes to implement
|
|
|
+ Multicast DNS as well, it can still do that, by opening two
|
|
|
+ sockets. Having two different port numbers allows this
|
|
|
+ flexibility.
|
|
|
+
|
|
|
+ * Some VPN software hijacks all outgoing traffic to port 53 and
|
|
|
+ redirects it to a special DNS server set up to serve those VPN
|
|
|
+ clients while they are connected to the corporate network. It is
|
|
|
+ questionable whether this is the right thing to do, but it is
|
|
|
+ common, and redirecting link-local multicast DNS packets to a
|
|
|
+ remote server rarely produces any useful results. It does mean,
|
|
|
+ for example, that a user of such VPN software becomes unable to
|
|
|
+ access their local network printer sitting on their desk right next
|
|
|
+ to their computer. Using a different UDP port helps avoid this
|
|
|
+ particular problem.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 60]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ * On many operating systems, unprivileged software may not send or
|
|
|
+ receive packets on low-numbered ports. This means that any
|
|
|
+ software sending or receiving Multicast DNS packets on port 53
|
|
|
+ would have to run as "root", which is an undesirable security risk.
|
|
|
+ Using a higher-numbered UDP port avoids this restriction.
|
|
|
+
|
|
|
+Appendix B. Design Rationale for Not Using Hashed Multicast Addresses
|
|
|
+
|
|
|
+ Some discovery protocols use a range of multicast addresses, and
|
|
|
+ determine the address to be used by a hash function of the name being
|
|
|
+ sought. Queries are sent via multicast to the address as indicated
|
|
|
+ by the hash function, and responses are returned to the querier via
|
|
|
+ unicast. Particularly in IPv6, where multicast addresses are
|
|
|
+ extremely plentiful, this approach is frequently advocated. For
|
|
|
+ example, IPv6 Neighbor Discovery [RFC4861] sends Neighbor
|
|
|
+ Solicitation messages to the "solicited-node multicast address",
|
|
|
+ which is computed as a function of the solicited IPv6 address.
|
|
|
+
|
|
|
+ There are some disadvantages to using hashed multicast addresses like
|
|
|
+ this in a service discovery protocol:
|
|
|
+
|
|
|
+ * When a host has a large number of records with different names, the
|
|
|
+ host may have to join a large number of multicast groups. Each
|
|
|
+ time a host joins or leaves a multicast group, this results in
|
|
|
+ Internet Group Management Protocol (IGMP) or Multicast Listener
|
|
|
+ Discovery (MLD) traffic on the network announcing this fact.
|
|
|
+ Joining a large number of multicast groups can place undue burden
|
|
|
+ on the Ethernet hardware, which typically supports a limited number
|
|
|
+ of multicast addresses efficiently. When this number is exceeded,
|
|
|
+ the Ethernet hardware may have to resort to receiving all
|
|
|
+ multicasts and passing them up to the host networking code for
|
|
|
+ filtering in software, thereby defeating much of the point of using
|
|
|
+ a multicast address range in the first place. Finally, many IPv6
|
|
|
+ stacks have a fixed limit IPV6_MAX_MEMBERSHIPS, and the code simply
|
|
|
+ fails with an error if a client attempts to exceed this limit.
|
|
|
+ Common values for IPV6_MAX_MEMBERSHIPS are 20 or 31.
|
|
|
+
|
|
|
+ * Multiple questions cannot be placed in one packet if they don't all
|
|
|
+ hash to the same multicast address.
|
|
|
+
|
|
|
+ * Duplicate Question Suppression doesn't work if queriers are not
|
|
|
+ seeing each other's queries.
|
|
|
+
|
|
|
+ * Duplicate Answer Suppression doesn't work if responders are not
|
|
|
+ seeing each other's responses.
|
|
|
+
|
|
|
+ * Opportunistic Caching doesn't work.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 61]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ * Ongoing Conflict Detection doesn't work.
|
|
|
+
|
|
|
+Appendix C. Design Rationale for Maximum Multicast DNS Name Length
|
|
|
+
|
|
|
+ Multicast DNS names may be up to 255 bytes long (in the on-the-wire
|
|
|
+ message format), not counting the terminating zero byte at the end.
|
|
|
+
|
|
|
+ "Domain Names - Implementation and Specification" [RFC1035] says:
|
|
|
+
|
|
|
+ Various objects and parameters in the DNS have size limits. They
|
|
|
+ are listed below. Some could be easily changed, others are more
|
|
|
+ fundamental.
|
|
|
+
|
|
|
+ labels 63 octets or less
|
|
|
+
|
|
|
+ names 255 octets or less
|
|
|
+
|
|
|
+ ...
|
|
|
+
|
|
|
+ the total length of a domain name (i.e., label octets and label
|
|
|
+ length octets) is restricted to 255 octets or less.
|
|
|
+
|
|
|
+ This text does not state whether this 255-byte limit includes the
|
|
|
+ terminating zero at the end of every name.
|
|
|
+
|
|
|
+ Several factors lead us to conclude that the 255-byte limit does
|
|
|
+ *not* include the terminating zero:
|
|
|
+
|
|
|
+ o It is common in software engineering to have size limits that are a
|
|
|
+ power of two, or a multiple of a power of two, for efficiency. For
|
|
|
+ example, an integer on a modern processor is typically 2, 4, or 8
|
|
|
+ bytes, not 3 or 5 bytes. The number 255 is not a power of two, nor
|
|
|
+ is it to most people a particularly noteworthy number. It is
|
|
|
+ noteworthy to computer scientists for only one reason -- because it
|
|
|
+ is exactly one *less* than a power of two. When a size limit is
|
|
|
+ exactly one less than a power of two, that suggests strongly that
|
|
|
+ the one extra byte is being reserved for some specific reason -- in
|
|
|
+ this case reserved, perhaps, to leave room for a terminating zero
|
|
|
+ at the end.
|
|
|
+
|
|
|
+ o In the case of DNS label lengths, the stated limit is 63 bytes. As
|
|
|
+ with the total name length, this limit is exactly one less than a
|
|
|
+ power of two. This label length limit also excludes the label
|
|
|
+ length byte at the start of every label. Including that extra
|
|
|
+ byte, a 63-byte label takes 64 bytes of space in memory or in a DNS
|
|
|
+ message.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 62]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ o It is common in software engineering for the semantic "length" of
|
|
|
+ an object to be one less than the number of bytes it takes to store
|
|
|
+ that object. For example, in C, strlen("foo") is 3, but
|
|
|
+ sizeof("foo") (which includes the terminating zero byte at the end)
|
|
|
+ is 4.
|
|
|
+
|
|
|
+ o The text describing the total length of a domain name mentions
|
|
|
+ explicitly that label length and data octets are included, but does
|
|
|
+ not mention the terminating zero at the end. The zero byte at the
|
|
|
+ end of a domain name is not a label length. Indeed, the value zero
|
|
|
+ is chosen as the terminating marker precisely because it is not a
|
|
|
+ legal length byte value -- DNS prohibits empty labels. For
|
|
|
+ example, a name like "bad..name." is not a valid domain name
|
|
|
+ because it contains a zero-length label in the middle, which cannot
|
|
|
+ be expressed in a DNS message, because software parsing the message
|
|
|
+ would misinterpret a zero label-length byte as being a zero "end of
|
|
|
+ name" marker instead.
|
|
|
+
|
|
|
+ Finally, "Clarifications to the DNS Specification" [RFC2181] offers
|
|
|
+ additional confirmation that, in the context of DNS specifications,
|
|
|
+ the stated "length" of a domain name does not include the terminating
|
|
|
+ zero byte at the end. That document refers to the root name, which
|
|
|
+ is typically written as "." and is represented in a DNS message by a
|
|
|
+ single lone zero byte (i.e., zero bytes of data plus a terminating
|
|
|
+ zero), as the "zero length full name":
|
|
|
+
|
|
|
+ The zero length full name is defined as representing the root of
|
|
|
+ the DNS tree, and is typically written and displayed as ".".
|
|
|
+
|
|
|
+ This wording supports the interpretation that, in a DNS context, when
|
|
|
+ talking about lengths of names, the terminating zero byte at the end
|
|
|
+ is not counted. If the root name (".") is considered to be zero
|
|
|
+ length, then to be consistent, the length (for example) of "org" has
|
|
|
+ to be 4 and the length of "ietf.org" has to be 9, as shown below:
|
|
|
+
|
|
|
+ ------
|
|
|
+ | 0x00 | length = 0
|
|
|
+ ------
|
|
|
+
|
|
|
+ ------------------ ------
|
|
|
+ | 0x03 | o | r | g | | 0x00 | length = 4
|
|
|
+ ------------------ ------
|
|
|
+
|
|
|
+ ----------------------------------------- ------
|
|
|
+ | 0x04 | i | e | t | f | 0x03 | o | r | g | | 0x00 | length = 9
|
|
|
+ ----------------------------------------- ------
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 63]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ This means that the maximum length of a domain name, as represented
|
|
|
+ in a Multicast DNS message, up to but not including the final
|
|
|
+ terminating zero, must not exceed 255 bytes.
|
|
|
+
|
|
|
+ However, many Unicast DNS implementers have read these RFCs
|
|
|
+ differently, and argue that the 255-byte limit does include the
|
|
|
+ terminating zero, and that the "Clarifications to the DNS
|
|
|
+ Specification" [RFC2181] statement that "." is the "zero length full
|
|
|
+ name" was simply a mistake.
|
|
|
+
|
|
|
+ Hence, implementers should be aware that other Unicast DNS
|
|
|
+ implementations may limit the maximum domain name to 254 bytes plus a
|
|
|
+ terminating zero, depending on how that implementer interpreted the
|
|
|
+ DNS specifications.
|
|
|
+
|
|
|
+ Compliant Multicast DNS implementations MUST support names up to 255
|
|
|
+ bytes plus a terminating zero, i.e., 256 bytes total.
|
|
|
+
|
|
|
+Appendix D. Benefits of Multicast Responses
|
|
|
+
|
|
|
+ Some people have argued that sending responses via multicast is
|
|
|
+ inefficient on the network. In fact, using multicast responses can
|
|
|
+ result in a net lowering of overall multicast traffic for a variety
|
|
|
+ of reasons, and provides other benefits too:
|
|
|
+
|
|
|
+ * Opportunistic Caching. One multicast response can update the
|
|
|
+ caches on all machines on the network. If another machine later
|
|
|
+ wants to issue the same query, and it already has the answer in its
|
|
|
+ cache, it may not need to even transmit that multicast query on the
|
|
|
+ network at all.
|
|
|
+
|
|
|
+ * Duplicate Query Suppression. When more than one machine has the
|
|
|
+ same ongoing long-lived query running, every machine does not have
|
|
|
+ to transmit its own independent query. When one machine transmits
|
|
|
+ a query, all the other hosts see the answers, so they can suppress
|
|
|
+ their own queries.
|
|
|
+
|
|
|
+ * Passive Observation Of Failures (POOF). When a host sees a
|
|
|
+ multicast query, but does not see the corresponding multicast
|
|
|
+ response, it can use this information to promptly delete stale data
|
|
|
+ from its cache. To achieve the same level of user-interface
|
|
|
+ quality and responsiveness without multicast responses would
|
|
|
+ require lower cache lifetimes and more frequent network polling,
|
|
|
+ resulting in a higher packet rate.
|
|
|
+
|
|
|
+ * Passive Conflict Detection. Just because a name has been
|
|
|
+ previously verified to be unique does not guarantee it will
|
|
|
+ continue to be so indefinitely. By allowing all Multicast DNS
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 64]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ responders to constantly monitor their peers' responses, conflicts
|
|
|
+ arising out of network topology changes can be promptly detected
|
|
|
+ and resolved. If responses were not sent via multicast, some other
|
|
|
+ conflict detection mechanism would be needed, imposing its own
|
|
|
+ additional burden on the network.
|
|
|
+
|
|
|
+ * Use on devices with constrained memory resources: When using
|
|
|
+ delayed responses to reduce network collisions, responders need to
|
|
|
+ maintain a list recording to whom each answer should be sent. The
|
|
|
+ option of multicast responses allows responders with limited
|
|
|
+ storage, which cannot store an arbitrarily long list of response
|
|
|
+ addresses, to choose to fail-over to a single multicast response in
|
|
|
+ place of multiple unicast responses, when appropriate.
|
|
|
+
|
|
|
+ * Overlayed Subnets. In the case of overlayed subnets, multicast
|
|
|
+ responses allow a receiver to know with certainty that a response
|
|
|
+ originated on the local link, even when its source address may
|
|
|
+ apparently suggest otherwise.
|
|
|
+
|
|
|
+ * Robustness in the face of misconfiguration: Link-local multicast
|
|
|
+ transcends virtually every conceivable network misconfiguration.
|
|
|
+ Even if you have a collection of devices where every device's IP
|
|
|
+ address, subnet mask, default gateway, and DNS server address are
|
|
|
+ all wrong, packets sent by any of those devices addressed to a
|
|
|
+ link-local multicast destination address will still be delivered to
|
|
|
+ all peers on the local link. This can be extremely helpful when
|
|
|
+ diagnosing and rectifying network problems, since it facilitates a
|
|
|
+ direct communication channel between client and server that works
|
|
|
+ without reliance on ARP, IP routing tables, etc. Being able to
|
|
|
+ discover what IP address a device has (or thinks it has) is
|
|
|
+ frequently a very valuable first step in diagnosing why it is
|
|
|
+ unable to communicate on the local network.
|
|
|
+
|
|
|
+Appendix E. Design Rationale for Encoding Negative Responses
|
|
|
+
|
|
|
+ Alternative methods of asserting nonexistence were considered, such
|
|
|
+ as using an NXDOMAIN response, or emitting a resource record with
|
|
|
+ zero-length rdata.
|
|
|
+
|
|
|
+ Using an NXDOMAIN response does not work well with Multicast DNS. A
|
|
|
+ Unicast DNS NXDOMAIN response applies to the entire message, but for
|
|
|
+ efficiency Multicast DNS allows (and encourages) multiple responses
|
|
|
+ in a single message. If the error code in the header were NXDOMAIN,
|
|
|
+ it would not be clear to which name(s) that error code applied.
|
|
|
+
|
|
|
+ Asserting nonexistence by emitting a resource record with zero-length
|
|
|
+ rdata would mean that there would be no way to differentiate between
|
|
|
+ a record that doesn't exist, and a record that does exist, with zero-
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 65]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ length rdata. By analogy, most file systems today allow empty files,
|
|
|
+ so a file that exists with zero bytes of data is not considered
|
|
|
+ equivalent to a filename that does not exist.
|
|
|
+
|
|
|
+ A benefit of asserting nonexistence through NSEC records instead of
|
|
|
+ through NXDOMAIN responses is that NSEC records can be added to the
|
|
|
+ Additional Section of a DNS response to offer additional information
|
|
|
+ beyond what the querier explicitly requested. For example, in
|
|
|
+ response to an SRV query, a responder should include A record(s)
|
|
|
+ giving its IPv4 addresses in the Additional Section, and an NSEC
|
|
|
+ record indicating which other types it does or does not have for this
|
|
|
+ name. If the responder is running on a host that does not support
|
|
|
+ IPv6 (or does support IPv6 but currently has no IPv6 address on that
|
|
|
+ interface) then this NSEC record in the Additional Section will
|
|
|
+ indicate this absence of AAAA records. In effect, the responder is
|
|
|
+ saying, "Here's my SRV record, and here are my IPv4 addresses, and
|
|
|
+ no, I don't have any IPv6 addresses, so don't waste your time
|
|
|
+ asking". Without this information in the Additional Section, it
|
|
|
+ would take the querier an additional round-trip to perform an
|
|
|
+ additional query to ascertain that the target host has no AAAA
|
|
|
+ records. (Arguably Unicast DNS could also benefit from this ability
|
|
|
+ to express nonexistence in the Additional Section, but that is
|
|
|
+ outside the scope of this document.)
|
|
|
+
|
|
|
+Appendix F. Use of UTF-8
|
|
|
+
|
|
|
+ After many years of debate, as a result of the perceived need to
|
|
|
+ accommodate certain DNS implementations that apparently couldn't
|
|
|
+ handle any character that's not a letter, digit, or hyphen (and
|
|
|
+ apparently never would be updated to remedy this limitation), the
|
|
|
+ Unicast DNS community settled on an extremely baroque encoding called
|
|
|
+ "Punycode" [RFC3492]. Punycode is a remarkably ingenious encoding
|
|
|
+ solution, but it is complicated, hard to understand, and hard to
|
|
|
+ implement, using sophisticated techniques including insertion unsort
|
|
|
+ coding, generalized variable-length integers, and bias adaptation.
|
|
|
+ The resulting encoding is remarkably compact given the constraints,
|
|
|
+ but it's still not as good as simple straightforward UTF-8, and it's
|
|
|
+ hard even to predict whether a given input string will encode to a
|
|
|
+ Punycode string that fits within DNS's 63-byte limit, except by
|
|
|
+ simply trying the encoding and seeing whether it fits. Indeed, the
|
|
|
+ encoded size depends not only on the input characters, but on the
|
|
|
+ order they appear, so the same set of characters may or may not
|
|
|
+ encode to a legal Punycode string that fits within DNS's 63-byte
|
|
|
+ limit, depending on the order the characters appear. This is
|
|
|
+ extremely hard to present in a user interface that explains to users
|
|
|
+ why one name is allowed, but another name containing the exact same
|
|
|
+ characters is not. Neither Punycode nor any other of the "ASCII-
|
|
|
+ Compatible Encodings" [RFC5890] proposed for Unicast DNS may be used
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 66]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ in Multicast DNS messages. Any text being represented internally in
|
|
|
+ some other representation must be converted to canonical precomposed
|
|
|
+ UTF-8 before being placed in any Multicast DNS message.
|
|
|
+
|
|
|
+Appendix G. Private DNS Namespaces
|
|
|
+
|
|
|
+ The special treatment of names ending in ".local." has been
|
|
|
+ implemented in Macintosh computers since the days of Mac OS 9, and
|
|
|
+ continues today in Mac OS X and iOS. There are also implementations
|
|
|
+ for Microsoft Windows [B4W], Linux, and other platforms.
|
|
|
+
|
|
|
+ Some network operators setting up private internal networks
|
|
|
+ ("intranets") have used unregistered top-level domains, and some may
|
|
|
+ have used the ".local" top-level domain. Using ".local" as a private
|
|
|
+ top-level domain conflicts with Multicast DNS and may cause problems
|
|
|
+ for users. Clients can be configured to send both Multicast and
|
|
|
+ Unicast DNS queries in parallel for these names, and this does allow
|
|
|
+ names to be looked up both ways, but this results in additional
|
|
|
+ network traffic and additional delays in name resolution, as well as
|
|
|
+ potentially creating user confusion when it is not clear whether any
|
|
|
+ given result was received via link-local multicast from a peer on the
|
|
|
+ same link, or from the configured unicast name server. Because of
|
|
|
+ this, we recommend against using ".local" as a private Unicast DNS
|
|
|
+ top-level domain. 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:
|
|
|
+
|
|
|
+ .intranet.
|
|
|
+ .internal.
|
|
|
+ .private.
|
|
|
+ .corp.
|
|
|
+ .home.
|
|
|
+ .lan.
|
|
|
+
|
|
|
+Appendix H. Deployment History
|
|
|
+
|
|
|
+ In July 1997, in an email to the net-thinkers@thumper.vmeng.com
|
|
|
+ mailing list, Stuart Cheshire first proposed the idea of running the
|
|
|
+ AppleTalk Name Binding Protocol [RFC6760] over IP. As a result of
|
|
|
+ this and related IETF discussions, the IETF Zeroconf working group
|
|
|
+ was chartered September 1999. After various working group
|
|
|
+ discussions and other informal IETF discussions, several Internet-
|
|
|
+ Drafts were written that were loosely related to the general themes
|
|
|
+ of DNS and multicast, but did not address the service discovery
|
|
|
+ aspect of NBP.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 67]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ In April 2000, Stuart Cheshire registered IPv4 multicast address
|
|
|
+ 224.0.0.251 with IANA [MC4] and began writing code to test and
|
|
|
+ develop the idea of performing NBP-like service discovery using
|
|
|
+ Multicast DNS, which was documented in a group of three Internet-
|
|
|
+ Drafts:
|
|
|
+
|
|
|
+ o "Requirements for a Protocol to Replace the AppleTalk Name Binding
|
|
|
+ Protocol (NBP)" [RFC6760] is an overview explaining the AppleTalk
|
|
|
+ Name Binding Protocol, because many in the IETF community had
|
|
|
+ little first-hand experience using AppleTalk, and confusion in the
|
|
|
+ IETF community about what AppleTalk NBP did was causing confusion
|
|
|
+ about what would be required in an IP-based replacement.
|
|
|
+
|
|
|
+ o "Discovering Named Instances of Abstract Services using DNS" [NIAS]
|
|
|
+ proposed a way to perform NBP-like service discovery using DNS-
|
|
|
+ compatible names and record types.
|
|
|
+
|
|
|
+ o "Multicast DNS" (this document) specifies a way to transport those
|
|
|
+ DNS-compatible queries and responses using IP multicast, for zero-
|
|
|
+ configuration environments where no conventional Unicast DNS server
|
|
|
+ was available.
|
|
|
+
|
|
|
+ In 2001, an update to Mac OS 9 added resolver library support for
|
|
|
+ host name lookup using Multicast DNS. If the user typed a name such
|
|
|
+ as "MyPrinter.local." into any piece of networking software that used
|
|
|
+ the standard Mac OS 9 name lookup APIs, then those name lookup APIs
|
|
|
+ would recognize the name as a dot-local name and query for it by
|
|
|
+ sending simple one-shot Multicast DNS queries to 224.0.0.251:5353.
|
|
|
+ This enabled the user to, for example, enter the name
|
|
|
+ "MyPrinter.local." into their web browser in order to view a
|
|
|
+ printer's status and configuration web page, or enter the name
|
|
|
+ "MyPrinter.local." into the printer setup utility to create a print
|
|
|
+ queue for printing documents on that printer.
|
|
|
+
|
|
|
+ Multicast DNS responder software, with full service discovery, first
|
|
|
+ began shipping to end users in volume with the launch of Mac OS X
|
|
|
+ 10.2 "Jaguar" in August 2002, and network printer makers (who had
|
|
|
+ historically supported AppleTalk in their network printers and were
|
|
|
+ receptive to IP-based technologies that could offer them similar
|
|
|
+ ease-of-use) started adopting Multicast DNS shortly thereafter.
|
|
|
+
|
|
|
+ In September 2002, Apple released the source code for the
|
|
|
+ mDNSResponder daemon as Open Source under Apple's standard Apple
|
|
|
+ Public Source License (APSL).
|
|
|
+
|
|
|
+ Multicast DNS responder software became available for Microsoft
|
|
|
+ Windows users in June 2004 with the launch of Apple's "Rendezvous for
|
|
|
+ Windows" (now "Bonjour for Windows"), both in executable form (a
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 68]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+ downloadable installer for end users) and as Open Source (one of the
|
|
|
+ supported platforms within Apple's body of cross-platform code in the
|
|
|
+ publicly accessible mDNSResponder CVS source code repository) [BJ].
|
|
|
+
|
|
|
+ In August 2006, Apple re-licensed the cross-platform mDNSResponder
|
|
|
+ source code under the Apache License, Version 2.0.
|
|
|
+
|
|
|
+ In addition to desktop and laptop computers running Mac OS X and
|
|
|
+ Microsoft Windows, Multicast DNS is now implemented in a wide range
|
|
|
+ of hardware devices, such as Apple's "AirPort" wireless base
|
|
|
+ stations, iPhone and iPad, and in home gateways from other vendors,
|
|
|
+ network printers, network cameras, TiVo DVRs, etc.
|
|
|
+
|
|
|
+ The Open Source community has produced many independent
|
|
|
+ implementations of Multicast DNS, some in C like Apple's
|
|
|
+ mDNSResponder daemon, and others in a variety of different languages
|
|
|
+ including Java, Python, Perl, and C#/Mono.
|
|
|
+
|
|
|
+ In January 2007, the IETF published the Informational RFC "Link-Local
|
|
|
+ Multicast Name Resolution (LLMNR)" [RFC4795], which is substantially
|
|
|
+ similar to Multicast DNS, but incompatible in some small but
|
|
|
+ important ways. In particular, the LLMNR design explicitly excluded
|
|
|
+ support for service discovery, which made it an unsuitable candidate
|
|
|
+ for a protocol to replace AppleTalk NBP [RFC6760].
|
|
|
+
|
|
|
+ While the original focus of Multicast DNS and DNS-Based Service
|
|
|
+ Discovery was for zero-configuration environments without a
|
|
|
+ conventional Unicast DNS server, DNS-Based Service Discovery also
|
|
|
+ works using Unicast DNS servers, using DNS Update [RFC2136] [RFC3007]
|
|
|
+ to create service discovery records and standard DNS queries to query
|
|
|
+ for them. Apple's Back to My Mac service, launched with Mac OS X
|
|
|
+ 10.5 "Leopard" in October 2007, uses DNS-Based Service Discovery over
|
|
|
+ Unicast DNS [RFC6281].
|
|
|
+
|
|
|
+ In June 2012, Google's Android operating system added native support
|
|
|
+ for DNS-SD and Multicast DNS with the android.net.nsd.NsdManager
|
|
|
+ class in Android 4.1 "Jelly Bean" (API Level 16) [NSD].
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 69]
|
|
|
+
|
|
|
+RFC 6762 Multicast DNS February 2013
|
|
|
+
|
|
|
+
|
|
|
+Authors' Addresses
|
|
|
+
|
|
|
+ Stuart Cheshire
|
|
|
+ Apple Inc.
|
|
|
+ 1 Infinite Loop
|
|
|
+ Cupertino, CA 95014
|
|
|
+ USA
|
|
|
+
|
|
|
+ Phone: +1 408 974 3207
|
|
|
+ EMail: cheshire@apple.com
|
|
|
+
|
|
|
+
|
|
|
+ Marc Krochmal
|
|
|
+ Apple Inc.
|
|
|
+ 1 Infinite Loop
|
|
|
+ Cupertino, CA 95014
|
|
|
+ USA
|
|
|
+
|
|
|
+ Phone: +1 408 974 4368
|
|
|
+ EMail: marc@apple.com
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Cheshire & Krochmal Standards Track [Page 70]
|
|
|
+
|