--- /dev/null
+Document: draft-cheshire-dnsext-multicastdns-04.txt Stuart Cheshire
+Category: Standards Track Apple Computer, Inc.
+Expires 14th August 2004 Marc Krochmal
+ Apple Computer, Inc.
+ 14th February 2004
+
+ Multicast DNS
+
+ <draft-cheshire-dnsext-multicastdns-04.txt>
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF),
+ its areas, and its working groups. Note that other groups may
+ also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other documents
+ at any time. It is inappropriate to use Internet-Drafts as
+ reference material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+ Distribution of this memo is unlimited.
+
+
+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 becoming essential.
+
+ Multicast DNS (mDNS) provides the ability to do DNS-like operations
+ on the local link in the absense of any conventional unicast DNS
+ server. In addition, mDNS 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 mDNS 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.
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 1]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+Table of Contents
+
+ 1. Introduction...................................................3
+ 2. Conventions and Terminology Used in this Document..............4
+ 3. Multicast DNS Names............................................4
+ 4. IP TTL Checks..................................................8
+ 5. Reverse Address Mapping........................................8
+ 6. Querying.......................................................9
+ 7. Duplicate Suppression.........................................13
+ 8. Responding....................................................15
+ 9. Probing and Announcing on Startup.............................17
+ 10. Conflict Resolution...........................................21
+ 11. Special Characteristics of Multicast DNS Domains..............23
+ 12. Multicast DNS for Service Discovery...........................24
+ 13. Resource Record TTL Values and Cache Coherency................25
+ 14. Enabling and Disabling Multicast DNS..........................30
+ 15. Considerations for Multiple Interfaces........................30
+ 16. Multicast DNS and Power Management............................31
+ 17. Multicast DNS Character Set...................................32
+ 18. Multicast DNS Message Size....................................33
+ 19. Multicast DNS Message Format..................................33
+ 20. Choice of UDP Port Number.....................................36
+ 21. Summary of Differences Between Multicast DNS and Unicast DNS..37
+ 22. Benefits of Multicast Responses...............................38
+ 23. IPv6 Considerations...........................................39
+ 24. Security Considerations.......................................40
+ 25. IANA Considerations...........................................41
+ 26. Acknowledgements..............................................41
+ 27. Copyright.....................................................41
+ 28. Normative References..........................................42
+ 29. Informative References........................................42
+ 30. Author's Addresses............................................43
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 2]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+1. Introduction
+
+ When reading this document, familiarity with the concepts of Zero
+ Configuration Networking [ZC] and automatic link-local addressing
+ [v4LL] [RFC 2462] is helpful.
+
+ This document proposes no change to the structure of DNS messages,
+ and no new operation codes, response codes, or resource record types.
+ This document simply discusses what needs to happen if DNS clients
+ start sending DNS queries to a multicast address, and how a
+ collection of hosts can cooperate to collectively answer those
+ queries in a useful manner.
+
+ There has been discussion of how much burden Multicast DNS might
+ impose on a network. It should be remembered that whenever IPv4 hosts
+ communicate, they broadcast ARP packets on the network on a regular
+ basis, and this is not disastrous. The approximate amount of
+ multicast traffic generated by hosts making conventional use of
+ Multicast DNS is anticipated to be roughly the same order of
+ magnitude as the amount of broadcast ARP traffic those hosts already
+ generate.
+
+ New applications making new use of Multicast DNS capabilities for
+ unconventional purposes may generate more traffic. If some of those
+ new applications are "chatty", then work will be needed to help them
+ become less chatty. When performing any analysis, it is important to
+ make a distinction between the application behavior and the
+ underlying protocol behavior. If a chatty application uses UDP, that
+ doesn't mean that UDP is chatty, or that IP is chatty, or that
+ Ethernet is chatty. What it means is that the application is chatty.
+ The same applies to any future applications that may decide to layer
+ increasing portions of their functionality over Multicast DNS.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 3]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+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" [RFC 2119].
+
+ This document uses the term "host name" in the strict sense to mean a
+ fully qualified domain name that has an 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 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.
+
+ In any place where there may be potential confusion between these two
+ types of TTL, the term "IP TTL" is used to refer to the IP header TTL
+ (hop limit), and the term "RR TTL" is used to refer to the Resource
+ Record TTL (cache lifetime).
+
+ 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 packets over IP
+ Multicast to UDP port 5353."
+
+
+3. Multicast DNS Names
+
+ This document proposes that the DNS top-level domain ".local." be
+ designated 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, 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 multicast address (224.0.0.251 or its IPv6 equivalent
+ FF02::FB).
+
+ 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 in a DHCP option, or via
+ any other valid mechanism for configuring the DNS search list. In
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 4]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ this respect the ".local." suffix is treated no differently to any
+ other search domain that might appear in the DNS search list.
+
+ 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 which disrupt communication with the greater
+ Internet. When resolving global names via local multicast, it is even
+ more important to use DNSSEC 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 in detail, instead concentrating on the issue of resolving local
+ names using DNS packets sent to a multicast address.
+
+ A host which 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, for example,
+ "cheshire.apple.com." For those of us who have this luxury, this
+ works very well. However, the majority of home customers do not have
+ easy access to any portion of the global DNS namespace within which
+ they have the authority to create names as they wish. This leaves the
+ majority of home computers effectively anonymous for practical
+ purposes.
+
+ 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, my Titanium
+ PowerBook laptop computer answers to the name "sctibook.local." Any
+ computer user is granted the authority to name their computer this
+ way, providing 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 using that name until such time as a name
+ conflict occurs on the link which is not resolved in the user's
+ favour. If this happens, the computer (or its human user) SHOULD
+ cease using the name, and may choose to attempt to allocate a new
+ unique name for use on that link. Like law suits over global DNS
+ names, 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.
+
+ The point made in the previous paragraph is very important and bears
+ repeating. It is easy for those of us in the IETF community who run
+ our own name servers at home to forget that the majority of computer
+ users do not run their own name server and have no easy way to create
+ their own host names. When these users wish to transfer files between
+ two laptop computers, they are frequently reduced to typing in
+ dotted-decimal IP addresses because they simply have no other way for
+ one host to refer to the other by name. This is a sorry state of
+ affairs. What is worse, most users don't even bother trying to use
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 5]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ dotted-decimal IP addresses. Most users still move data between
+ machines by copying it onto a floppy disk or similar removable media.
+
+ In a world of gigabit Ethernet and ubiquitous wireless networking it
+ is a sad indictment of the networking community that the preferred
+ communication medium for most computer users is still the floppy
+ disk.
+
+ Allowing ad-hoc allocation of single-label names in a single flat
+ ".local." namespace may seem to invite chaos. However, operational
+ experience with AppleTalk NBP names [NBP], which on any given link
+ are also effectively single-label names in a flat namespace, shows
+ that in practice name collisions happen extremely rarely and are not
+ a problem. Groups of computer users from disparate organizations
+ bring Macintosh laptop computers to events such as IETF Meetings, the
+ Mac Hack conference, the Apple World Wide Developer Conference, etc.,
+ and complaints at these events about users suffering conflicts and
+ being forced to rename their machines have never been an issue.
+
+ Enforcing uniqueness of host names (i.e. the names of DNS address
+ records mapping names to IP addresses) 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 are supported. The Multicast DNS protocol
+ allows hosts to verify and maintain unique names for resource records
+ where that behaviour is desired, and it also allows hosts to maintain
+ multiple resource records with a single shared name where that
+ behaviour 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.
+
+
+3.1 Governing Standards Body
+
+ Note that this use of the ".local." suffix falls under IETF
+ jurisdiction, not ICANN jurisdiction. DNS is an IETF network
+ protocol, governed by protocol rules defined by the IETF. These IETF
+ protocol rules dictate character set, maximum name length, packet
+ format, etc. ICANN determines additional rules that apply when the
+ IETF's DNS protocol is used on the public Internet. In contrast,
+ private uses of the DNS protocol on isolated private networks are not
+ governed by ICANN. Since this proposed change is a change to the core
+ DNS protocol rules, it affects everyone, not just those machines
+ using the ICANN-governed Internet. Hence this change falls into the
+ category of an IETF protocol rule, not an ICANN usage rule.
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 6]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+3.2 Private DNS Namespaces
+
+ Note also that 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. There are also implementations for
+ Linux and other platforms [dotlocal]. Operators setting up private
+ internal networks ("intranets") are advised that their lives may be
+ easier if they avoid using the suffix ".local." in names in their
+ private internal DNS server. Alternative possibilities include:
+
+ .intranet
+ .internal
+ .private
+ .corp
+ .home
+
+ Another alternative naming scheme, advocated by Professor D. J.
+ Bernstein, is to use a numerical suffix, such as ".6." [djbdl].
+
+
+3.3 Maximum Multicast DNS Name Length
+
+ RFC 1034 says:
+
+ "the total number of octets that represent a domain name (i.e.,
+ the sum of all label octets and label lengths) is limited to 255."
+
+ This text implies that the final root label at the end of every name
+ is included in this count (a name can't be represented without it),
+ but the text does not explicitly state that. Implementations of
+ Multicast DNS MUST include the label length byte of the final root
+ label at the end of every name when enforcing the rule that no name
+ may be longer than 255 bytes. For example, the length of the name
+ "apple.com." is considered to be 11, which is the number of bytes it
+ takes to represent that name in a packet without using name
+ compression:
+
+ ------------------------------------------------------
+ | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 |
+ ------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 7]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+4. IP TTL Checks
+
+ All Multicast DNS responses (including responses sent via unicast)
+ MUST be sent with IP TTL set to 255.
+
+ A host sending Multicast DNS queries to a link-local destination
+ address (including the 224.0.0.251 link-local multicast address) MUST
+ verify that the IP TTL in response packets is 255, and silently
+ discard any response packets where the IP TTL is not 255. 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.
+
+ The authors have heard complaints that some older network stack
+ implementations do not implement the IP_RECVTTL socket option
+ (or equivalent API) for obtaining the IP TTL of received packets.
+ This is unfortunate, and these old network stacks would benefit
+ from adding this API support so that they may benefit from this
+ enhanced protection against spoof packets arriving from off-link.
+
+ Note that Multicast DNS Responders SHOULD NOT discard queries with
+ TTLs other than 255. There may be valid future applications of
+ Multicast DNS where hosts issue unicast queries directed at Multicast
+ DNS Responders more than one hop away, if Multicast DNS Responders
+ were to discard queries where the TTL is not 255, they would not
+ answer these queries.
+
+
+5. 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 multicast address 224.0.0.251. 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. As an optimization, these queries MAY be first
+ unicast directly to the address in question, but if this query is not
+ answered, the query MUST also be sent via multicast, to accommodate
+ the case where the machine in question is not answering for itself
+ (for example, because it is currently sleeping).
+
+ Likewise, any DNS query for a name ending with "0.8.e.f.ip6.arpa."
+ MUST be sent to the IPv6 mDNS link-local multicast address FF02::FB,
+ with or without an optional initial query unicast directly to the
+ address in question.
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 8]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+6. Querying
+
+ There are three kinds of Multicast DNS Queries, one-shot queries of
+ the kind made by today's conventional DNS clients, one-shot queries
+ accumulating multiple responses made by multicast-aware DNS clients,
+ and continuous ongoing Multicast DNS Queries used by IP network
+ browser software.
+
+ A Multicast DNS Responder that is offering records that are intended
+ to be unique on the local link 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.
+
+
+6.1 One-Shot Queries
+
+ An unsophisticated DNS client may simply send its DNS queries
+ blindly to the 224.0.0.251 multicast address, without necessarily
+ even being aware what a multicast address is.
+
+ Such an unsophisticated DNS client may not get ideal behaviour. Such
+ a client may simply take the first response it receives and fail to
+ wait to see if there are more, but in many instances this may not be
+ a serious problem. If a user types "http://stu.local." into their Web
+ browser and gets to see the page they were hoping for, then the
+ protocol has met the user's needs in this case.
+
+
+6.2 One-Shot Queries, Accumulating Multiple Responses
+
+ A more sophisticated DNS client should understand that Multicast DNS
+ is not exactly the same as unicast DNS, and should modify its
+ behaviour in some simple ways.
+
+ As described above, there are some cases, such as looking up the
+ address associated with a unique host name, where a single response
+ is sufficient, and moreover may be all that is expected. However,
+ there are other DNS queries where more than one response is
+ possible, and for these queries a more sophisticated Multicast DNS
+ client should include the ability to wait for an appropriate period
+ of time to collect multiple responses.
+
+ A naive DNS client retransmits its query only so long as it has
+ received no response. A more sophisticated Multicast DNS client is
+ aware that having received one response is not necessarily an
+ indication that it might not receive others, and has the ability to
+ retransmit its query an appropriate number of times at appropriate
+ intervals until it is satisfied with the collection of responses it
+ has gathered.
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 9]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ A more sophisticated Multicast DNS client that is retransmitting
+ a query for which it has already received some responses, MUST
+ implement Known Answer Suppression, as described below in Section
+ 7.1. This indicates to responders who have already replied that their
+ responses have been received, and they don't need to send them again
+ in response to this repeated query. In addition, the interval between
+ the first two queries MUST be at least one second, and the
+ intervals between subsequent queries MUST double.
+
+
+6.3 Continuous Querying
+
+ In One-Shot Queries, with either a single or multiple responses,
+ the underlying assumption is that the transaction begins when the
+ application issues a query, and ends when all the desired responses
+ have been received. There is another type of operation which is more
+ akin to continuous monitoring.
+
+ Macintosh users are accustomed to opening the "Chooser" window,
+ selecting a desired printer, and then closing the Chooser window.
+ However, when the desired printer does not appear in the list, the
+ user will typically leave the "Chooser" window open while they go and
+ check to verify that the printer is plugged in, powered on, connected
+ to the Ethernet, etc. While the user jiggles the wires, hits the
+ Ethernet hub, and so forth, they keep an eye on the Chooser window,
+ and when the printer name appears, they know they have fixed whatever
+ the problem was. This can be a useful and intuitive troubleshooting
+ technique, but a user who goes home for the weekend leaving the
+ Chooser window open places a non-trivial burden on the network.
+
+ With continuous querying, multiple queries are sent over a long
+ period of time, until the user terminates the operation. It is
+ important that an IP network browser window displaying live
+ information from the network using Multicast DNS, if left running for
+ an extended period of time, should generate significantly less
+ multicast traffic on the network than the old AppleTalk Chooser.
+ Therefore, the interval between the first two queries MUST be at
+ least one second, the intervals between subsequent queries MUST
+ double, and the querier MUST implement Known Answer Suppression, as
+ described below in Section 7.1.
+
+ 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 this time is reached, a
+ Multicast DNS Querier with an ongoing interest in that record SHOULD
+ re-issue its query to determine whether the record is still valid,
+ and if so update its expiry time.
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 10]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ To perform this cache maintenance, a Multicast DNS 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 after four queries no answer is
+ received, the record is deleted when it reaches 100% of its lifetime.
+
+ 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.
+
+
+6.4 Multiple Questions per Query
+
+ Multicast DNS allows a querier to place multiple questions in the
+ question section of a single Multicast DNS query packet.
+
+ The semantics of a Multicast DNS query packet containing multiple
+ questions is identical to a series of individual DNS query packets
+ containing one question each. Combining multiple questions into a
+ single packet is purely an efficiency optimization, and has no other
+ semantic significance.
+
+ A useful technique for adaptively combining multiple questions into a
+ single query is to use a Nagle-style algorithm: When a client issues
+ its first question, a Query packet is immediately built and sent,
+ without delay. If the client then continues issuing a rapid series of
+ questions they are held until either the first query receives at
+ least one answer, or 100ms has passed, or there are enough questions
+ to fill the question section of a Multicast DNS query packet. At this
+ time, all the held questions are placed into a Multicast DNS query
+ packet and sent.
+
+
+6.5 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, and
+ can 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. One example is a laptop
+ computer waking from sleep. At that instant it is a brand new
+ participant on a new network. Its Multicast DNS cache is empty, and
+ it has no knowledge of its surroundings. It may have a significant
+ number of queries 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
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 11]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ just seconds ago. In this case, trigging a large sudden flood of
+ multicast responses may impose an unreasonable burden on the network.
+ To avoid this, the Multicast DNS Querier SHOULD set the top bit in
+ the class field of its DNS question(s), to indicate that it is
+ willing to accept unicast responses instead of 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).
+
+ When retransmitting a question more than once, the 'unicast response'
+ bit SHOULD be set only for the first question of the series. After
+ the first question has received its responses, the querier should
+ have a large known-answer list (see "Known Answer Suppression" below)
+ 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 "Benefits of Multicast Responses" below).
+
+ When receiving a question with the 'unicast response' bit set, a
+ responder SHOULD usually respond with a unicast packet directed back
+ to the querier. 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.
+
+
+6.6 Suppressing Initial Query
+
+ If a query is issued for which there already exist one or more
+ records in the local cache, and those record(s) were received with
+ the cache flush bit set, indicating that they form a unique RRSet,
+ then the host SHOULD suppress its initial "QU" query, and proceed to
+ issue a "QM" query. To avoid the situation where a group of hosts
+ are synchronized by some external event and all perform the same
+ query simultaneously, a host suppressing its initial "QU" query
+ SHOULD impose a random delay from 500-1000ms before transmitting its
+ first "QM" query for this question. This means that when the first
+ host (selected randomly by this algorithm) transmits its "QM" query,
+ all the other hosts that were about to transmit the same query can
+ suppress their superfluous query, as described in "Duplicate
+ Question Suppression" below.
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 12]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+7. Duplicate Suppression
+
+ A variety of techniques are used to reduce the amount of redundant
+ 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 message with
+ those answers.
+
+ A Multicast DNS Responder SHOULD 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 their original TTL. Doing so would simply consume space in the
+ packet without achieving the goal of suppressing responses, and would
+ therefore be a pointless waste of network bandwidth.
+
+ 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 Multi-Packet 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 should then set the TC
+ (Truncated) bit in the header before sending the Query. It should
+ then immediately follow the packet with another query 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
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 13]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ 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 20-120ms. This gives the Multicast DNS Querier time to
+ send additional Known Answer packets before the Responder responds.
+ If the Responder sees any of its answers listed in the Known Answer
+ lists of subsequent packets from the querying host, it should delete
+ that answer from the list of answers it is planning to give, provided
+ that no other host on the network is also waiting to receive the same
+ answer record.
+
+
+7.3 Duplicate Question Suppression
+
+ If a host is planning to send a query, and it sees another host on
+ the network send a query containing the same question, and the Known
+ Answer section of that query does not contain any records which 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
+ clients 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 packet 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. When multiple responders on the network have the same data,
+ there is no need for all of them to respond.
+
+ This feature is particularly useful when multiple Sleep Proxy Servers
+ are deployed (see Section 16. "Multicast DNS and Power Management").
+ In the future it is possible that every general-purpose OS (Mac,
+ Windows, Linux, etc.) will implement Sleep Proxy Service as a matter
+ of course. In this case there could be a large number of Sleep Proxy
+ Servers on any given network, which is good for reliability and
+ fault-tolerance, but would be bad for the network if every Sleep
+ Proxy Server were to answer every query.
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 14]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+8. Responding
+
+ A Multicast DNS Responder MUST only respond when it has a positive
+ non-null response to send. Error responses must never be sent. The
+ non-existence of any name in a Multicast DNS Domain is ascertained by
+ the failure of any machine to respond to the Multicast DNS query, not
+ by NXDOMAIN errors.
+
+ 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 [IEEE802] and similar shared
+ multiple access networks SHOULD delay its responses by a random
+ amount of time selected with uniform random distribution in the range
+ 20-120ms. If multiple 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. 120ms is a short enough time that
+ it is almost imperceptible to a human user, but long enough to
+ significantly reduce the risk of Ethernet collisions. 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 10Mb/s
+ Ethernet, this equates to a vulnerable time window of 25.6us.
+
+ In the case where a Multicast DNS Responder has good reason to
+ believe that it will be the only responder on the link with a
+ positive non-null response, it SHOULD NOT impose the random delay
+ before responding, and SHOULD normally generate its response within
+ 10ms. To do this safely, it MUST have previously verified that the
+ requested name, type and class in the DNS query are unique on this
+ link. Responding immediately without delay is appropriate for things
+ like looking up the address record for a particular host name, when
+ the host name has been previously verified unique. Responding
+ immediately without delay is *not* appropriate for things like
+ looking up PTR records used for DNS Service Discovery [DNS-SD], where
+ a large number of responses may be anticipated.
+
+ Except when a unicast reply has been explicitly requested via the
+ "unicast reply" bit, Multicast DNS Responses MUST be sent to UDP port
+ 5353 (the well-known port assigned to mDNS) on the 224.0.0.251
+ multicast address (or its IPv6 equivalent FF02::FB). Operating in a
+ Zeroconf environment requires constant vigilance. Just because a name
+ has been previously verified unique does not mean it will continue to
+ be so indefinitely. By allowing all Multicast DNS Responders to
+ constantly monitor their peers' responses, conflicts arising out of
+ network topology changes can be promptly detected and resolved.
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 15]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ Sending all responses by multicast also facilitates opportunistic
+ caching by other hosts on the network.
+
+ To protect the network against excessive packet flooding due to
+ software bugs or malicious attack, a Multicast DNS Responder MUST NOT
+ multicast a given record on a given interface if it has previously
+ multicast that record on that interface within the last second. A
+ legitimate client on the network should have seen the previous
+ transmission and cached it. A client that did not receive and cache
+ the previous transmission will retry its request and receive a
+ subsequent response. Under no circumstances is there any legitimate
+ reason for a Multicast DNS Responder to multicast a given record more
+ than once per second on any given interface.
+
+
+8.1 Legacy Unicast Responses
+
+ If the source UDP port in a received Multicast DNS Query is not port
+ 5353, this indicates that the client originating the query is a
+ simple client that does not fully implement all of Multicast DNS. In
+ this case, the Multicast DNS Responder MUST send a UDP response
+ directly back to the client, 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 packet.
+
+ The resource record TTL given in a 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 13 to update and invalidate stale
+ data. Were unicast responses sent to legacy clients to use the same
+ high TTLs, these legacy clients, which do not implement these cache
+ coherency mechanisms, could retain stale cached resource record data
+ long after it is no longer valid.
+
+ Having sent this unicast response, if the Responder has not sent this
+ record in any multicast response recently, it SHOULD schedule the
+ record to be sent via multicast as well, to facilitate passive
+ conflict detection. "Recently" in this context means "if the time
+ since the record was last sent via multicast is less than one quarter
+ of the record's TTL".
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 16]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+8.2 Multi-Question Queries
+
+ Multicast DNS Responders MUST correctly handle DNS query packets
+ containing more than one question, by answering any or all of the
+ questions to which they have answers. Any answers generated
+ in response to query packets containing more than one question
+ MUST be randomly delayed in the range 20-120ms, as described above.
+
+
+8.3 Response Aggregation
+
+ Having delayed one or more multicast responses by 20-120ms as
+ described above in Section 8 "Responding", a Multicast DNS Responder
+ SHOULD, for the sake of network efficiency, aggregate as many of its
+ pending responses as possible into a single Multicast DNS response
+ packet.
+
+
+9. 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 an Ethernet "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.
+
+
+9.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
+ its address record which maps its unique host name to its unique IP
+ address. All Probe Queries SHOULD be done using the desired resource
+ record name and query type T_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, 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 HINFO record for that name.
+
+ 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 packet
+ for all of its resource records instead of needing a separate packet
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 17]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ for each. For example, a host can simultaneously probe for uniqueness
+ of its "A" record and all its SRV records [DNS-SD] in the same query
+ packet.
+
+ When ready to send its mDNS probe packet(s) the host should first
+ wait for a short random delay time, uniformly distributed in the
+ range 0-250ms. This random delay is to guard against the case where a
+ group of devices are powered on simultaneously, or a group of 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.
+
+ 250ms after the first query the host should send a second, then
+ 250ms after that a third. If, by 250ms after the third probe, no
+ conflicting Multicast DNS responses have been received, the host may
+ move to the next step, announcing.
+
+ If any conflicting Multicast DNS responses are received, then the
+ probing host MUST defer to the existing host, and must choose new
+ names for some or all of its resource records as appropriate, to
+ avoid conflict with pre-existing hosts on the network. In the case
+ of a host probing using query type T_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 ten failures 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.
+
+
+9.2 Simultaneous Probe Tie-Breaking
+
+ 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 Authority Section of its queries with records giving
+ 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 Update section of a DNS Update packet [RFC 2136].
+
+ 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 there which answers the query,
+ then it compares the data of that resource record with its own
+ tentative data. The lexicographically later data wins. This means
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 18]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ 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 treats this exactly
+ as if it had received a positive answer to its query, and concludes
+ that it may not use the desired name.
+
+ The determination of 'lexicographically later' is performed by first
+ comparing the record class, 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 type and class both match then the
+ rdata is compared.
+
+ In the case of resource records containing rdata that is subject to
+ name compression, 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:
+
+ sctibook.local. A 196.254.100.200
+ sctibook.local. A 196.254.200.100
+
+ In this case 196.254.200.100 is lexicographically later, so it is
+ deemed the winner.
+
+ Note that it is vital that the bytes are interpreted as UNSIGNED
+ values, or the wrong outcome may result. In the example above, if
+ the byte with value 200 had been incorrectly interpreted as a
+ signed value then it would be interpreted as value -56, and the
+ wrong address record would be deemed the winner.
+
+
+9.3 Announcing
+
+ The second startup step is that the Multicast DNS Responder MUST send
+ a gratuitous Multicast DNS Response containing, in the Answer
+ Section, all of its resource records. If there are too many resource
+ records to fit in a single packet, multiple packets should be used.
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 19]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ In the case of shared records (e.g. the PTR records used by DNS
+ Service Discovery [DNS-SD]), 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 is the mDNS "cache flush" bit and
+ is discussed in more detail below in Section 13.3 "Announcements to
+ Flush Outdated Cache Entries".
+
+ The Multicast DNS Responder MUST send at least two gratuitous
+ responses, one second apart. A Responder MAY send up to ten
+ gratuitous Responses, providing that the interval between gratuitous
+ responses doubles with every response sent.
+
+ A Multicast DNS Responder SHOULD NOT continue sending gratuitous
+ Responses for longer than the TTL of the record. The purpose of
+ announcing new records via gratuitous Responses is to ensure that
+ peer caches are up to date. After a time interval equal to the TTL of
+ the record has passed, it is very likely that old stale copies of
+ that record in peer caches will have expired naturally, so subsequent
+ announcements serve little purpose.
+
+ Whenever a Multicast DNS Responder receives any Multicast DNS
+ response (gratuitous or otherwise) containing a conflicting resource
+ record, the conflict MUST be resolved as described below in "Conflict
+ Resolution".
+
+ 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.
+
+
+9.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 neighbouring caches. For example, if any of a host's IP
+ addresses change, it must re-announce those address records.
+
+ 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 Multicast DNS may not be
+ the appropriate protocol to disseminate that information.
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 20]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+10. Conflict Resolution
+
+ A conflict occurs when two resource records with the same name, type
+ and class have 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. 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 (gratuitous or otherwise) containing a conflicting resource
+ record, the Multicast DNS Responder MUST immediately reset that
+ record to probing state, and go through the startup steps described
+ above in Section 9. "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 that observes an apparent conflict
+ MUST take action. 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 is obtained.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 21]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ The recommended course of action after probing and failing is as
+ follows:
+
+ o 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, appending the
+ digit "2" to the name, or incrementing a number at the end of the
+ name if one is already present.
+
+ o Probe again, and repeat until a unique name is found.
+
+ o Record this newly chosen name in persistent storage so that the
+ device will use the same name the next time it is power-cycled.
+
+ o 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 iTunes music
+ server on the network. Your music has been renamed to
+ "Bob's Music (G4 Cube)". If you want to change this name,
+ use [describe appropriate menu item or preference dialog].
+
+ How the user or operator is informed 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 other error conditions. On the other hand a headless
+ server in the closet may not inform the user at all -- if the user
+ cares, 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.
+
+ The examples in this section focus on address records (i.e. host
+ names), but the same considerations apply to all resource records
+ where uniqueness (or maintenance of some other defined constraint) is
+ desired.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 22]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+11. Special Characteristics of Multicast DNS Domains
+
+ Unlike conventional DNS names, names that end in ".local.",
+ "254.169.in-addr.arpa." or "0.8.e.f.ip6.arpa." have only local
+ significance. Conventional 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. (However, split views, firewalls, intranets and
+ the like have somewhat interfered with this goal of DNS representing
+ a single universal truth.) In contrast, each IP link has its own
+ private ".local.", "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa."
+ namespaces, and the answer to any query for a name within those
+ domains depends on where that query is asked.
+
+ Multicast DNS Domains are not delegated from their parent domain via
+ use of NS records. There are no NS records anywhere in Multicast DNS
+ Domains. Instead, all Multicast DNS Domains are delegated to the IP
+ addresses 224.0.0.251 and FF02::FB by virtue of the individual
+ organizations producing DNS client software deciding how to handle
+ those names. It would be extremely valuable for the industry if this
+ special handling were ratified and recorded by IANA, since otherwise
+ the special handling provided by each vendor is likely to be
+ inconsistent.
+
+ The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The
+ IPv6 name server 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.
+
+ No delegation is performed within Multicast DNS Domains. Because the
+ cluster of loosely coordinated CPUs is cooperating to administer a
+ single zone, delegation is neither necessary nor desirable. 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."
+
+ Multicast DNS Zones have no SOA 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
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 23]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ 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.
+
+
+12. Multicast DNS for Service Discovery
+
+ This document does not describe using Multicast DNS for network
+ browsing or service discovery. However, the mechanisms this document
+ describes are compatible with (and support) the browsing and service
+ discovery mechanisms proposed in "DNS-Based Service Discovery"
+ [DNS-SD].
+
+ This document places few limitations on what DNS record types may be
+ looked up using local multicast. One particular kind of Multicast DNS
+ query that might be useful is a query for the SRV record named
+ "_domain._udp.local.", yielding the port number and IP address of a
+ conventional DNS server willing to perform general recursive DNS
+ lookups. This could solve a particular problem facing the IPv6
+ community, which is that IPv6 is able to self-configure almost all of
+ the information it needs to operate [RFC 2462], except for the
+ address of the DNS server. Bringing in all of the mechanisms of DHCP
+ just for that one little additional piece of information is not an
+ attractive solution. Using DNS-format messages and DNS-format
+ resource records to find the address of the DNS server has an elegant
+ self-sufficiency about it. Any host that needs to know the address of
+ the DNS server must already have code to generate and parse DNS
+ packets, so using that same code and those same packets to find the
+ DNS server in the first place is a simple self-reliant solution that
+ avoids taking external dependencies on other protocols.
+
+
+13. Resource Record TTL Values and Cache Coherency
+
+ The recommended TTL value for Multicast DNS resource records is
+ 120 minutes.
+
+ A client with an active outstanding query will issue a query packet
+ when one or more of the resource record(s) in its cache is (are) 80%
+ of the way to expiry. If the TTL on those records is 120 minutes,
+ this ongoing cache maintenance process yields a steady-state query
+ rate of one query every 96 minutes.
+
+ Any distributed cache needs a cache coherency protocol. If Multicast
+ DNS resource records follow the recommendation and have a TTL of 120
+ minutes, that means that stale data could persist in the system for
+ up to two hours. Making the default TTL significantly lower would
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 24]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ 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.
+
+
+13.1 Cooperating Multicast DNS Responders
+
+ If a Multicast DNS Responder ("A") observes some other Multicast DNS
+ Responder ("B") send a Multicast DNS Response packet containing a
+ resource record with the same name type and class 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 unique resource record
+ then this is a conflict and MUST be handled as described in Section
+ 10 "Conflict Resolution".
+
+ If a Multicast DNS Responder ("A") observes some other Multicast DNS
+ Responder ("B") send a Multicast DNS Response packet containing a
+ resource record with the same name type and class as one of A's
+ resource records, and identical rdata, then:
+
+ o If the TTL of B's resource record given in the packet 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 packet is less than
+ half the true TTL from A's point of view, then A MUST mark its
+ record to be announced via multicast. Clients 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.
+
+ 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.
+
+
+13.2 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 a gratuitous announcement mDNS
+ response packet, giving the same resource record name, type, class
+ and rdata, but an RR TTL of zero. This has the effect of updating the
+ TTL stored in neighbouring hosts' cache entries to zero, causing that
+ cache entry to be promptly deleted.
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 25]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ Clients 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 13.1 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.
+
+ Generally speaking, it is more important to send goodbye packets for
+ shared records than unique records. A given shared record name (such
+ as a PTR record used for DNS Service Discovery [DNS-SD]) by its
+ nature often has many representatives from many different hosts, and
+ tends to be the subject of long-lived ongoing queries. Those
+ long-lived queries are often concerned not just about being informed
+ when records appear, but also about being informed if those records
+ vanish again. In contrast, a unique record set (such as an SRV
+ record, or a host address record), by its nature, often has far fewer
+ members than a shared record set, and is usually the subject of
+ one-shot queries which simply retrieve the data and then cease
+ querying once they have the answer they are seeking. Therefore,
+ sending a goodbye packet for a unique record set is likely to offer
+ less benefit, because it is likely at any given moment that no one
+ has an active query running for that record set. One example where
+ goodbye packets for SRV and address records are useful is when
+ transferring control to a Sleep Proxy Server (see Section 16.
+ "Multicast DNS and Power Management").
+
+
+13.3 Announcements to Flush Outdated Cache Entries
+
+ Whenever a host has a resource record with potentially new data (e.g.
+ after rebooting, waking from sleep, connecting to a new network link,
+ changing IP address, etc.), the host MUST send a series of gratuitous
+ announcements to update cache entries in its neighbour hosts. In
+ these gratuitous announcements, if the record is one that is intended
+ to be unique, the host sets the most significant bit of the rrclass
+ field of the resource record. This bit, the "cache flush" bit, tells
+ neighbouring 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, type and class, all old records
+ with that name, type and class 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 the answer section of the DNS Response, it
+ means, "This is an assertion that this information is true." When a
+ resource record appears in the answer 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
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 26]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ may have heard more than a second ago regarding records of this
+ name/type/class is no longer valid".
+
+ 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
+ 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 SHOULD 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
+ SHOULD set the cache flush bit on all members of the unique RRSet.
+ In the event that for some reason the host chooses not to send the
+ entire unique RRSet in a single packet or a rapid packet burst,
+ it MUST NOT set the cache flush bit on any of those records.
+
+ The 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 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 address records
+ so that both sets remain valid and live in peer caches.
+
+ These rules apply regardless of *why* the response packet is being
+ generated. They apply to startup announcements as described in
+ Section 9.3, and to responses generated as a result of receiving
+ query packets.
+
+ The "cache flush" bit is only set in Multicast DNS responses sent to
+ UDP port 5353. The "cache flush" bit MUST NOT be set in any resource
+ records in a response packet 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 packet.
+
+ 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.
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 27]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ 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 an mDNS packet (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 mDNS resource record class 0x8001. The value
+ 0x8001 in the rrclass field of a resource record in an mDNS response
+ packet 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.
+
+
+13.4 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 mDNS 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, or wakes from sleep, or undergoes some
+ other similar discontinuous state change, the cache management
+ strategy should take that information into account.
+
+
+13.5 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 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
+ ARP/ND requests for that address go unanswered (for an address on a
+ local subnet) or because a router returns an ICMP "Host Unreachable"
+ error (for an address on a remote subnet).
+
+ 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.
+
+ In any such case, the software implementing the mDNS resource record
+ cache should provide a mechanism so that clients detecting stale
+ rdata can inform the cache.
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 28]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ When the cache receives this hint that it should reconfirm some
+ record, it MUST issue two or more queries for the resource record in
+ question. If no response is received in a reasonable amount of time,
+ 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.
+
+
+13.6 Passive Observation of Failures
+
+ 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 a reasonable amount of
+ time, then even though its TTL may indicate that it is not yet due to
+ expire, that record MAY be flushed from the cache. The host SHOULD
+ NOT perform its own queries to re-confirm 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.
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 29]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+14. 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.
+
+ The option to lookup unqualified (relative) names by appending
+ ".local." (or not) is controlled by whether ".local." appears
+ (or not) in the client's DNS search list.
+
+ No special control is needed for enabling and disabling Multicast DNS
+ for names explicitly ending with ".local." as entered by the user.
+ The user doesn't need a way to disable Multicast DNS for names ending
+ with ".local.", because if the user doesn't want to use Multicast
+ DNS, they can achieve this by simply not using those names. If a user
+ *does* enter a name ending in ".local.", then we can safely assume
+ the user's intention was probably that it should work. Having user
+ configuration options that can be (intentionally or unintentionally)
+ set so that local names don't work is just one more way of
+ frustrating the user's ability to perform the tasks they want,
+ perpetuating the view that, "IP networking is too complicated to
+ configure and too hard to use." This in turn perpetuates the
+ continued use of protocols like AppleTalk. If we want to retire
+ AppleTalk, NetBIOS, etc., we need to offer users equivalent IP
+ functionality that they can rely on to, "always work, like
+ AppleTalk." A little Multicast DNS traffic may be a burden on the
+ network, but it is an insignificant burden compared to continued
+ widespread use of AppleTalk.
+
+
+15. Considerations for Multiple Interfaces
+
+ A host should defend its host name (FQDN) 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.
+
+ When answering a Multicast DNS query, a multi-homed host with a
+ link-local address (or addresses) should take care to ensure that
+ any address going out in a Multicast DNS response is valid for use
+ on the interface on which the response is going out.
+
+ 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 multi-homed 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
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 30]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ 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.
+
+
+16. Multicast DNS and Power Management
+
+ Many modern network devices have the ability to go into a low-power
+ mode where only a small part of the Ethernet hardware remains
+ powered, and the device can be woken up by sending a specially
+ formatted Ethernet frame which the device's power-management hardware
+ recognizes.
+
+ To make use of this in conjunction with Multicast DNS, the device
+ first uses DNS-SD to determine if Sleep Proxy Service is available on
+ the local network. In some networks there may be more than one piece
+ of hardware implementing Sleep Proxy Service, for fault-tolerance
+ reasons.
+
+ If the device finds the network has Sleep Proxy Service, the device
+ transmits two or more gratuitous mDNS announcements setting the TTL
+ of its relevant resource records to zero, to delete them from
+ neighbouring caches. The relevant resource records include address
+ records and SRV records, and other resource records as may apply to a
+ particular device. The device then communicates all of its remaining
+ active records, plus the names, types and classes of the deleted
+ records, to the Sleep Proxy Service(s), along with a copy of the
+ specific "magic packet" required to wake the device up.
+
+ When a Sleep Proxy Service sees an mDNS query for one of the
+ device's active records (e.g. a DNS-SD PTR record), it answers on
+ behalf of the device without waking it up. When a Sleep Proxy Service
+ sees an mDNS query for one of the device's deleted resource
+ records, it deduces that some client on the network needs to make an
+ active connection to the device, and sends the specified "magic
+ packet" to wake the device up. The device then wakes up, reactivates
+ its deleted resource records, and re-announces them to the network.
+ The client waiting to connect sees the announcements, learns the
+ current IP address and port number of the desired service on the
+ device, and proceeds to connect to it.
+
+ The connecting client does not need to be aware of how Sleep Proxy
+ Service works. Only devices that implement low power mode and wish to
+ make use of Sleep Proxy Service need to be aware of how that protocol
+ works.
+
+ The reason that a device using a Sleep Proxy Service should send more
+ than one goodbye packet is that the wakeup message is caused by the
+ Sleep Proxy Service seeing queries for the device's SRV and/or
+ address records, and those queries are in turn caused by the records
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 31]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ being absent from peer caches. If the records are not deleted from
+ peer caches, then those peers may use the cached value directly
+ without querying, and no wakeup message would be generated.
+
+ The full specification of mDNS / DNS-SD Sleep Proxy Service
+ is described in another document [not yet published].
+
+
+17. Multicast DNS Character Set
+
+ Unicast DNS has been plagued by the lack of any support for non-US
+ characters. Indeed, conventional DNS is usually limited to just
+ letters, digits and hyphens, with no spaces or other punctuation.
+ Attempts to remedy this have made slow progress because of the need
+ to accommodate old buggy legacy implementations.
+
+ Multicast DNS is a new protocol and doesn't (yet) have old buggy
+ legacy implementations to constrain the design choices. Accordingly,
+ it adopts the obvious simple solution: all names in Multicast DNS are
+ encoded using UTF-8 [RFC 2279]. For names that are restricted to
+ letters, digits and hyphens, the UTF-8 encoding is identical to the
+ US-ASCII encoding, so this is entirely compatible with existing host
+ names. For characters outside the US-ASCII range, UTF-8 encoding is
+ used.
+
+ Multicast DNS implementations MUST NOT use any other encodings apart
+ from UTF-8 (US-ASCII being considered a compatible subset of UTF-8).
+
+ This point bears repeating: There are various baroque representations
+ of international text being proposed for Unicast DNS. None of these
+ representations may be used in Multicast DNS packets. Any text being
+ represented internally in some other representation MUST be converted
+ to canonical UTF-8 before being placed in any Multicast DNS packet.
+
+ The simple rules for case-insensitivity in Unicast DNS also apply in
+ Multicast DNS; that is to say, in name comparisons, the lower-case
+ letters "a" to "z" match their upper-case equivalents "A" to "Z".
+ Hence, if a client issues a query for an address record with the name
+ "stuartcheshire.local", then a responder having an address record
+ with the name "StuartCheshire.local" should issue a response.
+
+ No other automatic character equivalence is defined in Multicast DNS.
+ For example, 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 client 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.
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 32]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+18. Multicast DNS Message Size
+
+ RFC 1035 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 mDNS Resource Record which 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, sent 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
+ re-assemble fragmented IP datagrams, so large Resource Records SHOULD
+ only be used in specialized cases where the implementer knows that
+ all receivers implement reassembly.
+
+ 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.
+
+
+19. Multicast DNS Message Format
+
+ This section describes specific restrictions on the allowable
+ values for the header fields of a Multicast DNS message.
+
+19.1. ID (Query Identifier)
+
+ Multicast DNS clients SHOULD listen for gratuitous responses
+ issued by hosts booting up (or waking up from sleep or otherwise
+ joining the network). Since these gratuitous responses may contain a
+ useful answer to a question for which the client is currently
+ awaiting an answer, Multicast DNS clients 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 clients MAY cache any or all Multicast DNS response
+ messages they receive, for possible future use, providing of course
+ that normal TTL aging is performed on these cashed resource records.
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 33]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ In multicast query messages, the Query ID SHOULD be set to zero on
+ transmission.
+
+ In multicast responses, including gratuitous multicast responses, the
+ Query ID MUST be set to zero on transmission, and MUST be ignored on
+ reception.
+
+ In unicast response messages generated specifically in response to a
+ particular (unicast or multicast) query, the Query ID MUST match the
+ ID from the query message.
+
+
+19.2. QR (Query/Response) Bit
+
+ In query messages, MUST be zero.
+
+ In response messages, MUST be one.
+
+
+19.3. OPCODE
+
+ In both multicast query and multicast response messages, MUST be zero
+ (only standard queries are currently supported over multicast, unless
+ other queries are allowed by future IETF Standards Action).
+
+
+19.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 implies there's some
+ other place where "better" information may be found) and MUST be
+ ignored on reception.
+
+
+19.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 MAY choose
+ to 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 client SHOULD re-issue its
+ query using TCP in order to receive the larger response.
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 34]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+19.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.
+
+
+19.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.
+
+
+19.8. Z (Zero) Bit
+
+ In both query and response messages, the Zero bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+
+19.9. AD (Authentic Data) Bit [RFC 2535]
+
+ In query messages the Authentic Data bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+ In response messages, the Authentic Data bit MAY be set. Resolvers
+ receiving response messages with the AD bit set MUST NOT trust the AD
+ bit unless they trust the source of the message and either have a
+ secure path to it or use DNS transaction security.
+
+
+19.10. CD (Checking Disabled) Bit [RFC 2535]
+
+ In query messages, a resolver willing to do cryptography SHOULD set
+ the Checking Disabled bit to permit it to impose its own policies.
+
+ In response messages, the Checking Disabled bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+
+19.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.
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 35]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+20. Choice of UDP Port Number
+
+ Arguments were made for and against using Multicast on UDP port 53.
+ The final decision was to use UDP port 5353. Some of the arguments
+ for and against are given below.
+
+
+20.1 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 clients to do simple
+ mDNS 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.
+
+
+20.2 Arguments for using a different port (UDP port 5353):
+
+ * This is not "just DNS". This is a DNS-like protocol, but different.
+
+ * Changing client code to use a different port number is not hard.
+
+ * Using the same port number makes it hard to run an mDNS Responder
+ and a conventional unicast DNS server on the same machine. If a
+ conventional unicast DNS server wishes to implement mDNS as well,
+ it can still do that, by opening two sockets. Having two different
+ port numbers is important to allow 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 the user becomes unable to access their local network
+ printer sitting on their desk right next to their computer. Using
+ a different UDP port eliminates this particular problem.
+
+ * On many operating systems, unprivileged clients may not send or
+ receive packets on low-numbered ports. This means that any client
+ sending or receiving mDNS packets on port 53 would have to run as
+ "root", which is an undesirable security risk. Using a higher-
+ numbered UDP port eliminates this particular problem.
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 36]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+21. Summary of Differences Between Multicast DNS and Unicast DNS
+
+ The value of Multicast DNS is that it 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 authoritarian
+ hierarchy controlled by a strict chain of formal delegations from the
+ top. These differences are listed below:
+
+ Multicast DNS...
+ * uses multicast
+ * uses UDP port 5353 instead of port 53
+ * operates in well-defined parts of the DNS namespace
+ * uses UTF-8, and only UTF-8, to encode resource record names
+ * defines a clear limit on the maximum legal domain name (255 bytes)
+ * allows larger UDP packets
+ * allows more than one question in a query packet
+ * 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 tie-breaking
+ * ignores the Query ID field (except for generating legacy responses)
+ * doesn't require the question to be repeated in the response packet
+ * uses gratuitous responses to announce new records to the peer group
+ * defines a "unicast response" bit in the rrclass of query questions
+ * defines a "cache flush" bit in the rrclass of responses
+ * uses DNS TTL 0 to indicate that a record has been deleted
+ * uses IP TTL 255 to verify that answers originated on the local link
+ * monitors queries to perform Duplicate Question Suppression
+ * monitors responses to perform Duplicate Answer Suppression...
+ * ... and Ongoing Conflict Detection
+ * ... and Opportunistic Caching
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 37]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+22. Benefits of Multicast Responses
+
+ Some people have argued that sending responses via multicast is
+ inefficient on the network. In fact the benefits of using multicast
+ responses result in a net lowering of overall multicast traffic, for
+ a variety of reasons.
+
+ * One multicast response can update the cache on all machines on the
+ network. If another machine later wants to issue the same query, it
+ already has the answer in its cache, so it may not need to even
+ transmit that multicast query on the network at all.
+
+ * 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.
+
+ * 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 significantly higher
+ packet rate.
+
+ * Multicast responses allow passive conflict detection. Without this
+ ability, some other conflict detection mechanism would be needed,
+ imposing its own additional burden on the network.
+
+ * When using delayed responses to reduce network collisions, clients
+ need to maintain a list recording to whom each answer should be
+ sent. The option of multicast responses allows clients 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 respones, when appropriate.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 38]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+23. 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
+ multi-homed host, with one connection to the logical "IPv4 Ethernet
+ segment", and a connection to the logical "IPv6 Ethernet segment".
+
+23.1 IPv6 Multicast Addresses by Hashing
+
+ 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.
+
+ There are some problems with this:
+
+ * When a host has a large number of records with different names, the
+ host may have to join a large number of multicast groups. This 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
+ software for filtering, thereby defeating the point of using a
+ multicast address range in the first place.
+
+ * 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.
+
+ * Ongoing Conflict Detection doesn't work.
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 39]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+24. 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 administered DNS.
+
+ In an environment where there is a group of cooperating participants,
+ but there may be other antagonistic participants on the same physical
+ link, the cooperating participants need to use IPSEC signatures
+ and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS
+ messages from trusted participants (which they process as usual) from
+ mDNS messages from untrusted participants (which they silently
+ discard).
+
+ When 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)
+ domain name containing two or more labels. Appending ".local." to
+ single-label relative domain names is acceptable, since the user
+ should have no expectation that a single-label domain name will
+ resolve as-is.
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 40]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+25. IANA Considerations
+
+ The IANA has allocated the IPv4 link-local multicast address
+ 224.0.0.251 for the use described in this document.
+
+ The IANA has allocated the IPv6 multicast address set FF0X::FB
+ for the use described in this document.
+
+ When this document is published, IANA should designate a list
+ of domains which are deemed to have only link-local significance,
+ as described in this document.
+
+ No other IANA services are required by this document.
+
+
+26. Acknowledgements
+
+ The concepts described in this document have been explored and
+ developed with help from Erik Guttman, Paul Vixie, Bill Woodcock,
+ and others.
+
+
+27. Copyright
+
+ Copyright (C) The Internet Society January 2004.
+ All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 41]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+28. Normative References
+
+ [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
+ Facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+ Specifications", STD 13, RFC 1035, November 1987.
+
+ [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+ [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+29. Informative References
+
+ [dotlocal] <http://www.dotlocal.org/>
+
+ [djbdl] <http://cr.yp.to/djbdns/dot-local.html>
+
+ [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service
+ Discovery", Internet-Draft (work in progress),
+ draft-cheshire-dnsext-dns-sd-02.txt, February 2004.
+
+ [IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
+ Overview and Architecture.
+ Institute of Electrical and Electronic Engineers,
+ IEEE Standard 802, 1990.
+
+ [NBP] Cheshire, S., and M. Krochmal,
+ "Requirements for a Protocol to Replace AppleTalk NBP",
+ Internet-Draft (work in progress),
+ draft-cheshire-dnsext-nbp-03.txt, February 2004.
+
+ [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
+ System (DNS UPDATE)", RFC 2136, April 1997.
+
+ [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address
+ Autoconfiguration", RFC 2462, December 1998.
+
+ [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [v4LL] Cheshire, S., B. Aboba, and E. Guttman, "Dynamic
+ Configuration of IPv4 Link-Local Addresses",
+ Internet-Draft (work in progress),
+ draft-ietf-zeroconf-ipv4-linklocal-11.txt, January 2004.
+
+ [ZC] Williams, A., "Requirements for Automatic Configuration
+ of IP Hosts", Internet-Draft (work in progress),
+ draft-ietf-zeroconf-reqts-12.txt, September 2002.
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 42]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+30. Author's Addresses
+
+ Stuart Cheshire
+ Apple Computer, Inc.
+ 1 Infinite Loop
+ Cupertino
+ California 95014
+ USA
+
+ Phone: +1 408 974 3207
+ EMail: rfc@stuartcheshire.org
+
+
+ Marc Krochmal
+ Apple Computer, Inc.
+ 1 Infinite Loop
+ Cupertino
+ California 95014
+ USA
+
+ Phone: +1 408 974 4368
+ EMail: marc@apple.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 43]
\ No newline at end of file
projects / catta / blobdiff