| Document: draft-cheshire-dnsext-multicastdns-05.txt Stuart Cheshire |
| Category: Standards Track Apple Computer, Inc. |
| Expires 7th December 2005 Marc Krochmal |
| Apple Computer, Inc. |
| 7th June 2005 |
| |
| Multicast DNS |
| |
| <draft-cheshire-dnsext-multicastdns-05.txt> |
| |
| |
| Status of this Memo |
| |
| By submitting this Internet-Draft, each author represents |
| that any applicable patent or other IPR claims of which he or she is |
| aware have been or will be disclosed, and any of which he or she |
| become aware will be disclosed, in accordance with RFC 3979. |
| |
| 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. |
| |
| |
| 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 absence 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 7th December 2005 Cheshire & Krochmal [Page 1] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| Table of Contents |
| |
| 1. Introduction...................................................3 |
| 2. Conventions and Terminology Used in this Document..............4 |
| 3. Multicast DNS Names............................................5 |
| 4. Source Address Check...........................................8 |
| 5. Reverse Address Mapping........................................9 |
| 6. Querying.......................................................9 |
| 7. Duplicate Suppression.........................................13 |
| 8. Responding....................................................15 |
| 9. Probing and Announcing on Startup.............................18 |
| 10. Conflict Resolution...........................................22 |
| 11. Resource Record TTL Values and Cache Coherency................23 |
| 12. Special Characteristics of Multicast DNS Domains..............28 |
| 13. Multicast DNS for Service Discovery...........................30 |
| 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....................................34 |
| 19. Multicast DNS Message Format..................................34 |
| 20. Choice of UDP Port Number.....................................37 |
| 21. Summary of Differences Between Multicast DNS and Unicast DNS..38 |
| 22. Benefits of Multicast Responses...............................38 |
| 23. IPv6 Considerations...........................................39 |
| 24. Security Considerations.......................................40 |
| 25. IANA Considerations...........................................41 |
| 26. Acknowledgments...............................................42 |
| 27. Copyright.....................................................42 |
| 28. Normative References..........................................42 |
| 29. Informative References........................................43 |
| 30. Authors' Addresses............................................44 |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 2] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 1. Introduction |
| |
| When reading this document, familiarity with the concepts of Zero |
| Configuration Networking [ZC] and automatic link-local addressing |
| [RFC 2462] [RFC 3927] 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 7th December 2005 Cheshire & Krochmal [Page 3] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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." |
| |
| This document uses the terms "shared" and "unique" when referring to |
| resource record sets. |
| |
| A "shared" resource record set is one where several Multicast DNS |
| responders may have records with that name, rrtype, and rrclass, and |
| several responders may respond to a particular query. |
| |
| A "unique" resource record set is one where all the records with that |
| name, rrtype, and rrclass are under the control or ownership of a |
| single responder, and at most one responder should respond to any |
| given query. Before claiming ownership of a unique resource record |
| set, a responder MUST probe to verify that no other responder |
| already claims ownership of that set, as described in Section 9.1 |
| "Probing". |
| |
| Strictly speaking the terms "shared" and "unique" apply to resource |
| record sets, not to individual resource records, but it is sometimes |
| convenient to talk of "shared resource records" and "unique resource |
| records". When used this way, the terms should be understood to mean |
| a record that is a member of a "shared" or "unique" resource record |
| set, respectively. |
| |
| |
| |
| |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 4] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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 |
| 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, a laptop computer |
| may answer to the name "cheshire.local." Any computer user is granted |
| the authority to name their computer this way, provided that the |
| chosen host name is not already in use on that link. Having named |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 5] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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. 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 |
| dotted-decimal IP addresses. Most users still move data between |
| machines by copying it onto a floppy disk or similar removable media. |
| |
| In a world of gigabit Ethernet and ubiquitous wireless networking it |
| is a sad indictment of the networking community that the preferred |
| communication medium for most computer users is still the floppy |
| disk. |
| |
| Allowing ad-hoc allocation of single-label names in a single flat |
| ".local." namespace may seem to invite chaos. However, operational |
| experience with AppleTalk NBP names [NBP], which on any given link |
| are also effectively single-label names in a flat namespace, shows |
| that in practice name collisions happen extremely rarely and are not |
| a problem. Groups of computer users from disparate organizations |
| bring Macintosh laptop computers to events such as IETF Meetings, the |
| Mac Hack conference, the Apple World Wide Developer Conference, etc., |
| and complaints at these events about users suffering conflicts and |
| being forced to rename their machines have never been an issue. |
| |
| Enforcing uniqueness of host names (i.e. the names of DNS address |
| records mapping names to IP addresses) is probably desirable in the |
| common case, but this document does not mandate that. It is |
| permissible for a collection of coordinated hosts to agree to |
| maintain multiple DNS address records with the same name, possibly |
| for load balancing or fault-tolerance reasons. This document does not |
| take a position on whether that is sensible. It is important that |
| both modes of operation are supported. The Multicast DNS protocol |
| allows hosts to verify and maintain unique names for resource records |
| where that behavior is desired, and it also allows hosts to maintain |
| multiple resource records with a single shared name where that |
| behavior is desired. This consideration applies to all resource |
| records, not just address records (host names). In summary: It is |
| required that the protocol have the ability to detect and handle name |
| conflicts, but it is not required that this ability be used for every |
| record. |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 6] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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. |
| |
| 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 7th December 2005 Cheshire & Krochmal [Page 7] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 4. Source Address Check |
| |
| All Multicast DNS responses (including responses sent via unicast) |
| SHOULD be sent with IP TTL set to 255. This is recommended to provide |
| backwards-compatibility with older Multicast DNS clients that check |
| the IP TTL on reception to determine whether the packet originated |
| on the local link. These older clients discard all packets with TTLs |
| other than 255. |
| |
| A host sending Multicast DNS queries to a link-local destination |
| address (including the 224.0.0.251 link-local multicast address) |
| MUST only accept responses to that query that originate from the |
| local link, and silently discard any other response packets. Without |
| this check, it could be possible for remote rogue hosts to send |
| spoof answer packets (perhaps unicast to the victim host) which the |
| receiving machine could misinterpret as having originated on the |
| local link. |
| |
| The test for whether a response originated on the local link |
| is done in two ways: |
| |
| * All responses sent to the link-local multicast address 224.0.0.251 |
| are necessarily deemed to have originated on the local link, |
| regardless of source IP address. This is essential to allow devices |
| to work correctly and reliably in unusual configurations, such as |
| multiple logical IP subnets overlayed on a single link, or in cases |
| of severe misconfiguration, where devices are physically connected |
| to the same link, but are currently misconfigured with completely |
| unrelated IP addresses and subnet masks. |
| |
| * For responses sent to a unicast destination address, the source IP |
| address in the packet is checked to see if it is an address on a |
| local subnet. An address is determined to be on a local subnet if, |
| for (one of) the address(es) configured on the interface receiving |
| the packet, (I & M) == (P & M), where I and M are the interface |
| address and subnet mask respectively, P is the source IP address |
| from the packet, '&' represents the bitwise logical 'and' |
| operation, and '==' represents a bitwise equality test. |
| |
| Since queriers will ignore responses apparently originating outside |
| the local subnet, responders SHOULD avoid generating responses that |
| it can reasonably predict will be ignored. This applies particularly |
| in the case of overlayed subnets. If a responder receives a query |
| addressed to the link-local multicast address 224.0.0.251, from a |
| source address not apparently on the same subnet as the responder, |
| then even if the query indicates that a unicast response is preferred |
| (see Section 6.5, "Questions Requesting Unicast Responses"), the |
| responder SHOULD elect to respond by multicast anyway, since it can |
| reasonably predict that a unicast response with an apparently |
| non-local source address will probably be ignored. |
| |
| |
| |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 8] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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. |
| |
| |
| 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 behavior. 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://cheshire.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. |
| |
| |
| |
| |
| |
| |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 9] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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 |
| behavior 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. |
| |
| 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 SHOULD be one second, and the intervals between |
| subsequent queries SHOULD 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. |
| |
| |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 10] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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 SHOULD be one |
| second, the intervals between subsequent queries SHOULD double, and |
| the querier MUST implement Known Answer Suppression, as described |
| below in Section 7.1. When the interval between queries reaches or |
| exceeds 60 minutes, a querier MAY cap the interval to a maximum of 60 |
| minutes, and perform subsequent queries at a steady-state rate of one |
| query per hour. |
| |
| 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. |
| |
| To perform this cache maintenance, a Multicast DNS Querier should |
| plan to re-query for records after at least 50% of the record |
| lifetime has elapsed. This document recommends the following |
| specific strategy: |
| |
| The Querier should plan to issue a query at 80% of the record |
| lifetime, and then if no answer is received, at 85%, 90% and 95%. If |
| an answer is received, then the remaining TTL is reset to the value |
| given in the answer, and this process repeats for as long as the |
| Multicast DNS Querier has an ongoing interest in the record. If 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. |
| |
| |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 11] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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 |
| 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. |
| |
| Unicast replies are subject to all the same packet generation rules |
| as multicast replies, including the cache flush bit (see Section |
| 11.3, "Announcements to Flush Outdated Cache Entries") and randomized |
| delays to reduce network collisions (see Section 8, "Responding"). |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 12] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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 (see Section 11.3, "Announcements to Flush |
| Outdated Cache Entries"), 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. |
| |
| 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. |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 13] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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 MUST then set the TC |
| (Truncated) bit in the header before sending the Query. It MUST then |
| immediately follow the packet with another query packet containing no |
| questions, and as many more Known Answer records as will fit. If |
| there are still too many records remaining to fit in the packet, it |
| again sets the TC bit and continues until all the Known Answer |
| records have been sent. |
| |
| A Multicast DNS Responder seeing a Multicast DNS Query with the TC |
| bit set defers its response for a time period randomly selected in |
| the interval 400-500ms. 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. |
| |
| Previous versions of this draft specified a delay of 20-120ms before |
| answering queries with multi-packet Known Answer lists. However, |
| operational experience showed that, while this works well on |
| Ethernet, on very busy 802.11 networks, it is not uncommon to observe |
| consecutively sent packets arriving separated by as much as |
| 200-400ms. |
| |
| |
| 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. |
| |
| |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 14] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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. |
| |
| |
| 8. Responding |
| |
| When a Multicast DNS Responder constructs and sends a Multicast DNS |
| response packet, the Answer Section of that packet must contain only |
| records for which that Responder is explicitly authoritative. These |
| answers may be generated because the record answers a question |
| received in a Multicast DNS query packet, or at certain other times |
| that the responder determines than an unsolicited announcement is |
| warranted. A Multicast DNS Responder MUST NOT place records from its |
| cache, which have been learned from other responders on the network, |
| in the Answer Section of outgoing response packets. Only an |
| authoritative source for a given record is allowed to issue responses |
| containing that record. |
| |
| The determination of whether a given record answers a given question |
| is done using the standard DNS rules: The record name must match the |
| question name, the record rrtype must match the question qtype |
| (unless the qtype is "ANY"), and the record rrclass must match the |
| question qclass (unless the qclass is "ANY"). |
| |
| 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 have the capability of delaying its |
| responses by up to 500ms, as determined by the rules described below. |
| 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. 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 |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 15] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| time window of 25.6us. On higher-speed variants of Ethernet, the |
| vulnerable time window is shorter. |
| |
| In the case where a Multicast DNS Responder has good reason to |
| believe that it will be the only responder on the link with a |
| positive non-null response, it SHOULD NOT impose any random delay |
| before responding, and SHOULD normally generate its response within |
| at most 10ms. In particular, this applies to responding to probe |
| queries. Since receiving a probe query gives a clear indication that |
| some other Responder is planning to start using this name in the very |
| near future, answering such probe queries to defend a unique record |
| is a high priority and needs to be done immediately, without delay. A |
| probe query can be distinguished from a normal query by the fact that |
| a probe query contains a proposed record in the Authority Section |
| which answers the question in the Question Section (for more details, |
| see Section 9.1, "Probing"). |
| |
| To generate immediate responses safely, it MUST have previously |
| verified that the requested name, rrtype and rrclass 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. |
| |
| In any case where there may be multiple responses, such as queries |
| where the answer is a member of a shared resource record set, each |
| responder SHOULD delay its response by a random amount of time |
| selected with uniform random distribution in the range 20-120ms. |
| |
| In the case where the query has the TC (truncated) bit set, |
| indicating that subsequent known answer packets will follow, |
| responders SHOULD delay their responses by a random amount of time |
| selected with uniform random distribution in the range 400-500ms, |
| to allow enough time for all the known answer packets to arrive. |
| |
| 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. |
| |
| 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 |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 16] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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 legacy unicast response SHOULD NOT |
| be greater than ten seconds, even if the true TTL of the Multicast |
| DNS resource record is higher. This is because Multicast DNS |
| Responders that fully participate in the protocol use the cache |
| coherency mechanisms described in Section 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". |
| |
| |
| 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 (non-defensive) answers |
| generated in response to query packets containing more than one |
| question SHOULD be randomly delayed in the range 20-120ms, or |
| 400-500ms if the TC (truncated) bit is set, as described above. |
| (Answers defending a name, in response to a probe for that name, |
| are not subject to this delay rule and are still sent immediately.) |
| |
| |
| |
| |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 17] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 8.3 Response Aggregation |
| |
| When possible, a responder SHOULD, for the sake of network |
| efficiency, aggregate as many responses as possible into a single |
| Multicast DNS response packet. For example, when a responder has |
| several responses it plans to send, each delayed by a different |
| interval, then earlier responses SHOULD be delayed by up to an |
| additional 500ms if that will permit them to be aggregated with |
| other responses scheduled to go out a little later. |
| |
| |
| 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 |
| 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 |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 18] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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. (Note that this is the one |
| exception from the normal rule that there should be at least one |
| second between repetitions of the same question, and the interval |
| between subsequent repetitions should double.) |
| |
| 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 fifteen 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. |
| |
| If a responder knows by other means, with absolute certainty, that |
| its unique resource record set name, rrtype and rrclass cannot |
| already be in use by any other responder on the network, then it MAY |
| skip the probing step for that resource record set. For example, when |
| creating the reverse address mapping PTR records, the host can |
| reasonably assume that no other host will be trying to create those |
| same PTR records, since that would imply that the two hosts were |
| trying to use the same IP address, and if that were the case, the two |
| hosts would be suffering communication problems beyond the scope of |
| what Multicast DNS is designed to solve. |
| |
| |
| 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 |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 19] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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 |
| 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 rrtype and rrclass 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: |
| |
| cheshire.local. A 169.254.99.200 |
| cheshire.local. A 169.254.200.50 |
| |
| In this case 169.254.200.50 is lexicographically later (the third |
| byte, with value 200, is greater than its counterpart with value 99), |
| so it is deemed the winner. |
| |
| Note that it is vital that the bytes are interpreted as UNSIGNED |
| values, 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 (both shared records, and unique |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 20] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| records that have completed the probing step). If there are too many |
| resource records to fit in a single packet, multiple packets should |
| be used. |
| |
| In the case of shared records (e.g. the PTR records used by DNS |
| 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 for a record in the Answer |
| Section of a response packet is the mDNS "cache flush" bit and is |
| discussed in more detail below in Section 11.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, provided 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. |
| |
| A Multicast DNS Responder MUST NOT send announcements in the absence |
| of information that its network connectivity may have changed in some |
| relevant way. In particular, a Multicast DNS Responder MUST NOT send |
| regular periodic announcements as a matter of course. |
| |
| Whenever a Multicast DNS Responder receives any Multicast DNS |
| response (gratuitous or otherwise) containing a conflicting resource |
| record, the conflict MUST be resolved as described below in "Conflict |
| Resolution". |
| |
| 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 neighboring caches. For example, if any of a host's IP |
| addresses change, it MUST re-announce those address records. |
| |
| In the case of shared records, a host MUST send a 'goodbye' |
| announcement with TTL zero (see Section 11.2 "Goodbye Packets") |
| for the old rdata, to cause it to be deleted from peer caches, |
| before announcing the new rdata. In the case of unique records, |
| a host SHOULD omit the 'goodbye' announcement, since the cache |
| flush bit on the newly announced records will cause old rdata |
| to be flushed from peer caches anyway. |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 21] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| A host may update the contents of any of its records at any time, |
| though a host SHOULD NOT update records more frequently than ten |
| times per minute. Frequent rapid updates impose a burden on the |
| network. If a host has information to disseminate which changes more |
| frequently than ten times per minute, then it may be more appropriate |
| to design a protocol for that specific purpose. |
| |
| |
| 10. Conflict Resolution |
| |
| A conflict occurs when a Multicast DNS Responder has a unique record |
| for which it is authoritative, and it receives, in the Answer Section |
| of a Multicast DNS response another record with the same name, rrtype |
| and rrclass, but inconsistent rdata. What may be considered |
| inconsistent is context sensitive, except that resource records with |
| identical rdata are never considered inconsistent, even if they |
| originate from different hosts. This is to permit use of proxies and |
| other fault-tolerance mechanisms that may cause more than one |
| responder to be capable of issuing identical answers on the network. |
| |
| A common example of a resource record type that is intended to be |
| unique, not shared between hosts, is the address record that maps a |
| host's name to its IP address. Should a host witness another host |
| announce an address record with the same name but a different IP |
| address, then that is considered inconsistent, and that address |
| record is considered to be in conflict. |
| |
| Whenever a Multicast DNS Responder receives any Multicast DNS |
| response (gratuitous or otherwise) containing a conflicting resource |
| record in the Answer Section, the Multicast DNS Responder MUST |
| immediately reset its conflicted unique 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 receiving a resource record that |
| conflicts with one of its own MUST take action as described above. |
| In the case of two hosts using the same host name, where one has been |
| configured to require a unique host name and the other has not, the |
| one that has not been configured to require a unique host name will |
| not perceive any conflict, and will not take any action. By reverting |
| to Probing state, the host that desires a unique host name will go |
| through the necessary steps to ensure that a unique host is obtained. |
| |
| 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. |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 22] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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. |
| |
| |
| |
| 11. Resource Record TTL Values and Cache Coherency |
| |
| As a general rule, the recommended TTL value for Multicast DNS |
| resource records with a host name as the resource record's name |
| (e.g. A, AAAA, HINFO, etc.) or contained within the resource record's |
| rdata (e.g. SRV, reverse mapping PTR record, etc.) is 120 seconds. |
| |
| The recommended TTL value for other Multicast DNS resource records |
| is 75 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 75 minutes, |
| this ongoing cache maintenance process yields a steady-state query |
| rate of one query every 60 minutes. |
| |
| Any distributed cache needs a cache coherency protocol. If Multicast |
| DNS resource records follow the recommendation and have a TTL of 75 |
| minutes, that means that stale data could persist in the system for |
| a little over an hour. Making the default TTL significantly lower |
| would reduce the lifetime of stale data, but would produce too much |
| extra traffic on the network. Various techniques are available to |
| minimize the impact of such stale data. |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 23] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 11.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, rrtype and rrclass as one of A's |
| resource records, but different rdata, then: |
| |
| o If A's resource record is intended to be a shared resource record, |
| then this is no conflict, and no action is required. |
| |
| o If A's resource record is intended to be a member of a unique |
| resource record set owned solely by that responder, then this |
| is a conflict and MUST be handled as described in Section 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, rrtype and rrclass as one of A's |
| resource records, and identical rdata, then: |
| |
| o If the TTL of B's resource record given in the 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. |
| |
| |
| 11.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, rrtype, |
| rrclass and rdata, but an RR TTL of zero. This has the effect of |
| updating the TTL stored in neighboring hosts' cache entries to zero, |
| causing that cache entry to be promptly deleted. |
| |
| 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 11.1 above, if one of the Responders shuts down and |
| incorrectly sends goodbye packets for its records, it gives the other |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 24] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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"). |
| |
| |
| 11.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 neighbor 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 |
| neighboring hosts that this is not a shared record type. Instead of |
| merging this new record additively into the cache in addition to any |
| previous records with the same name, rrtype and rrclass, all old |
| records with that name, 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 |
| may have heard more than a second ago regarding records of this |
| name/rrtype/rrclass 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 |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 25] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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 interface's |
| 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 records in the Answer Section of |
| 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. |
| |
| The "cache flush" bit does apply to questions listed in the Question |
| Section of a Multicast DNS packet. The top bit of the rrclass field |
| in questions is used for an entirely different purpose (see Section |
| 6.5, "Questions Requesting Unicast Responses"). |
| |
| Note that the "cache flush" bit is NOT part of the resource record |
| class. The "cache flush" bit is the most significant bit of the |
| second 16-bit word of a resource record in the Answer Section of |
| an mDNS packet (the field conventionally referred to as the rrclass |
| field), and the actual resource record class is the least-significant |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 26] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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. |
| |
| |
| 11.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. |
| |
| |
| 11.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. |
| |
| 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. |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 27] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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. |
| |
| |
| 11.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. |
| |
| |
| 12. 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 |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 28] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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 |
| 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. |
| |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 29] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 13. 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]. |
| |
| |
| 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. |
| |
| A host may choose to use the same name for all of its address records |
| on all interfaces, or it may choose to manage its Multicast DNS host |
| name(s) independently on each interface, potentially answering to |
| different names on different interfaces. |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 30] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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 |
| 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, we propose a |
| network power management service called Sleep Proxy Service. A device |
| that wishes to enter low-power mode 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 |
| neighboring 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, rrtypes and rrclasses 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. |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 31] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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 to ensure deletion of the resource records |
| from all peer caches. If resource records were to inadvertently |
| remain in some peer caches, then those peers may not issue any query |
| packets for those records when attempting to access the sleeping |
| device, so the Sleep Proxy Service would not receive any queries for |
| the device's SRV and/or address records, and the necessary wake-up |
| message would not be triggered. |
| |
| 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 for unicast DNS have been badly constrained |
| by the need to accommodate old buggy legacy DNS implementations. |
| In reality, the DNS specification actually imposes no limits on what |
| characters may be used in names, and good DNS implementations handle |
| any arbitrary eight-bit data without trouble. However, the old rules |
| for ARPANET host names back in the 1980s required names to be just |
| letters, digits, and hyphens [RFC 1034], and since the predominant |
| use of DNS is to store host address records, many have assumed that |
| the DNS protocol itself suffers from the same limitation. It would be |
| more accurate to say that certain bad implementations may not handle |
| eight-bit data correctly, not that the protocol doesn't support it. |
| |
| Multicast DNS is a new protocol and doesn't (yet) have old buggy |
| legacy implementations to constrain the design choices. Accordingly, |
| it adopts the simple obvious elegant solution: all names in Multicast |
| DNS are encoded using precomposed UTF-8 [RFC 3629]. The |
| characters SHOULD conform to Unicode Normalization Form C (NFC): Use |
| precomposed characters instead of combining sequences where possible, |
| e.g. use U+00C4 ("Latin capital letter A with diaeresis") instead of |
| U+0041 U+0308 ("Latin capital letter A", "combining diaeresis"). |
| |
| 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 precomposed UTF-8 (US-ASCII being considered a compatible subset |
| of UTF-8). |
| |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 32] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| This point bears repeating: After many years of debate, as a result |
| of the need to accommodate certain DNS implementations that |
| apparently couldn't handle any character that's not a letter, digit |
| or hyphen (and apparently never will be updated to remedy this |
| limitation) the unicast DNS community settled on an extremely baroque |
| encoding called "Punycode" [RFC 3492]. Punycode is a remarkably |
| ingenious encoding solution, but it is complicated, hard to |
| understand, and hard to implement, using sophisticated techniques |
| including insertion unsort coding, generalized variable-length |
| integers, and bias adaptation. The resulting encoding is remarkably |
| compact given the constraints, but it's still not as good as simple |
| straightforward UTF-8, and it's hard even to predict whether a given |
| input string will encode to a Punycode string that fits within DNS's |
| 63-byte limit, except by simply trying the encoding and seeing |
| whether it fits. Indeed, the encoded size depends not only on the |
| input characters, but on the order they appear, so the same set of |
| characters may or may not encode to a legal Punycode string that fits |
| within DNS's 63-byte limit, depending on the order the characters |
| appear. This is extremely hard to present in a user interface that |
| explains to users why one name is allowed, but another name |
| containing the exact same characters is not. Neither Punycode nor any |
| other of the "Ascii Compatible Encodings" proposed for Unicast DNS |
| may be used in Multicast DNS packets. Any text being represented |
| internally in some other representation MUST be converted to |
| canonical precomposed 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" (0x61 to 0x7A) match their upper-case equivalents |
| "A" to "Z" (0x41 to 0x5A). Hence, if a client issues a query for an |
| address record with the name "cheshire.local", then a responder |
| having an address record with the name "Cheshire.local" should |
| issue a response. No other automatic equivalences should be assumed. |
| In particular all UTF-8 multi-byte characters (codes 0x80 and higher) |
| are compared by simple binary comparison of the raw byte values. |
| |
| 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 7th December 2005 Cheshire & Krochmal [Page 33] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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 |
| NOT be used except 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, provided of course |
| that normal TTL aging is performed on these cached resource records. |
| |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 34] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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 7th December 2005 Cheshire & Krochmal [Page 35] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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. |
| |
| |
| 19.12. Repurposing of top bit of qclass in Question Section |
| |
| In the Question Section of a Multicast DNS Query, the top bit of the |
| qclass field is used to indicate that unicast responses are preferred |
| for this particular question. |
| |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 36] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 19.12. Repurposing of top bit of rrclass in Answer Section |
| |
| In the Answer Section of a Multicast DNS Response, the top bit of the |
| rrclass field is used to indicate that the record is a member of a |
| unique RRSet, and the entire RRSet has been sent together (in the |
| same packet, or in consecutive packets if there are too many records |
| to fit in a single packet). |
| |
| |
| 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 7th December 2005 Cheshire & Krochmal [Page 37] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| Continuing the previous point, since using an unprivileged port |
| allows normal user-level code to bind, a given machine may have more |
| than one such user-level application running at a time. Because of |
| this, any code binding to UDP port 5353 MUST use the SO_REUSEPORT |
| option, so as to be a good citizen and not block other clients on the |
| machine from also binding to that port. |
| |
| |
| 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 response answers |
| * uses DNS TTL 0 to indicate that a record has been deleted |
| * monitors queries to perform Duplicate Question Suppression |
| * monitors responses to perform Duplicate Answer Suppression... |
| * ... and Ongoing Conflict Detection |
| * ... and Opportunistic Caching |
| |
| |
| 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. |
| |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 38] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| * When more than one machine has the same ongoing long-lived query |
| running, every machine does not have to transmit its own |
| independent query. When one machine transmits a query, all the |
| other hosts see the answers, so they can suppress their own |
| queries. |
| |
| * When a host sees a multicast query, but does not see the |
| corresponding multicast response, it can use this information to |
| promptly delete stale data from its cache. To achieve the same |
| level of user-interface quality and responsiveness without |
| multicast responses would require lower cache lifetimes and more |
| frequent network polling, resulting in a significantly higher |
| packet rate. |
| |
| * Multicast responses allow passive conflict detection. Without this |
| ability, some other conflict detection mechanism would be needed, |
| imposing its own additional burden on the network. |
| |
| * When using delayed responses to reduce network collisions, clients |
| need to maintain a list recording to whom each answer should be |
| sent. The option of multicast responses allows clients with limited |
| storage, which cannot store an arbitrarily long list of response |
| addresses, to choose to fail-over to a single multicast response in |
| place of multiple unicast responses, when appropriate. |
| |
| * In the case of overlayed subnets and other misconfigurations, |
| multicast responses allow a receiver to know with certainty that |
| a response originated on the local link, even when its source |
| address may apparently suggest otherwise. This can be extremely |
| helpful when diagnosing and rectifying network problems, since |
| it facilitates a direct communication channel between client and |
| server that works without reliance on ARP, IP routing tables, etc. |
| Being able to discover what IP address a device has (or thinks it |
| has) is frequently a very valuable first step in diagnosing why |
| it unable to communicate on the local network. |
| |
| |
| 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 |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 39] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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. |
| |
| |
| 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. |
| |
| |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 40] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 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. |
| |
| |
| 25. IANA Considerations |
| |
| IANA has allocated the IPv4 link-local multicast address 224.0.0.251 |
| for the use described in this document. |
| |
| IANA has allocated the IPv6 multicast address set FF0X::FB for the |
| use described in this document. Only address FF02::FB (Link-Local |
| Scope) is currently in use by deployed software, but it is possible |
| that in future implementers may experiment with Multicast DNS using |
| larger-scoped addresses, such as FF05::FB (Site-Local Scope). |
| |
| When this document is published, IANA should designate a list of |
| domains which are deemed to have only link-local significance, as |
| described in Section 12 of this document ("Special Characteristics of |
| Multicast DNS Domains"). |
| |
| The re-use of the top bit of the rrclass field in the Question and |
| Answer Sections means that Multicast DNS can only carry DNS records |
| with classes in the range 0-32767. Classes in the range 32768 to |
| 65535 are incompatible with Multicast DNS. However, since to-date |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 41] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| only three DNS classes have been assigned by IANA (1, 3 and 4), |
| and only one (1, "Internet") is actually in widespread use, this |
| limitation is likely to remain a purely theoretical one. |
| |
| No other IANA services are required by this document. |
| |
| |
| 26. Acknowledgments |
| |
| The concepts described in this document have been explored, developed |
| and implemented with help from Freek Dijkstra, Erik Guttman, Paul |
| Vixie, Bill Woodcock, and others. |
| |
| Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher, |
| Roger Pantos and Kiren Sekar for their significant contributions. |
| |
| |
| 27. Copyright |
| |
| Copyright (C) The Internet Society 2005. |
| 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. |
| |
| |
| 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. |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 42] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", RFC 2119, March 1997. |
| |
| [RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO |
| 10646", RFC 3629, November 2003. |
| |
| |
| 29. Informative References |
| |
| [dotlocal] <http://www.dotlocal.org/> |
| |
| [djbdl] <http://cr.yp.to/djbdns/dot-local.html> |
| |
| [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service |
| Discovery", Internet-Draft (work in progress), |
| draft-cheshire-dnsext-dns-sd-03.txt, June 2005. |
| |
| [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: |
| Overview and Architecture. |
| Institute of Electrical and Electronic Engineers, |
| IEEE Standard 802, 1990. |
| |
| [NBP] Cheshire, S., and M. Krochmal, |
| "Requirements for a Protocol to Replace AppleTalk NBP", |
| Internet-Draft (work in progress), |
| draft-cheshire-dnsext-nbp-04.txt, June 2005. |
| |
| [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. |
| |
| [RFC 3492] Costello, A., "Punycode: A Bootstring encoding of |
| Unicode for use with Internationalized Domain Names |
| in Applications (IDNA)", RFC 3492, March 2003. |
| |
| [RFC 3927] Cheshire, S., B. Aboba, and E. Guttman, |
| "Dynamic Configuration of IPv4 Link-Local Addresses", |
| RFC 3927, May 2005. |
| |
| [ZC] Williams, A., "Requirements for Automatic Configuration |
| of IP Hosts", Internet-Draft (work in progress), |
| draft-ietf-zeroconf-reqts-12.txt, September 2002. |
| |
| |
| |
| |
| |
| |
| |
| |
| Expires 7th December 2005 Cheshire & Krochmal [Page 43] |
| |
| Internet Draft Multicast DNS 7th June 2005 |
| |
| |
| 30. Authors' 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 7th December 2005 Cheshire & Krochmal [Page 44] |