Internet Engineering Task Force Erik Guttman INTERNET DRAFT Sun Microsystems Intended for Standards Track July 20, 2001 Expires in six months DHCP mDNS Enable Option draft-guttman-dhc-mdns-enable-01.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 [RFC 2026]. 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 [RFC 2131] allows network administrators to determine host configuration parameters. This document defines a new DHCP option [RFC 2132] specifically to enable and control multicast DNS behavior. This is an alternative to using the Domain Search Option [DOMSEARCH] to configure mDNS behavior, as has been proposed. 1.0 Introduction When the DNS protocol [RFC 1034] is transported via multicast (termed 'mDNS'), it is well suited for ad-hoc network environments lacking E. Guttman Expires: 20 January 2002 [Page 1] Internet Draft DHC Option to Enable mDNS July 2001 administration and services [ZEROCONF]. 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 [ZEROCONF]). 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. This document does not specify host behavior if mDNS support can be manually configured. An alternative approach suggested in [LINKLOCAL-MDNS] is to use the domain search list (obtained, for instance, using the Domain Search Option [DOMSEARCH]) for the same purpose. The differences between these approaches are discussed below. 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 [RFC 2119]. Other terms used in this document are defined in the DNS specification [RFC 1034]. E. Guttman Expires: 20 January 2002 [Page 2] Internet Draft DHC Option to Enable mDNS July 2001 2.0 DHCP Enable mDNS Option Format Code Len Scope +-----+-----+-----+-----+ | TBD | n | Scp | ... +-----+-----+-----+-----+ 2.1 Specifying the multicast scope and order to use DNS and mDNS The value of n is set to the number of Scp entries which follow. Each Scp entry is one byte long and is interpreted separately. The value of 'Scp' determines the scope of the multicast used by mDNS. This field has only two defined values at the present time. Scp = 0 means that unicast DNS (to DNS servers whose locations are known to the resolver) is to be used. Scp = 1 indicates that LINKLOCAL multicast DNS be used, as defined in [LINKLOCAL-MDNS]. If mDNS is specified for additional multicast scopes in the future, additional values for the bits in Scp may be defined. These will be associated with standards track specifications of multicast DNS at that scope. The order in which the Scp values are given is the order in which hosts attempt to get a response for a given request. Only if the replies are not returned by the mechanism at one scope, is the next mechanism in the list attempted. 3.0 mDNS host behavior mDNS behavior depends upon configuration obtained by DHCP. As noted in Section 3.6 of [RFC 2131], "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. A mDNS enabled host SHOULD issue requests and respond to them from each multicast enabled interface, by default, if it lacks any DNS or DHCP configuration. A mDNS enabled host which has manual DNS configuration or receives E. Guttman Expires: 20 January 2002 [Page 3] Internet Draft DHC Option to Enable mDNS July 2001 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. If a host offers manual configuraration to enable mDNS on an interface, the host's behavior is left unspecified by this document. 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 [DOMSEARCH] provides a much needed mechanism for configuring resolvers' search list parameter using DHCP. The LINKLOCAL mDNS specification [LINKLOCAL-MDNS] 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: 20 January 2002 [Page 4] Internet Draft DHC Option to Enable mDNS July 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 Scp fields will be determined by IETF Consensus. [RFC 2434] 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. [RFC 2939] 6.0 Security Considerations Security considerations for LINKLOCAL multicast DNS are discussed in [LINKLOCAL-MDNS]. Security considerations for DHCP are considered in [RFC 2131] and addressed in [RFC 3118]. 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, Bernard Aboba and Stuart Cheshire for their comments. References [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. E. Guttman Expires: 20 January 2002 [Page 5] Internet Draft DHC Option to Enable mDNS July 2001 [DOMSEARCH] Aboba, B., "DHCP Domain Search Option", draft-aboba-dhc- domsearch-02.txt, June 2001, A work in progress [RFC 1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987. [ZEROCONF] Hattig, M., "ZeroConf Requirements", draft-ietf-zeroconf- reqts-08.txt, June 2001, A work in progress [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [LINKLOCAL-MDNS] Ebisov, L., Aboba, B., Thaler, D., "Multicast DNS", draft-ietf-dnsext-01.txt, June 2001, A work in progress. [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC 2939] Droms, R., "Procedures for New DHCP Options", BCP 29, RFC 2939, September 2000. [RFC 3118] 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: 20 January 2002 [Page 6]