Network Working Group B. Woodcock Request for Comments: nnnn Zocalo Category: Experimental B. Manning ISI August 2000 Multicast Discovery of DNS Services draft-manning-multicast-dns-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. 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." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 1. Introduction This document describes a minimal extension to the method of a DNS query which allows unconfigured hosts to locate a local DNS server, or in the absence of a DNS server to nonetheless identify some local network services. 2. Acknowledgments Vital contributions to this document were made by Paul Vixie, Dave Meyer, Stuart Cheshire, Richard Ford, Tony McGregor, Erik Guttman, Benard Aboba, and Peter Ford. Thanks also to Alex Hoppman for discussion of text-encoding methods. 3. Overview and rationale This experimental extension to DNS is intended to provide a bootstrap mechanism whereby unconfigured devices may find a local DNS server and begin using it to perform the usual name resolution and service lookup functions. This need is particularly acute in the absence of a DHCP server. Secondarily, it is anticipated that device vendors may implement the server (query-receiving) portion of this extension, in order to render unconfigured devices which may lack an out-of-band configuration interface such as a screen or keyboard discoverable on the local network. For example, if a newly-purchased laser printer or router were connected to a network, this extension would allow a system administrator to use the DNS to discover the IP address which the device had selected or been DHCP-assigned, and begin communicating with it through the network. A tertiary objective of this extension is to make possible the deprecation of the AppleTalk protocol, which has been prolonged as a means of providing support for "network browsing." 4. 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 -2 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.253. 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.253. In order to receive multicasted queries, DNS server implementations MUST listen on the -2 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.253), and respond via ordinary unicast UDP to ONLY those queries for which they have or can find a positive non-null answer. Multicast-enabled DNS servers MUST answer multicasted queries non-authoritatively. That is, when responding to a query which was received via multicast, they MAY NOT include an NS record which contains data which resolves back to their own IP address. Resolvers SHOULD be liberal in their acceptance of wildcard queries. That is, resolvers should anticipate receiving queries which will contain the asterisk character in any position within the query's data field. For example, a query for SRV RRs with data "afp.tcp.*.domain.com." would match "afp.tcp.server.domain.com." but not match "afp.tcp.". A query for "afp.tcp.*" would match both, since the asterisk should be interpreted as matching zero or more characters within the RR data. 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 non-null 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 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 reveived by any hosts capable of answering, however any resolvers which repeat a query MUST increase the interval between such repetitions exponentially over time. Resolvers MUST also anticipate receiving multiple replies to the same multicasted query, in the event that several multicast-enabled DNS servers 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 server would, ordinarily. 5. Implementation Notes Appendix It is anticipated that a major use of this extension to DNS will be for the replacement of the AppleTalk Name Binding Protocol (NBP) "distributed database," and the implementation of a similar service within other operating systems and on other platforms. Such use implies the existence of "stub DNS servers" on each participating host, each containing only local information in its served zones, but not to the exclusion of data which other servers may assert within the same zones. The following rather complex example shows the format by which an implementor could assert the local information possessed by any Macintosh in zones served by a stub DNS server on that host: $ORIGIN . @ SOA . . 1998082701 0 0 0 0 0 IN NS dns.udp. Jasons-Mac 0 IN A 169.254.101.218 0 IN HINFO Macintosh-G3-400 MacOS-8.6 0 IN LOC 37 52 N 122 20 W 0 IN RP . owner-name.Jasons-Mac. Jasons-Hard-Disk 0 IN A 169.254.101.218 0 IN TXT "UTF8-encoded service-name" Print-Spooler 0 IN A 169.254.101.218 0 IN TXT "UTF8-encoded service-name" dns.udp 0 IN SRV 0 0 53 Jasons-Mac. afp.tcp 0 IN SRV 0 0 548 Jasons-Hard-Disk. lpr.tcp 0 IN SRV 0 0 515 Print-Spooler. http.tcp 0 IN SRV 0 0 80 www.jasonco.com. https.tcp 0 IN SRV 0 0 443 secure.jasonco.com. $ORIGIN jasonco.com. www 0 IN A 169.254.101.218 0 IN TXT "UTF8-encoded service-name" secure 0 IN A 169.254.101.218 0 IN TXT "UTF8-encoded service-name" $ORIGIN Jasons-Mac. dns.udp 0 IN SRV 0 0 53 Jasons-Mac. owner-name 0 IN TXT "Jason A. Luser" * 0 IN PTR afp.tcp.Jasons-Mac. 0 IN PTR lpr.tcp.Jasons-Mac. 0 IN PTR http.tcp.Jasons-Mac. afp.tcp 0 IN SRV 0 0 548 Jasons-Hard-Disk. lpr.tcp 0 IN SRV 0 0 515 Print-Spooler. http.tcp 0 IN SRV 0 0 80 www.jasonco.com. $ORIGIN 101.254.169.in-addr.arpa. 218 0 IN PTR Jasons-Mac. Windows and Unix hosts are possessed of many of the same, or analogous, types of local information, and similar examples could be constructed around hypothetical hosts of those types. A much simpler example featuring a laser printer follows, in section 6 of this document. Note that in translating service and device names from high-bit-depth character sets such as Unicode to DNS-compliant hostnames, a character-mapping must occur, whereby spaces are mapped to hyphens, punctuation other than periods is removed, and plain characters are substituted for their accented equivalents. Implementors MUST perform a uniqueness check, in order to guarantee that no other device within the local multicast scope has already asserted a claim to the DNS name which their device wishes to employ. Uniqueness checks at service-registration time must be somewhat more strict than their historical AppleTalk equivalents, comparing names which have already been converted to their DNS-compliant state (containing only a-z, A-Z, 0-9, and the hyphen character, and starting with a letter rather than a hyphen or number), and must treat upper and lower-case as equivalent. Note that periods in device and service names shall be preserved and used to establish subdomains within the stub DNS server's dataset. The high-bit-depth names are made available to queriants in the form of UTF8-encoded RDATA in TXT RRs included as Additional Information (as described in RFC 1035, sections 4.1 through 4.1.3) appended to any A RR response. Implementors of multicast-enabled resolvers may expect the following results of the following query-types: Data Type Result *.in-addr.arpa PTR All hostnames in the local scope *.host.domain.com SRV All services on host.domain.com lpr.tcp. SRV All printers/spoolers in the local scope Duplicate identical records received in different responses to a query may be treated as a single record in the concatenation of responses. It is beyond the scope of this document to suggest disposition of different responses which contain disagreeing pairs of name NAME and RDATA. Implementors should note that "virtual hosts" (that is, the support of multiple IP addresses on a single host, and the binding of different services to different addresses) are easily supported in responses to multicast queries, but should also note that one of the benefits afforded by the use of SRV RR-types is a reduction in the need for virtual hosts, since multiple named services may be bound to different (non-well-known) ports of the same IP address, and still be individually identified and differentiated. For example, a single host might support one HTTP server on port 80, a second on port 8001, and an HTTPS server on port 443, and each could be reached via different name. Another major use of this extension to DNS is to allow bootstrapping machines to find local DNS servers. It is anticipated that larger enterprises may in the future possess one or more fully-featured DNS servers which are also multicast-enabled. Once a bootstrapping host has located such a server, that host need no longer use multicast at all. That host may instead employ ordinary unicast DNS exactly as any other host would, to query those DNS servers. The servers, in turn, might well employ multicast queries to glean information about the services contained within their local scope, which information they might then use to respond to unicast queries (proxying, in effect), and cache against future need. Note also that the ability to answer multicast queries would prove particularly useful to a DNS server which was resident on the same host as a NAT at the border of an enterprise which employed 10.0.0.0/8 or 169.254.0.0/16 unicast addresses internally. Implementors MAY choose to employ an optimization whereby the deleterious impact of large numbers of unconfigured hosts simultaneously attempting to locate DNS servers during the bootstrap process might be mitigated, and the process be made more efficient. Specifically, high- and low-water marks are defined for frequency of multicasted lookups for SRV RRs of "dns.udp.". When a multicast-enabled DNS server observes the frequency of such lookups exceeding a high-water mark (five queries per minute, perhaps), the server MAY begin interspersing responses transmitted via multicast, rather than unicast, until such time as the frequency of such lookups falls below a low-water mark (one query per five minutes, perhaps). In order for this to work, multicast-enabled resolvers would also need to listen on the multicast address for responses, and cache them briefly. Both the server and resolver portions of this optimized behavior are optional, and it should be stressed that this optimization need not be considered by implementors of stub servers in devices such as printers, which do not provide generalized DNS services. If DNS server implementors choose to employ multicast responses, they MUST interleave multicast responses with unicast responses in such a way that the multicast responses decrease over time, rather than flooding the network, in order that servers not be used to propagate denial-of-service attacks. In other words, a reasonable approach might be while above the high-water mark to make the first, second, fourth, eighth, sixteenth et cetera responses for each RR multicast, while all inbetween would be unicast. Note that this not only protects against multicast "storms," it also protects against the mis-match condition which occurs in the case that a non-optimized resolver is the presence only of optimized servers, all of which are temporarily in multicast-response mode. Implementors SHOULD also employ DNS Sec, or its equivalent, as soon as such technology is standardized, in order to minimize the possiblity of "spoofing" of information by nodes responding to multicast queries. 6. Use & Administration Notes Appendix Administrators of networks employing this protocol are advised to employ fully-qualified domain names (FQDNs) as their host names where possible, such that the dots separating portions of the name shall be interpreted by the stub-server implementations as subdomain delimiters, and shall thus serve to remove the host from the local view of the root domain to its correct and appropriate globally-unique subdomain. Administrators of service-providing devices, such as already-deployed printers, which are not capable of receiving multicast DNS queries, may wish to inject DNS records into a local multicast-enabled DNS server on behalf of those devices. For example, an administrator might wish to create records of the following nature in order to make a non-multicast-capable laser printer visible to both multicast and unicast queriants: $ORIGIN . lpr.tcp 0 IN SRV 0 0 515 laser2.sales.domain.com. $ORIGIN sales.domain.com. laser2 0 IN A 169.254.5.28 0 IN TXT "Old Sales Dep't Laser Printer" $ORIGIN laser2.sales.domain.com. * 0 IN PTR lpr.tcp.laser2.sales.domain.com. lpr.tcp 0 IN SRV 0 0 515 laser2.sales.domain.com. $ORIGIN 5.254.169.in-addr.arpa. 28 0 IN PTR laser2.sales.domain.com. Administrators of networks which contain either multicast-capable resolvers or multicast-capable DNS servers MUST employ filters defining a contiguous border around their enterprises and prohibiting passage of data to and from the 239.0.0.0/8 address space, as well as routing information relating to the 239.0.0.0/8 prefix or any subnet of it. This is the mechanism by which RFC 2365 administrative scoping is enacted. The sole exception to this rule would be any explicitly-configured interconnections with other specific enterprises between which all involved administrators wish to share a single browsable network space. This is anticipated to be a very infrequent occurrence within the current regime of network security policies. References 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. Security Considerations While this extension to DNS introduces no new 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. The level of trust traditionally assumed in distributed directory environments does not necessarily mix well with clear-text password transmission such as is still found on some IP networks, for example. 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 (1998). 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 ...... --------------1F985EC911030AB70E0CD7B9-- -- --bill