Internet DRAFT - draft-guttman-dhc-mdns-enable
draft-guttman-dhc-mdns-enable
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]
