Internet Engineering Task Force B. Woodcock INTERNET-DRAFT Zocalo Expires February 2001 B. Manning draft-manning-dnsext-mdns-00.txt ISI August 2000 Multicast Domain Name Service 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 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 This document describes a method by which DNS resolvers may reach multicast-capable DNS servers which may exist within a multicast local scope, by issuing a single UDP query to a static multicast address. Acknowledgments Vital contributions to this document were made by Erik Guttman, Paul Vixie, Dave Meyer, David Conrad, Andreas Gustafsson, Stuart Cheshire, Richard Ford, Tony McGregor, Stuart Kwan, Alex Hoppman and Peter Ford. Woodcock & Manning [Page 1] INTERNET-DRAFT Multicast Domain Name Service August, 2000 Overview and rationale The addition of multicast capability into the DNS protocol will facilitate retirement of legacy protocols such as AppleTalk and NetBIOS and may enable the development of new methods of service location and ZeroConf bootstrapping. Discussion 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. Specifically, this extension allows UDP DNS queries, as documented in RFC 1035, sections 4.1.1, 4.1.2 and 4.2.1, to be addressed to port 53 of statically-assigned relative offset -4 within the range of multicast addresses defined as "administratively scoped" by RFC 2365, section 9. Within the full /8 of administratively scoped addresses, this corresponds to the destination address 239.255.255.251. Until MZAP or a similar protocol is implemented to allow hosts to discover the extent of the local multicast scopes which enclose them, it is anticipated that implementations will simply utilize the destination address 239.255.255.251. Queries sent via multicast MUST NOT request recursion. In order to receive multicasted queries, DNS server implementations MUST listen on the -4 offset to their local scope (as above, in the absence of a method of determining the scope, this will be assumed to be relative to the full /8 allocated for administratively-scoped multicast use, or 239.255.255.251), and respond via ordinary unicast UDP to ONLY those queries for which they have a positive answer which originated within a locally-configured zone file. That is, a server MUST NOT answer a multicasted query with cached information which it received from another server, nor may it request further resolution from other servers on behalf of a multicasted query. A multicast-capable server may, however, utilize multicast queries to perform further resolution on behalf of queries received via ordinary unicast. This is referred to as "proxy" operation. Multicast-enabled DNS servers MUST answer multicasted queries non-authoritatively. That is, when responding to a query which was received via multicast, they MUST NOT include an NS record which contains data which resolves back to their own IP address and MUST NOT set the AA bit. Resolvers MUST anticipate receiving no replies to some multicasted queries, in the event that no multicast-enabled DNS server implementations are active within the local scope, or in the event that no positive responses exist to the transmitted query. That is, a query for the MX record for host.domain.com would go unanswered if no local server was able to resolve that request, if no MX record exists for host.domain.com, or if no local servers were capable of receiving multicast queries. The resolver which initiated Woodcock & Manning [Page 2] INTERNET-DRAFT Multicast Domain Name Service August, 2000 the query MUST treat such non-response as a non-cacheable negative response. Since this multicast transmission does not provide reliable delivery, resolvers MAY repeat the transmission of a query in order to assure themselves that is has been received by any hosts capable of answering, however any resolvers which repeat a query MUST increase the interval by a factor of two between each repetition. It is more likely, however, that any repeated queries will be performed under the explicit direction of the application driving the query, rather than autonomously by the resolver implementation. It will often be the case that multicast queries will result in responses from multiple servers. In the event that the multicast query was generated via a current API such as gethostbyname, or as the result of a proxy operation, the first response received must be passed to the requesting application or host, and all subsequently-received responses must be discarded. Future multicast-aware APIs should anticipate receiving multiple independent RR-sets in response to queries. Security Considerations While this extension to DNS introduces no known security problems to DNS or Multicast, it should be emphasized that distributed directories, common to other networking protocols, have not hitherto been widely used in the IP networking community. Distributed directories do require that users and system administrators assume some conscious balance between the level of trust which they accord to the responding entities on their network, and the degree of credence which they pay to the responses they receive. References RFC 1034: Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November, 1987. RFC 1035: Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November, 1987. RFC 2052: Gulbrandsen, A., Vixie, P., "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October, 1996. RFC 2365: Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July, 1998. Handley, M., Thaler, D., "Multicast-Scope Zone Announcement Protocol (MZAP)", MBoneD Internet Draft, October, 1998. Sidhu, G.S., Andrews, R.F., and Oppenheimer, A., "Inside AppleTalk, Second Edition", Addison-Wesley, 1990. Woodcock & Manning [Page 3] INTERNET-DRAFT Multicast Domain Name Service August, 2000 Authors' Addresses Bill Woodcock Zocalo 2355 Virginia Street Berkeley, CA 94709-1315 USA Phone: +1 510 540 8000 EMail: woody@zocalo.net Bill Manning USC/ISI 4676 Admiralty Way, #1001 Marina del Rey, CA. 90292 USA Phone: +1 310 822 1511 EMail: bmanning@isi.edu 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. Woodcock & Manning [Page 4]