Document: draft-cheshire-dnsext-multicastdns-03.txt Stuart Cheshire Category: Standards Track Apple Computer, Inc. Expires 29th July 2004 Marc Krochmal Apple Computer, Inc. 29th January 2003 Multicast DNS 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 29th July 2004 Cheshire & Krochmal [Page 1] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 2] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 3] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 4] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 5] Internet Draft Multicast DNS 29th January 2003 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, 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 29th July 2004 Cheshire & Krochmal [Page 6] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 7] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 8] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 9] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 10] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 11] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 12] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 13] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 14] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 15] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 16] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 17] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 18] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 19] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 20] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 21] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 22] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 23] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 24] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 25] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 26] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 27] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 28] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 29] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 30] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 31] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 32] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 33] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 34] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 35] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 36] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 37] Internet Draft Multicast DNS 29th January 2003 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. Expires 29th July 2004 Cheshire & Krochmal [Page 38] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 39] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 40] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 41] Internet Draft Multicast DNS 29th January 2003 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] [djbdl] [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture. Institute of Electrical and Electronic Engineers, IEEE Standard 802, 1990. [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service Discovery", Internet-Draft (work in progress), draft-cheshire-dnsext-dns-sd-03.txt, January 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 29th July 2004 Cheshire & Krochmal [Page 42] Internet Draft Multicast DNS 29th January 2003 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 29th July 2004 Cheshire & Krochmal [Page 43]