Stuart Cheshire Document: draft-cheshire-dnsext-multicastdns-00.txt Apple Computer Expires 13th January 2002 13th July 2001 Performing DNS queries via IP Multicast Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this memo is unlimited. Abstract Multicast DNS is a really obvious idea, whose time has finally come. This draft proposes one possible way of making it work. 1. Acknowledgements This work builds upon original work done on Multicast DNS by Bill Manning and Bill Woodcock. The authors gratefully acknowledge their contribution to the current specification. Other contributors of valuable ideas include Bernard Aboba, Mark Andrews, Randy Bush, Levon Esibov, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Hattig, Thomas Narten, Erik Nordmark and Dave Thaler. I apologize humbly to anyone who feels their work has not been properly credited and I offer to buy dinner or drinks in compensation. Expires 13th January 2002 Cheshire [Page 1] Internet Draft DNS queries via IP Multicast 13th July 2001 2. Introduction This is a rough first draft. Its purpose is to describe the proposed idea well enough for meaningful discussion to take place. As such, while feedback concerning typographical mistakes and similar minutiae is always appreciated, the reader is advised that it is probably unwise to waste a lot of time on such trivia until after we find out whether this proposal will even live long enough to become a 'draft-01'. When reading this document, familiarity with the concepts of Zero Configuration Networking [ZC] and automatic link-local addressing [v4LL] [RFC 2462] is helpful. This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply discusses what needs to happen if DNS clients start sending DNS requests to a multicast address. The primary difference between this document and "draft-ietf-dnsext- mdns-01.txt" is the philosophy about how subdomains of the "local.arpa." domain are delegated. That document proposes that hosts running Multicast DNS Responders each assert an SOA record, thereby claiming to be the sole authority for their own little zone within the "local.arpa." domain. That approach makes it difficult for different hosts to manage two or more resource records with the same name, a feature that has some benefits. This document proposes that subdomains of the "local.arpa." domain can never be delegated, and instead "local.arpa." is managed as a single zone implemented by a loose collection of hosts cooperatively executing a distributed algorithm. From that philosophical difference, a variety of implementation differences emerge. There has been discussion of whether "local.arpa." is an appropriate domain to use. Perhaps it is not. Perhaps some other domain should, by IETF Standards Action, be declared a reserved name in the DNS protocol for this particular use. In any case, the text "local.arpa." in this document should be taken as a place holder for whatever reserved name or "domain" may eventually be allocated for this purpose. 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 using Multicast DNS is anticipated to be roughly the same order of magnitude as the amount of broadcast ARP traffic those hosts already generate. Expires 13th January 2002 Cheshire [Page 2] Internet Draft DNS queries via IP Multicast 13th July 2001 3. 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. 4. Multicast DNS Names The DNS domain "local.arpa." is (this document proposes) a special domain with special semantics, namely that "local.arpa." and all its subdomains are link-local, and names within this domain are meaningful only on the link where they originate, much as IPv4 addresses in the 169.254/16 prefix are link-local and meaningful only on the link where they originate. Any DNS query for a name within the "local.arpa." domain MUST be sent to the all-DNS multicast address (224.0.0.251 or its IPv6 equivalent). It is unimportant whether a name within the "local.arpa." domain occurred because the user explicitly typed in a fully qualified domain name ending in "local.arpa.", or because the user entered an unqualified domain name and the host software appended the "local.arpa." search domain to it. The "local.arpa." domain 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.arpa." domain is no different to any other search domain that might appear in the list. DNS queries for a names outside the "local.arpa." domain MAY be sent to the all-DNS 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. This 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 that owns 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." Another host, attempting and failing to resolve that name via conventional unicast DNS MAY elect to try resolving it via multicast, Expires 13th January 2002 Cheshire [Page 3] Internet Draft DNS queries via IP Multicast 13th July 2001 which may be successful if the two hosts happen to be on the same link. However, the majority 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. These users MAY elect to give their computers link-local host names of the form: "single-dns-label.local.arpa." For example, my laptop computer answers to the name "stu.local.arpa." Any computer user is granted the authority to name their computer this way, providing that the chosen host name is not already in use on that link. Having named their computer this way, the user has the authority to continue using that name until such time as name conflict occurs on the link which is not resolved in the user's favour. When 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. 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. Allowing ad-hoc allocation of single-label names in a single flat "local.arpa." namespace may seem to invite chaos. However, operational experience with AppleTalk NBP names, which on any given link are also effectively single-label names in a flat namespace, shows that in practice name collisions happen extremely rarely and are not a problem. Groups of computer users from disparate organizations bring Macintosh laptop computers to events such as IETF Meetings, the Mac Hack conference, the Apple World Wide Developer Conference, etc., and complaints at these events about users suffering conflicts and being forced to rename their machines have never been an issue. Enforcing uniqueness of host names (i.e. the names of DNS address records mapping names to IP addresses) is probably desirable in the common case, but this document does not mandate that. It is also 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, but it is important that the Multicast DNS protocol allows hosts to verify and maintain unique names for resource records where that behaviour is desired, and to maintain multiple resource records with a single shared name where that behaviour is desired. This consideration applies to all resource records, not just address records (i.e. host names). Expires 13th January 2002 Cheshire [Page 4] Internet Draft DNS queries via IP Multicast 13th July 2001 5. IP TTL Checks A host sending a Multicast DNS request to a link-local address MUST verify that the TTL in reply packets is 255, and silently discard any reply packets where the TTL is not 255. Without this check, it could be possible for remote rogue hosts to send spoof answer packets (perhaps unicast to the victim host) which the receiving machine could misinterpret as having originated on the local link. There has been some discussion that many current network programming APIs to not provide any indication of the TTL on received packets. This is unfortunate, and should be fixed for hosts that want to be able to guard against spoof packets arriving from off-link. 6. Reverse Address Mapping Like "local.arpa." the domain "254.169.in-addr.arpa." is defined to be link-local. Any DNS query for a name within the "254.169.in-addr. arpa." domain MUST be sent to the all-DNS multicast address 224.0.0.251. 7. Requesting There are three kinds of Multicast DNS Requests, one-shot requests of the kind made by today's conventional DNS clients, one-shot requests accumulating multiple replies made by multicast-aware DNS clients, and continuous ongoing Multicast DNS Requests 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 Requester so that it can first verify the uniqueness of those records before it begins answering requests for them. 7.1 One-Shot Requests An unsophisticated DNS client may simply send its DNS requests blindly to the 224.0.0.251 multicast address, without necessarily even being aware what a multicast address is. Indeed, certain existing DNS clients (e.g. Mac and Windows) can be persuaded to do this even today, simply by the user typing in that address as the 'name server address'. Such an unsophisticated DNS client may not get ideal behaviour. Such a client may simply take the first response it receives and fail to wait to see if there are more, but in many instances this may not be a serious problem. If a user types "http://stu.local.arpa." 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 13th January 2002 Cheshire [Page 5] Internet Draft DNS queries via IP Multicast 13th July 2001 7.2 One-Shot Requests, Accumulating Multiple Replies A more sophisticated DNS client should understand that Multicast DNS is not exactly the same as unicast DNS, and should modify its behaviour in some simple ways. As described above, there are some cases, such as looking up the address associated with a unique host name, where a single response is sufficient, and moreover may be all that is expected. However, there are other DNS requests where more than one response is possible, and for these requests 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 request only so long as it has received no reply. 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 request 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 request for which is has already received some replies, MAY elect to implement duplicate suppression, as described below under "Duplicate Suppression". 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 request. A Multicast DNS Requester MAY place more than one question into the Question Section of a Multicast DNS Request. 7.3 Continuous Requesting In One-Shot Requests, with either a single or multiple responses, the underlying assumption is that the transaction begins when the application issues a request, 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 13th January 2002 Cheshire [Page 6] Internet Draft DNS queries via IP Multicast 13th July 2001 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. A Multicast DNS Requester asking the same question repeatedly for an indefinite period of time MUST implement duplicate suppression, as described below. 8. Duplicate Suppression When a Multicast DNS Requester sends a request to which it already knows some answers, it populates the Answer Section of the DNS message with those cached resource records whose remaining TTL values indicate that they will remain valid for at least the time anticipated to send this DNS request, and the next, and the one after that. For example, if the Multicast DNS Requester is planning to wait four seconds after this request before sending the next, and then eight seconds after that, then only resource records with TTL values greater than twelve seconds should be included in the answer section. This is to ensure that when a resource record's TTL is close to expiration, the Multicast DNS Requester has *two* chances to refresh it before the cached record expires and has to be removed from the list. A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Request if the answer it would give is already included in the Answer Section with a TTL at least half the correct value. If the TTL of the answer as given in the Answer Section is less than half of the real TTL as known by the Multicast DNS Responder, the responder SHOULD send an answer so as to update the Requester's cache before the record becomes in danger of expiration. A Multicast DNS Requester MUST NOT cache resource records observed in the Answer Section of other Multicast DNS Requests. The Answer Section of Multicast DNS Requests is not authoritative. By placing information in the Answer Section of a Multicast DNS Request the requester 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 Requesters on the network would not be helpful. A Multicast DNS Responder that implements duplicate suppression SHOULD implement EDNS0 [RFC 2671] to allow larger-sized requests and replies. Expires 13th January 2002 Cheshire [Page 7] Internet Draft DNS queries via IP Multicast 13th July 2001 9. Responding A Multicast DNS Responder MUST only reply 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. A Multicast DNS Responder on Ethernet [IEEE802] and similar shared multiple access networks SHOULD delay its responses by a random amount of time selected with uniform random distribution in the range 0-10ms. If multiple Multicast DNS Responders were all to immediately reply to a particular request, a collision would be virtually guaranteed. By imposing a small random delay, the number of collisions is dramatically reduced. 10ms is a short enough time that it is not perceptible to a human user, but long enough to significantly reduce the risk of Ethernet collisions. On a full-sized Ethernet using the maximum cable lengths allowed and the maximum number of repeaters allowed, an Ethernet frame is vulnerable to collisions during the transmission of its first 256 bits. On 10Mb/s Ethernet, this equates to a vulnerable time window of 25.6us. In the case where a Multicast DNS Responder has good reason to believe that it will be the only responder on the link with a positive non-null response, it MAY reply immediately, without the random delay. To do this safely, it MUST have previously verified that the requested name type and class in the DNS query are unique on this link. This may be appropriate for things like looking up the address record for a particular host name, when the host name has been previously verified unique. This is *not* appropriate for things like looking up PTR records used for DNS Service Discovery [NIAS], where a large number of responses may be anticipated. Multicast DNS Responses MUST be sent to UDP port 53 (the well-known port assigned to DNS) on the 224.0.0.251 multicast address. 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. If the source UDP port in a received Multicast DNS Request is not port 53, this suggests that the client originating the request is an old naive client that is not entirely aware that it is using a multicast address. (The host OS needs to understand what an IP multicast address is in order to hash it to the correct Ethernet multicast address, but the user-level DNS client software does not need to know anything about multicast to blindly send a UDP packet to the IP address 224.0.0.251.) In this case, after sending the usual Expires 13th January 2002 Cheshire [Page 8] Internet Draft DNS queries via IP Multicast 13th July 2001 Multicast DNS Response to 224.0.0.251 port 53, the Multicast DNS Responder MUST also send a second identical UDP reply to the client via unicast to the request packet's source IP address and port. Multicast DNS Responders MUST correctly handle DNS request packets containing more than one question, by answering any or all of the questions to which they have answers. Multicast DNS Responders SHOULD implement EDNS0 [RFC 2671] to allow larger-sized requests and replies. Larger-sized requests are useful to allow longer duplicate suppression lists in the Answer Section. 10. Startup Procedure 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 two startup steps. 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. The ability to place more than one question in a Multicast DNS Request 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. If any conflicting Multicast DNS replies are received, then the host MUST defer to the other host already using those names, and MUST select new names for its conflicting records which need to be unique. One second after the first query it should send a second, then two seconds after that a third. If, after a total of seven seconds, no conflicting Multicast DNS replies have been received, the host may move to the second step. The second startup step is that the Multicast DNS Responder SHOULD send a gratuitous Multicast DNS Response containing, in the Answer Section, all those resource records that may be of interest to other hosts on the link. One example of this is the PTR records used by DNS Service Discovery [NIAS]. Since other hosts running Multicast DNS Requesters may have network browser windows open using an extremely long interval between Multicast DNS Request packets, the reception of a gratuitous Multicast DNS Response from a new device starting up allows the browser window to update immediately instead of having to wait until the next request is sent. Up to ten of gratuitous Multicast DNS Responses may be sent, providing that the interval between gratuitous responses doubles with every response sent, and the interval between the first two gratuitous responses is not less than one second. Expires 13th January 2002 Cheshire [Page 9] Internet Draft DNS queries via IP Multicast 13th July 2001 Whenever a Multicast DNS Responder receives any Multicast DNS response (gratuitous or otherwise) containing a conflicting resource record, the conflict MUST be resolved as described below in "Conflict Resolution". A Multicast DNS Responder MUST NOT send announcements in the absence of information that its network connectivity may have changed in some relevant way. In particular, a Multicast DNS Responder MUST NOT send regular periodic announcements as a matter of course. 11. Conflict Resolution A conflict occurs when two resource records with the same name, type and class have inconsistent rdata. What may be considered inconsistent is context sensitive, except that resource records with identical rdata are never considered inconsistent, even if they originate from different hosts. In the case of a host desiring to have a unique host name, another address record with the same name but a different IP address is considered inconsistent. Whenever a Multicast DNS Responder receives any Multicast DNS response (gratuitous or otherwise) containing a conflicting resource record, the Multicast DNS Responder must cease using that record and potentially reconfigure. In the case of a typical laptop or desktop computer with a human user, reconfiguration is achieved by displaying an error message to the user and suggesting that they choose a new name. In the case of a device with no human operator, reconfiguration is achieved by its software programmatically generating a new name. In either case, the host must then test the new name for uniqueness as described above in "Startup Procedure". It is important that the host that believes there is a conflict be the one to take action. In the case of two hosts using the same host name, where one has been configured to require a unique host name and the other has not, the one configured to require a unique host name must be the one to reconfigure, since the other one doesn't view the sharing of address records as a conflict and hence sees no reason why it should reconfigure. This algorithm could result in situations where both hosts reconfigure, but this will be rare. The uniqueness check described above in "Startup Procedure" helps reduces resource record conflicts to only those cases where two separate links are connected together, or a previously partitioned link is re-joined. 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 some other defined constraint is desired. Expires 13th January 2002 Cheshire [Page 10] Internet Draft DNS queries via IP Multicast 13th July 2001 12. Special Characteristics of Multicast DNS Domains Unlike conventional DNS, the DNS domains "local.arpa." and "254.169. in-addr.arpa." have only local significance. Conventional DNS seeks to provide a single unified namespace, where a given DNS query yields the same answer no matter where on the planet it is performed or to which recursive DNS server the query is sent. (However, split views, firewalls, intranets and the like have somewhat interfered with this goal of DNS representing a single universal truth.) In contrast, each IP link has its own private "local.arpa." and "254.169.in-addr.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. Instead, all Multicast DNS Domains are delegated to the IP address 224.0.0.251 by (potential) IETF Standards Action (i.e. this document, should it become a standard). There are no NS records anywhere in Multicast DNS Domains. The name server for a Multicast DNS Domain is 224.0.0.251. This is a multicast address; therefore it identifies 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 cluster of loosely cooperating CPUs rather than as a single process running on a single CPU (or tightly coupled multiprocessor). No delegation is performed within Multicast DNS Domains. Because the cluster of loosely coordinated CPUs is cooperating to administer a single zone, no delegation is necessary or desirable. Just because a particular host on the network may answer queries for a particular record type with the name "example.local.arpa." does not imply anything about whether that host will answer for the name "child.example.local.arpa.", or indeed for other record types with the "example.local.arpa." 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 13th January 2002 Cheshire [Page 11] Internet Draft DNS queries via IP Multicast 13th July 2001 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 "Discovering Named Instances of Abstract Services using DNS" [NIAS]. This document places few limitations on what DNS record types may be looked up in the "local.arpa." domain. In particular, a Multicast DNS request for the SRV record named "_dns._udp.local.arpa." may yield the port number and host name (and thence IP address) of a conventional DNS server willing to perform general recursive DNS lookups. The benefit of using this mechanism rather than a DHCP option to configure a host's DNS server address is that using DHCP is an outward-looking solution that makes DNS dependent on another protocol, which may not be running on every network (e.g. an IPv6 network using stateless address autoconfiguration [RFC 2462]). Locating a recursive DNS server using Multicast DNS is a self- sufficient solution that reduces DNS's need for support from other protocols. This possibility is not discussed futher here. 14. Resource Record TTL Values Multicast DNS resource records used in typical 'One-Shot' requests should generally have fairly low TTL values, on the order of seconds, rather than hours or days. The transient nature of Zeroconf networks [ZC] [v4LL] means that information can change at any time, and a host caching ancient stale resource records with unreasonably long TTL values could be left trying to work with hopelessly out-of-date information. Having hosts send gratuitous responses when configuration changes occur can somewhat mitigate this problem, but in the event of a network partition, or temporary signal fade in a wireless network, it is not safe to assume that all hosts will necessarily see all gratuitous responses. The one exception to this recommendation is resource records expected to be used to populate network browser lists, such as the PTR records used for DNS Service Discovery [NIAS]. Using short TTL values here would force the network browser to be continuously sending Multicast DNS Requests to refresh records before they expired from the list. In this case, the harm done by stale data due to high TTL values is relatively mild. The appearance of names in the network browser list is merely an assertion that the name exists now or has existed in the recent past. In order to actually use any named service, the client has to perform another DNS request to find the IP address, and in the case where the service has been forced to reconfigure to a new IP address (or has left the network entirely), the client will quickly discover that. Expires 13th January 2002 Cheshire [Page 12] Internet Draft DNS queries via IP Multicast 13th July 2001 15. Enabling and Disabling Multicast DNS The option to fail-over to Multicast DNS for names outside the "local.arpa." domain 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 in the "local.arpa." domain (or not) is controlled by whether or not "local.arpa." appears in the client's DNS search list. No special control is needed for enabling and disabling Multicast DNS for names within the "local.arpa." domain. The user doesn't need a way to disable Multicast DNS for names within the "local.arpa." domain, because if the user doesn't want to use Multicast DNS, they can achieve this by simply not using names that end in ".local.arpa." If a user *does* enter a name ending in ".local.arpa." into their Web browser, then we can safely assume their intention was probably that it should work. Having user configuration options that can be (intentionally or unintentionally) set so that this doesn'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, and there's no DHCP option to disable that! If we want to retire AppleTalk, 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. 16. Considerations for Multiple Interfaces A host should defend its host name (FQDN) on all active interfaces on which it is answering Multicast DNS requests. In the event of a name conflict on *any* interface, a host should configure a new host name, if it wishes to maintain uniqueness of its host name. When answering a Multicast DNS request, 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 reply is valid for use on the interface on which the reply is going out. Just as the same link-local IP address may validly be in use simultaneously on different links, 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 Expires 13th January 2002 Cheshire [Page 13] Internet Draft DNS queries via IP Multicast 13th July 2001 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 which 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 request and/or on what interface a Multicast DNS reply was received. 17. DNS Message Format This section describes specific restrictions on the allowable values for the header fields of a Multicast DNS message. 17.1. ID (Query Identifier) Multicast DNS clients SHOULD listen for gratuitous responses issued by hosts booting up (or waking up from sleep or otherwise joining the network). Since these gratuitous responses may contain a useful answer to a question for which the client is currently awaiting an answer, Multicast DNS clients SHOULD examine all received Multicast DNS response messages for useful answers, without regard to the contents of the ID field or the question section. In multicast DNS, knowing which particular query message (if any) is responsible for eliciting a particular response message is less interesting than knowing whether the response message contains useful information. Multicast DNS clients MAY cache any or all Multicast DNS response messages they receive, for possible future use, providing of course that normal TTL aging is performed on these cashed resource records. 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. 17.2. QR (Query/Response) Bit In query messages, MUST be zero. In response messages, MUST be one. Expires 13th January 2002 Cheshire [Page 14] Internet Draft DNS queries via IP Multicast 13th July 2001 17.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). 17.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 one -- not setting this bit implies there's some other place where 'better' information may be found. 17.5. TC (Truncated) Bit In query messages, the Truncated bit MUST be zero on transmission, and MUST be ignored on reception. In response messages, if the message does not contain all the data the requester was looking for, the requester SHOULD open a TCP connection to the responder and repeat the query. 17.6. RD (Recursion Desired) Bit In both multicast query and multicast response messages, the Recursion Desired bit MUST be zero on transmission, and MUST be ignored on reception. 17.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. 17.8. Z (Zero) Bit In both query and response messages, the Zero bit MUST be zero on transmission, and MUST be ignored on reception. 17.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. Expires 13th January 2002 Cheshire [Page 15] Internet Draft DNS queries via IP Multicast 13th July 2001 17.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. 17.11. RCODE (Response Code) In both multicast query and multicast response messages, the Response Code MUST be zero on transmission. Multicast DNS messages received with non-zero Response Codes MUST be silently ignored. 18. 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.arpa." 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.arpa." 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.arpa." 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. There has been discussion of the proposal that in the IPv6 case, the all-DNS multicast address should not be a single address, but instead a range of addresses selected using a hash function of the name being looked for. There are some issues with this: 1. The hash function must work correctly with both normal (case-insensitive) DNS labels and binary labels [RFC 2673]. 2. This may prevent more than one question being put into a single packet, since the different questions may hash to different multicast addresses. 3. This impedes the ability to use a single multicast reply packet to answer the client and simultaneously facilitate ongoing conflict monitoring, because every client would have to listen on every multicast address in the range (or rapidly join and leave multicast groups on demand for each request) in order to receive the reply. 4. This limits the ability to gain certain useful functionality out of old resolver software by configuring it with a single All-DNS multicast address to which it can send its queries. Expires 13th January 2002 Cheshire [Page 16] Internet Draft DNS queries via IP Multicast 13th July 2001 19. Security Considerations DNSSEC [RFC 2535] should be used where the authenticity of information is important. When DNS queries for names outside the "local.arpa." domain are sent to the all-DNS multicast address (during of 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 within the "local.arpa." domain, because within this domain the user can be aware that 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.arpa.", if present. A malicious host could masquerade as "www.example.com" by answering the resulting Multicast DNS request for "www.example.com.local.arpa." To avoid this, a host MUST NOT append the search domain "local.arpa.", if present, to any relative (partially qualified) domain name containing two or more labels. Appending "local.arpa." 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. [Lots more work to be done here!] 20. IANA Considerations The IANA has allocated the IPv4 link-local multicast address 224.0.0.251 for the use described in this document. We'd like the IANA to designate the DNS domain "local.arpa." a "Multicast Domain" with special semantics, namely that "local.arpa." and its subdomains are link-local, and names within this domain are meaningful only on the link where they originate, much as IPv4 addresses in the 169.254/16 prefix are link-local and meaningful only on the link where they originate. Likewise we'd like the IANA to designate the DNS domain "254.169.in-addr.arpa." to be similarly link-local and non-delegated. No other IANA services are required by this document. Expires 13th January 2002 Cheshire [Page 17] Internet Draft DNS queries via IP Multicast 13th July 2001 21. Copyright Copyright (C) The Internet Society 8th March 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires 13th January 2002 Cheshire [Page 18] Internet Draft DNS queries via IP Multicast 13th July 2001 22. References [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture. Institute of Electrical and Electronic Engineers, IEEE Standard 802, 1990. [NIAS] S. Cheshire, "Discovering Named Instances of Abstract Services using DNS", Internet-Draft (work in progress), draft-cheshire-dnsext-nias-00.txt, July 2001. [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC 2535] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC 2671] P. Vixie, "Extension mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC 2673] M. Crawford, "Binary Labels in the Domain Name System", RFC 2673, August 1999. [v4LL] S. Cheshire and B. Aboba, "Dynamic Configuration of IPv4 Link-Local Addresses", Internet-Draft (work in progress), draft-ietf-zeroconf-ipv4-linklocal-03.txt, June 2001. [ZC] M. Hattig, "Zeroconf Requirements", Internet-Draft (work in progress), draft-ietf-zeroconf-reqts-08.txt, May 2001. 23. Author's Address Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino California 95014 USA Phone: +1 408 974 3207 EMail: rfc@stuartcheshire.org Expires 13th January 2002 Cheshire [Page 19]