Internet Engineering Task Force Erik Guttman INTERNET DRAFT Sun Microsystems Intended for Standards Track 27 June 2001 Expires in six months DHCP mDNS Enable Option draft-guttman-dhc-mdns-enable-00.txt Status of this Memo This document is an individual contribution for consideration by the Internet Engineering Task Force. Comments should be submitted to the author and the DHC and DNSEXT mailing lists, as appropriate. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 (C) The Internet Society 2001. All Rights Reserved. Abstract The Dynamic Host Configuration Protocol [2] allows network administrators to determine host configuration parameters. This document defines a new DHCP option [3] specifically to enable and control multicast DNS behavior. This is an alternative to using the Domain Search Option [4] to configure mDNS behavior, as has been proposed. Multicast DNS [5] is a protocol distinct from DNS [6], specifically suited for ad-hoc network environments lacking administration and services [7]. When mDNS enabled hosts become available, it is vital E. Guttman Expires: 27 December 2001 [Page 1] Internet Draft DHC Option to Enable mDNS June 2001 that they behave as expected in administered, configured networks. DNS resolvers must determine if mDNS should be used at all, exclusively or in addition to standard DNS. 1.0 Introduction Multicast DNS [5] is a protocol distinct from DNS [6], specifically suited for ad-hoc network environments lacking administration and services [7]. When mDNS enabled hosts become available, it is vital that they behave as expected in administered, configured networks. DNS resolvers must determine if mDNS should be used at all, exclusively or in addition to standard DNS. The simplest way to achieve the current DNS resolver behavior would be to not use mDNS if a host is configured via DHCP at all or the host had DNS configuration (manual or otherwise). Just as hosts neither respond to mDNS requests nor issue them today, they wouldn't do so after becoming configured via DHCP. Only in the absence of such configuration would a host use mDNS (this is the ZeroConf scenario [7]). This simplistic approach disallows cases in which it would be extremely useful to enable mDNS. (1) A host may have access to both a configured network and an unadministered LAN (such as a home office). The devices in the home office may not have either domain names nor global address configuration. A host could continue to be able to resolve locally using mDNS as well as use a back-end DNS resolver. (2) A host which uses mDNS to resolve a name locally should not (necessarily) fail to be able to after it has obtained DNS server configuration. (3) A host may no longer be able to contact the DNS server(s) it has been configured to use. A host could use mDNS to continue to resolve domain names locally, increasing the availability of local networking services substantially. This document accepts that the default behavior for a host which has DNS server configuration (whether from DHCP or some other source) is that it MUST NOT use mDNS. The exception to this is if the DNS client receives a mDNS Enable Option as well. An alternative approach suggested in [5] is to use the domain search list (obtained, for instance, using the Domain Search Option [4]) for the same purpose. The differences between these approaches are discussed below. E. Guttman Expires: 27 December 2001 [Page 2] Internet Draft DHC Option to Enable mDNS June 2001 1.1 Terminology The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" used in this document are to be interpreted as specified in [6]. Other terms used in this document are defined in the DNS specification, RFC 1034 [8]. 2.0 DHCP Enable mDNS Option Format Code Len Order Scope +-----+-----+-----+-----+ | TBD | 2 | Ord | Scp | +-----+-----+-----+-----+ 2.1 Specifying the order in which to use DNS and mDNS The value of the 'Ord' determines the order in which mDNS is used. If the low order bit of Ord is 0, a DNS resolver MUST attempt to use a DNS server it is configured with. Only if all DNS servers fail to respond, does the resolver use mDNS to issue requests. If the low order bit of Ord is 1, a DNS resolver MUST attempt to use mDNS first, and only if this fails to obtain a response, does the resolver use DNS to issue requests. All other bits in the Ord byte MUST be ignored by a DHCP client receiving the Enable mDNS Option. 2.2 Specifying the multicast scope for issuing mDNS requests The value of 'Scp' determines the scope of the multicast used by mDNS. This field has only one defined value, Scp = 1. This indicates that LINKLOCAL multicast DNS be used, as defined in [5]. If mDNS is specified for additional multicast scopes in the future, additional values for the bits in Scp may be defined. 3.0 mDNS host behavior mDNS behavior depends upon configuration obtained by DHCP. As noted in Section 3.6 of RFC 2131 [2], "A client with multiple network interfaces must use DHCP through each interface independently to obtain configuration information parameters for those separate interfaces." Each interface is enabled to use mDNS separately. This makes good sense. For example, a telecommuter may use a multihomed host, one interface attached to a LAN in a home office, the other attached via a WAN to a corporate network. The interface connected to the LAN will issue requests using mDNS, while the interface connected to the WAN, configured by DHCP, does not have mDNS enabled. E. Guttman Expires: 27 December 2001 [Page 3] Internet Draft DHC Option to Enable mDNS June 2001 A mDNS enabled host SHOULD issue requests and respond to them from each multicast enabled interface, as per [5], by default, if it lacks any DNS or DHCP configuration. A mDNS enabled host which has manual DNS configuration or receives DHCP configuration MUST NOT issue mDNS requests or respond to them (from the configured interface) unless it receives an mDNS Enable option. In this case, the host which SHOULD issue mDNS requests respond to them on interface upon which the DHCP option was received, according to the parameters provided in the mDNS Enable option. 4.0 Comparison between the Enable mDNS and search list approaches Both options allow an administrator to explicitly enable the use of mDNS - leaving it disabled by default when DHCP configuration occurs. The Domain Search Option [4] provides a much needed mechanism for configuring resolvers' search list parameter using DHCP. The current mDNS specification [5] interprets the domain search list (whether configured manually or via the Domain Search Option) to control mDNS behavior. Hosts respond to mDNS requests and issue mDNS requests only if the domain name ".local.arpa" is present. This domain name implies special treatment - requests for this name are always sent using mDNS, never via DNS. This approach implies the following: - mDNS requests will only be sent for names ending in '.local.arpa' - Names ending in '.local.arpa' will not be accessible via DNS though they are via mDNS. - A mDNS server must fashion a name by appending '.local.arpa' to its domain name instead of responding to its own actual domain name. - Use of the search list to control DNS transmission behavior and especially to enable local services (the mDNS responder) is highly unusual and will surely confuse many users and administrators. In contrast the mDNS Enable option has none of these implications. The mDNS Enable option additionally specifies which multicast scope to use, which could be useful in the future if mDNS is standardized to use scopes beyond LINKLOCAL. The only way this could be achieved in the future by the 'search list' approach would be to define a new domain name for special treatment, like 'local2.arpa' for the IPv4 Local Scope, for example. E. Guttman Expires: 27 December 2001 [Page 4] Internet Draft DHC Option to Enable mDNS June 2001 4.1 Conclusion The search list option requires special case treatment of certain domain names, overloads the notion of a DNS search list, creates arbitrary limitations on which names can be used with mDNS and how and poses challenges for extensibility of mDNS to scopes beyond LINKLOCAL. The Enable mDNS option approach should be adopted as the mechanism to control mDNS host behavior instead. 5.0 IANA Considerations New values for the S1 and S2 fields will be determined by IETF Consensus. [9] An IANA registry will be set up listing the assigned values. A new DHC option ID assignment will only occur if this document is accepted after review by an IETF working group (in this case either DHC or DNSEXT) and the IESG. This is the policy for all proposed DHC options. [10] 6.0 Security Considerations Security considerations for mDNS are discussed in [5]. Security considerations for DHCP are considered in [2] and addressed in [11]. The mDNS enable option itself could be abused by an attacker to enable the use of mDNS on a network where the network administrators do not intend it to be used. Once enabled, an attacker's mDNS server could respond to requests for names it has no authority for, masquerading as them or misdirecting hosts to use some other host. As hosts may use mDNS to resolve names which the DNS provides no results, an attacker could respond to non-existent names (such as resulting from slightly mistyped URLs, etc). Acknowledgments The author thanks kre and Bernard Aboba for their comments. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [3] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [4] Aboba, B., "DHCP Domain Search Option", draft-aboba-dhc- domsearch-02.txt, June 2001, A work in progress E. Guttman Expires: 27 December 2001 [Page 5] Internet Draft DHC Option to Enable mDNS June 2001 [5] Ebisov, L., Aboba, B., Thaler, D., "Multicast DNS", draft-ietf- dnsext-01.txt, June 2001, A work in progress. [6] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987. [7] Hattig, M., "ZeroConf Requirements", draft-ietf-zeroconf-reqts- 08.txt, June 2001, A work in progress [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [10] Droms, R., "Procedures for New DHCP Options", BCP 29, RFC 2939, September 2000. [11] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", RFC 3118, June 2001. Author's Address Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany Phone: +49 7263 911 701 Messages: +49 6221 356 202 Email: erik.guttman@sun.com E. Guttman Expires: 27 December 2001 [Page 6]