DNSEXT Working Group Levon Esibov INTERNET-DRAFT Bernard Aboba Category: Standards Track Dave Thaler Microsoft November 16, 2000 Multicast DNS 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract Today, with the rise of home networking, there are an increasing number of small networks operating without a DNS server. In order to allow DNS name resolution in such environments, the use of a multicast DNS is proposed. 1. Introduction Multicast DNS enables DNS name resolution in the scenarios when conventional DNS name resolution is not possible. Namely, when there are no DNS servers available on the network or available DNS servers do not provide name resolution for the names of the hosts on the local network. The latter case, for example, corresponds to a scenario when a home network that doesn't have a DNS server is connected to the Internet through an ISP and the home network hosts are configured with the ISP's DNS server for the name resolution. The ISP's DNS server provides the name resolution for the names registered on the Internet, but doesn't provide name resolution for the names of the hosts on the home network. Esibov, Aboba & Thaler Standards Track [Page 1] INTERNET-DRAFT Multicast DNS 16 November 2000 This document discusses multicast DNS, an extension to the DNS protocol which consists of a single change to the method of use, and no change to the format of DNS packets. Discovery of the services in general as well as discovery of the DNS servers in particular using multicast DNS is left outside of the scope of this document. Name resolution over non-multicast capable media is left outside of the scope of this document. In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [1]. 2. Name resolution using Multicast DNS This extension to the DNS protocol consists of a single change to the method of use, and no change whatsoever to the current format of DNS packets. Namely, this extension allows multicast DNS queries to be sent to and received on port 53 using the LINKLOCAL addresses [2] for IPv4 and IPv6 (below in this text referred as LINKLOCAL address), which are yet to be assigned by IANA. LINKLOCAL addresses are used to prevent propagation of the multicast DNS traffic across the routers that may cause network flooding. Propagation of the multicast DNS packets within the boundaries is considered sufficient to enable DNS name resolution, since the expectation is that if a network has a router, then this router can function as a mini-DHCP server, as described in [3], and a DNS proxy, possibly implementing dynamic DNS. Thus there is not expected to be a need for use of multicast DNS in networks with multiple segments. 2.1 Behavior of the sender and responder For the purpose of this document a device that sends a multicast query is called a "sender", while a device that listens to (but not necessarily responds to) a multicast query is called "responder". A device configured to be a "responder" may also be a "sender". A device configured to not be a "responder" cannot be a "sender". A sender sends multicast DNS query for any legal Type of resource record (e.g. A, PTR, etcà) for a name within the ".local.arpa." domain to the LINKLOCAL address. The RD (Recursion Desired) bit MUST NOT be set. If a responder receives a query with the header containing RD set bit, the responder MUST ignore the RD bit. Esibov, Aboba & Thaler Standards Track [Page 2] INTERNET-DRAFT Multicast DNS 16 November 2000 If the multicast query is not positively resolved ("positively resolved" refers in this document to the response with the RCODE set to 0) during a limited amount of time, then a sender MAY repeat the transmission of a query in order to assure themselves that the query has been received by a host capable of responding to the query. Repetition MUST NOT be attempted more than 5 times, and the repetition SHOULD NOT be repeated more often than once per 0.1 seconds to reduce the unnecessary network traffic. Retry intervals SHOULD be exponentially increased. A responder listens on port 53 on the LINKLOCAL address. Responders MUST respond to multicast queries to those and only those names for which they are authoritative. As an example, computer "host.example.com.local.arpa." is authoritative for the domain "host.example.com.local.arpa.". When such host receives a multicast DNS query for an A record for the name "host.example.com.local.arpa." it responds with an A record(s) that contains its IP address(es) in the RDATA of the record. In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone root except for the branches delegated into separate zones. Contrary to conventional DNS terminology, a responder is authoritative only for the zone root. For example the host "host.example.com.local.arpa." is not authoritative for the name "child.host.example.com.local.arpa." unless the host is configured with multiple names, including "host.example.com.local.arpa." and "child.host.example.com.local.arpa.". The purpose of such limitation of the name authority scope of a responder is to prevent complication that could be caused by coexistence of two or more devices with the names representing child and parent (or grandparents) nodes in the DNS tree, for example, "host.example.com.local.arpa." and "child.host.example.com.local.arpa.". In this example (unless this limitation introduced) the multicast query for an A record for the name "child.host.example.com.local.arpa." would cause two authoritative responses: name error received from "host.example.com.local.arpa.", and requested A record - from "child.host.example.com.local.arpa.". To prevent such ambiguity, we could propose to implement multicast enabled devices to perform a dynamic update of the parent (or grandparent) zone with a delegation to a child zone, in this example a host "child.host.example.com.local.arpa." would send a dynamic update for the NS and glue A record to the "host.example.com.local.arpa.", but this approach significantly complicates implementation of the multicast DNS and would not be acceptable for a lightweight devices. The response to the multicast query is composed in exactly the same manner as in case of a response to the unicast DNS query as specified in [4]. Responders MUST never respond using cached data, and the AA (Authoritative Answer) bit MUST be set. The response is sent to the sender via unicast. If a TC (truncation) bit is set in the response, then the sender MAY use the response if it contains all necessary information, or the sender MAY discard the response and resend the query over TCP or using EDNS0 with larger window using unicast address of the Esibov, Aboba & Thaler Standards Track [Page 3] INTERNET-DRAFT Multicast DNS 16 November 2000 responder. The RA (Recursion Available) bit in the header of the response MUST NOT be set. Even if the RA bit is set in the response header, the sender MUST ignore it. The responder MUST set the Hop Limit field in IPv6 header and TTL field in IPv4 header of all responses to the multicast DNS query to 255. The sender MUST verify that the Hop Limit field in IPv6 header and TTL field in IPv4 header of each response to the multicast DNS query is set to 255. If it is not, then sender MUST ignore such response. The responder should use a pre-configured TTL [5] value in the records returned in the multicast DNS query response. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value. The responder includes in the additional and authority section of the response the same records, as a DNS server would insert in the response to the unicast DNS query. Sender MUST anticipate receiving no replies to some multicasted queries, in the event that no responders are available within the multicast scope, or in the event that no positive non-null responses exist to the transmitted query. If no positive response is received, a resolver treats it as a response that no records of the specified type and class for the specified name exist (NXRRSET), which SHOULD be cached for a period that SHOULD NOT exceed 5 seconds. Sender MUST anticipate receiving multiple replies to the same multicasted query, in the event that several multicast DNS enabled computers receive the query and respond with valid answers. When this occurs, the responses MAY first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would, ordinarily. 3. Usage model A device configured to be a "responder" may also be a "sender". A device configured to not be a "responder" cannot be a "sender". Multicast DNS usage is determined by the domain search configuration as well as by special treatment of the ".local.arpa." namespace. Any device whose domain search configuration contains ".local.arpa." domain is configured to behave as "responder". A device configured to be a "responder" may also be a "sender". A device cannot be configured to behave as one (i.e. sender or responder), but not another. The sender treats queries for ".local.arpa." as a special case. The domain search list can be configured manually or automatically via a DHCP option. Esibov, Aboba & Thaler Standards Track [Page 4] INTERNET-DRAFT Multicast DNS 16 November 2000 A sender MUST NOT send a unicast query for names ending with the ".local.arpa." suffix except in the case when a sender repeats a query over TCP after it received a response to the previous multicast query with TC bit set or unless sender's cache contains NS resource record that enables sender to send a query directly to the devices authoritative for the name in query. It is not expected that a device "host.example.com." will be manually configured to have additional name "host.example.com.local.arpa." when it is configured to use multicast DNS. Instead, a responder with a name "host.example.com." configured with ".local.arpa." suffix in its domain search configuration is authoritative for the name "host.example.com.local.arpa.". I.e. when responder with the name "host.example.com." receives an A type query for the name "host.example.com.local.arpa." it authoritatively responds to the query. If ".local.arpa" is not in the domain search list, then multicast DNS MUST NOT be used by a device. This implies that the device will neither listen on the DNS LINKLOCAL multicast address, nor will it send queries to that address. An auto-configured host will typically have ".local.arpa" first in its search list so that it will be enabled to use mDNS. Typically an enterprise host will not have ".local.arpa" in its search list at all so that it will not use mDNS. The same device may use multicast DNS queries for the name resolution of the names ending with ".local.arpa.", and unicast DNS queries for name resolution of all other names. When a DNS client is requested by a user or application to perform a name resolution of a dot-terminated name that contains a ".local.arpa" suffix, a query for such name MUST be multicasted and such name should not be concatenated with any suffix. If a DNS server is running on a device, the device MUST NOT listen for the multicast DNS queries, to prevent a device from listening on port 53 and intercepting DNS queries directed to a DNS server. A DNS server may listen and respond to the multicast queries. A DNS server by default doesn't listen to the multicast DNS queries. Presence of the ".local.arpa." in the domain search list doesn't affect the configuration on the DNS server. 4. Sequence of events The sequence of events for usage of multicast DNS is as follows: 1. If a sender needs to resolve a query for a name "host.example.com.local.arpa", then it sends a multicast query to the LINKLOCAL multicast address. 2. A responder responds to this query only if it is authoritative for the domain name "host.example.com.local.arpa". The responder sends a response to the sender via unicast over UDP. Esibov, Aboba & Thaler Standards Track [Page 5] INTERNET-DRAFT Multicast DNS 16 November 2000 3. Upon the reception of the response the sender verifies that the Hop Limit field in IPv6 header or TTL field in IPv4 header (depending on used protocol) of the response is set to 255. If it is, then sender uses and caches the returned response. If not, then the sender ignores the response and continues waiting for the response. 5. Name conflicts It is required to verify the uniqueness of the host DNS name when a host boots, when its name is changed, or when it is configured to use multicast DNS (such as when the domain search option is changed to include ".local.arpa."). A gratuitous name resolution query SHOULD be done to check for a name conflict. This is done by having the resolver send a multicast query for a SOA type query for its own name (i.e. for the name it is authoritative for). If the query is not positively resolved then host assumes authority for the name. If the query is positively resolved, then the host should verify that the computer name specified in the RDATA of the SOA record in the answer section of the response is its own computer name. If the host verifies it, then it assumes authority for its name. If the host cannot match the returned computer name to its computer name, then a conflict has been detected. In order to resolve name conflict, the host will change the name. A host that has detected a name conflict MUST NOT use the name. This means that the host MUST NOT respond to multicast queries for that name and MUST NOT respond to other multicast queries with the records that contain in RDATA name in conflict (for example, PTR record). Note that this name conflict detection mechanism doesn't prevent name conflicts when previously separate networks are connected by a bridge. Name conflict in such situation is detected when a sender receives more than one response to its multicasted DNS query. Such sender sends using unicast the first response that it received to all responders, except the first one, that responded to this query. A host that receives a response for a query for it's own name, even if it didn't send such query, sends a multicast query for the SOA record for the name that it is authoritative for. Based on the response the host detects the name conflict and acts according to the description above. 6. IANA Considerations Authors will contact IANA to reserve LINKLOCAL IPv4 and IPv6 addresses. Esibov, Aboba & Thaler Standards Track [Page 6] INTERNET-DRAFT Multicast DNS 16 November 2000 7. Security Considerations This draft does not prescribe a means of securing the multicast DNS mechanism. It is possible that hosts will allocate conflicting names for a period of time, or that non-conforming hosts will attempt to deny service to other hosts by allocating the same name. Such attacks also allow nodes to receive packets destined for other nodes. The protocol reduces the exposure to such threats in the absence of authentication by ignoring multicast DNS query response packets received from off-link senders. The Hop Limit field in IPv6 and TTL field in IPv4 of all received packets is verified to contain 255, the maximum legal value. Because routers decrement the Hop Limit on all packets they forward, received packets containing a Hop Limit of 255 must have originated from a neighbor. These threats are most serious in wireless networks such as 802.11, since attackers on a wired network will require physical access to the home network, while wireless attackers may reside outside the home. In order to provide for privacy equivalent to a wired network, the 802.11 specification provides for RC4-based encryption. This is known as the "Wired Equivalency Privacy" (WEP) specification. Where WEP is implemented, an attacker will need to obtain the WEP key prior to gaining access to the home network. The mechanism specified in this draft does not require use of the DNSSEC, which means that the responses to the multicast DNS queries may not be authenticated. If a network contains a "signed key distribution center" for all (or at least some) of the DNS zones that the responders are authoritative for, then those devices on such a network are configured with the key for the top zone, "local.arpa." (hosted by "signed keys distribution center") may use DNSSEC for the authentication of the responders using DNSSEC. 8. Acknowledgements The authors would like to thank Stuart Cheshire, Michael Patton, Erik Guttman, Olafur Gudmundsson, Thomas Narten, Mark Andrews, Erik Nordmark, Myrong Hattig, Bill Manning and James Gilroy for comments on this draft. 9. Authors' Addresses Levon Esibov Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: levone@microsoft.com Esibov, Aboba & Thaler Standards Track [Page 7] INTERNET-DRAFT Multicast DNS 16 November 2000 Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 (425) 936-6605 EMail: bernarda@microsoft.com Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 (425) 703-8835 EMail: dthaler@microsoft.com 10. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [3] Aboba, B., "The Mini-DHCP Server", Internet draft (work in progress), draft-aboba-dhc-mini-01.txt, April 2000. [4] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. [5] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987. 11. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Esibov, Aboba & Thaler Standards Track [Page 8] INTERNET-DRAFT Multicast DNS 16 November 2000 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 12. Full Copyright Statement Copyright (C) The Internet Society (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." 13. Expiration Date This memo is filed as , and expires May 16, 2001. Esibov, Aboba & Thaler Standards Track [Page 9]