NETWORK Working Group Bernard Aboba INTERNET-DRAFT Dave Thaler Category: Standards Track Levon Esibov Microsoft March 9, 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. 1. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 2. 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. With wide deployment of the hosts registered with IPv6 addresses by routers, in the absence of the DHCP server multicast DNS is proposed to be used to discover available DNS servers, that will be used for unicast DNS. 3. 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 the name resolution for the names of the hosts on the local Aboba, Esibov & Thaler Standards Track [Page 1] INTERNET-DRAFT Multicast DNS 9 March 2000 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. With wide deployment of the hosts autoconfigured with IPv6 addresses by routers, in the absence of the DHCP servers, multicast DNS is proposed to be used to discover available DNS server, that will be used for the conventional unicast DNS name resolution. 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. 4. Terminology In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [1]. 5. 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 IP multicast addresses. These addresses include four addresses (two Local scope addresses for Ipv4 and IPv6 and two LINKLOCAL addresses for IPv4 and IPv6) in this document referred as Local Scope and LINKLOCAL [2] mDNS addresses. The IPv4 Local Scope address is 239.255.255.253. The other three addresses are yet to be assigned by IANA. In order to prevent a DNS server from recursive resolution of the multicast DNS queries, the RD (Recursion Desired) bit in the Header section of the query MUST be set to 0. In order to improve scalability, a resolver configured to use multicast DNS for name resolution always attempts to resolve a multicast query by sending it to the LINKLOCAL mDNS addresses prior to sending it to the Local Scope mDNS addresses. If a query sent to the LINKLOCAL mDNS addresses 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 resolver SHOULD resend query to a Local Scope mDNS addresses. Resolvers MAY repeat the transmission of a query in order to assure themselves that the query has been received by any hosts capable of answering the query. Aboba, Esibov & Thaler Standards Track [Page 2] INTERNET-DRAFT Multicast DNS 9 March 2000 DNS resolvers configured to use multicast DNS for name resolution listen on port 53 on the LINKLOCAL and Local Scope mDNS addresseses. Resolvers MUST respond to those queries for which they have a positive authoritative answer. The resolver responds to such queries after a random delay in the interval [0,MAX_DELAY). MAX_DELAY MUST never be longer than the requester's retransmission interval. If a duplicate response is heard by a resolver during the random delay, the resolver MUST suppress its own response. The authoritative response MUST contain AA (Authoritative Answer) bit set to 1. As an example, computer host.example.com. that receives a multicast DNS query for an A record for the name host.example.com., will respond with an A record that contains its IP address in the RDATA of the record. In addition to this, the resolvers SHOULD respond to the queries if cached data can be used. Such response contains a AA (Authoritative Answer) bit set to 0. Resolvers MUST anticipate receiving no replies to some multicasted queries, in the event that no multicast-enabled clients 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 according to RFC 2308 [15]. Resolvers MUST anticipate receiving multiple replies to the same multicasted query, in the event that several multicast DNS enabled hosts 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. Auto-configured hosts: Reference [3] describes how hosts that are configured to use DHCP, but cannot find a DHCP server, may auto-configure their IPv4 address within the 169.254/16 prefix. Such hosts may use multicast DNS as their name resolution mechanism. However, since mDNS queries from an auto-configured host will originate from a linklocal scope unicast addresses, it may not be possible for a host located on another subnet to answer them, since the source address is not routable. Thus, the result would be propagation of useless traffic. As a result, an auto-configured IPv4 address host MAY send multicast DNS queries to IPv4 LINKLOCAL mDNS address, and MUST NOT send multicast DNS queries to the IPv4 Local Scope mDNS address. Similarly, a host with an auto-configured address MUST only listen for multicast DNS queries on the IPv4 LINKLOCAL mDNS address. An auto-configured host that subsequently locates a DHCP server will transition to behaving as though it was configured via DHCP, as described above. Aboba, Esibov & Thaler Standards Track [Page 3] INTERNET-DRAFT Multicast DNS 9 March 2000 6. Name conflicts It is required to verify the uniqueness of the host DNS name when it is configured to use multicast DNS for the name resolution. When a host configured to use multicast DNS is joined to a network and/or when its name changes or when a host becomes configured to use multicast DNS for name resolution, the resolver sends a multicast A type query with its own name to discover whether there is any host (within the multicast scope) with the same name. All the responses with AA (Authoritative Answer) bit set to 0 MUST be ignored. If the query is not positively resolved then host starts using its name. If the query is positively resolved, (and AA (Authoritative Answer) bit is set to 1 in the response) then the host should verify that the IP addresses specified in the response are its own IP addresses, possibly from another adapter. If the host verifies it, then it starts using its name. If the host canÆt match the returned A records to its IP addresses, then the host MUST not use the name. This means that the host will not respond authoritatively to the multicast queries to that name as well as will not respond to other multicast queries with the records that contain in RDATA name in conflict (for example, PTR record). Although the name conflict is detected when a host joins a network (as described above), such name conflict detection mechanism doesnÆt prevent name conflicts when ômulticast scopeö changes. As an example of such change, a router, connecting two networks may be reconfigured to allow packages sent to local scope addresses to pass through. Similar examples may consider two separate networks being connected by a router or bridge. Name conflict in such situation is detected when a host receives an authoritative multicast response to an A query for its name or when a client receives more than one authoritative response to a multicast A type query that it sent. In this situation such client will send using unicast the first response (preserving the AA (Authoritative Answer) bit) that it received to the host(s) that authoritatively responded to the query after the first response was received. A host that receives a response for a query for itÆs own name, even if it didnÆt send such query, behaves as if it sent this query, meaning that the host will stop using the name as it is specified above if the AA bit is set to 1 and the IP address specified in the response is not its own IP address. 7. DNS resolver configuration In general, a DNS resolver may be configured to use for name resolution only unicast DNS, or only multicast DNS, or both. Following the notations introduced in the RFC 1001 [16], every DNS resolver may be configured as one of the following four types of nodes: p-node û DNS resolver sends only unicast queries. Resolver doesnÆt listen on multicast addresses. Aboba, Esibov & Thaler Standards Track [Page 4] INTERNET-DRAFT Multicast DNS 9 March 2000 h-node û DNS resolver sends unicast query. If the query is not positively resolved, then it submits the multicast query. Resolver listens on multicast addresses. m-node û DNS resolver sends multicast query. If the query is not positively resolved, then it submits the unicast query. Resolver listens on multicast addresses. b-node û DNS resolver sends only multicast queries. Clients listen on multicast addresses. Depending on the environments where host is used, different configurations could be more or less appropriate. While multicast DNS was designed for use within small networks, it is essential that its deployment not adversely affect enterprise networks. A Multicast DNS Node Type DHCP Option [4] enables network administrators to appropriately configure resolvers to prevent flooding caused by multicast DNS queries in the administered large networks. A host that is configured via DHCP, but does not receive a Multicast DNS Node Type DHCP Option MUST NOT use multicast DNS for name resolution unless otherwise configured. Thus, it behaves as though it had been configured as a P-node. If a DNS server is running on a host, the DNS resolver on such a host MUST be configured as a p-node, to prevent a DNS resolver from listening on port 53 and intercepting DNS queries directed to the DNS server. 8. DNS server discovery in IPv6 Multicast DNS MAY be used for the DNS server discovery. This behavior is expected when IPv6 gets widely deployed in the scenarios where DHCPv6 is not available. In the presence of a DHCPv6 server it is expected that administrators will configure the hosts with the DNS servers using the DNS server configuration option. A host that is not configured with a DNS server regardless of the configuration of its Multicast DNS node type MAY attempt to discover a preferred DNS server by sending a multicast SRV [17] query as described below. If no response is received, then the host MUST behave according to its multicast DNS node type configuration, but MAY repeat a multicast SRV query to discover DNS server on a periodic basis. If a response is received the host starts using discovered DNS servers for the name resolution, but it continues to behave according to its multicast DNS node type configuration. Aboba, Esibov & Thaler Standards Track [Page 5] INTERNET-DRAFT Multicast DNS 9 March 2000 To minimize the network load and load on the resolvers that listen to the multicast DNS queries, the following algorithm will be used if a resolver attempts a discovery of a DNS server: 1. send a query to the IPv6 LINKLOCAL mDNS address 2. if a query sent to the IPv6 LINKLOCAL mDNS address is not positively resolved during a limited amount of time, then resolver SHOULD resend query to the Local Scope All_DNS_servers mDNS address. Resolvers MAY repeat the transmission of a query in order to assure themselves that the query has been received by a DNS servers capable of answering the query. DNS servers that are configured to be discovered through multicast DNS queries, MUST listen on the IPv6 LINKLOCAL and IPv6 Local Scope All_DNS_servers mDNS addresses. They respond to the same multicast address the query was sent. DNS server discovery using SRV multicast query DNS server location information is to be stored using DNS Service Location Record (SRV)[17]. The data in a SRV record contains the DNS name of the DNS server, corresponding Port number, and Priority and Weight fields that enable the resolver to choose an appropriate server from multiple servers according to the algorithm described in the SRV protocol[17]. The name of this record is always: _dns._udp.lcl where ôdnsö indicates the service provided by the server, and "udp" is a protocol that should be used to contact a DNS server. This document doesnÆt imply to change the current standards specifying when udp and tcp protocols should/should not be used by DNS resolvers and servers. Every DNS server that is configured to be discovered through the multicast DNS query must be authoritative for the zone ôlclö. Presence of the SRV records for ô_dns._udp.lclö enables resolvers to find the DNS servers using multicast DNS query. As an example, a resolver that searches for a DNS server will submit a multicast DNS query for a set of SRV records with owner name: _dns._udp.lcl The resolver will receive the list of SRV records published in DNS that satisfy the requested criteria. The following is an example of such record: _dns._udp.lcl IN SRV 0 0 53 dnsserver.example.net. The set of returned records may contain multiple records in the case where multiple DNS servers serve the same network. Aboba, Esibov & Thaler Standards Track [Page 6] INTERNET-DRAFT Multicast DNS 9 March 2000 8. IANA Considerations Authors will contact IANA to reserve: 1. LINKLOCAL IPv4 and IPv6 addresses 2. Local Scope IPv6 address 3. Local Scope All_DNS_servers IPv6 address. Authors of the draft will contact IANA to reserve a top level domain ôlclö. 9. 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. 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 multicast DNS server discovery mechanism introduces another type of denial of service attack on the DNS servers by sending multicast queries to the DNS server, but this type is not worse than any other and does not add additional complication. All security considerations related to DNS SRV records are inherited by this document. See the security considerations section in [17] for more details. 10. Acknowledgements Authors would like to thank Eric Gutman for productive discussion and his contribution to the specification of the multicast DNS. Aboba, Esibov & Thaler Standards Track [Page 7] INTERNET-DRAFT Multicast DNS 9 March 2000 11. Authors' Addresses 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 Levon Esibov Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: levone@microsoft.com 12. 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] Troll, R., "Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network", Internet draft (work in progress), draft-ietf-dhc- ipv4-autoconfig-04.txt, April 1999. [4] Aboba, B., Esibov, L, Thaler, D., "Multicast DNS Configuration Option", Internet draft (work in progress), draft-aboba-dhc-mdns- conf-00.txt, February 2000. [5] Braden, R., "Requirements for Internet Hosts -- Application and Support", RFC 1123, October 1989. [6] Hanna, S., Patel, B., and Shah, M., "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999. Aboba, Esibov & Thaler Standards Track [Page 8] INTERNET-DRAFT Multicast DNS 9 March 2000 [7] Woodcock, B., Manning, B., "Multicast Discovery of DNS Services", Internet draft (work in progress), draft-manning-multicast- dns-01.txt, October 1998. [8] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. [9] IANA, "Single-source IP Multicast Address Range", http://www.isi.edu/in-notes/iana/assignments/single-source- multicast, October 1998. [10] Handley, M., Thaler, D., and Kermode, R., "Multicast-Scope Zone Announcement Protocol (MZAP)", Work in progress, draft-ietf-mboned- mzap-06.txt, December, 1999. [11] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., Lear, E., "Address Allocation for Private Internets", RFC 1918, February, 1996. [13] Vixie, P., et. al., "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April, 1997. [14] Troll, R., "DHCP Option to Disable Stateless Auto- Configuration in IPv4 Clients", RFC 2563, May 1999. [15] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [16] "PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS", RFC 1001, March, 1987. [17] Gulbrandsen , A., . Vixie, P., Esibov, L. ôA DNS RR for specifying the location of services (DNS SRV)ö, RFC 2782, February 2000. 13. 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 implmentation 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 Aboba, Esibov & Thaler Standards Track [Page 9] INTERNET-DRAFT Multicast DNS 9 March 2000 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." 14. Expiration Date This memo is filed as , and expires September 9, 2000. Aboba, Esibov & Thaler Standards Track [Page 10]