One document matched: draft-aboba-dnsext-mdns-00.txt
NETWORK Working Group Bernard Aboba
INTERNET-DRAFT Dave Thaler
Category: Standards Track Levon Esibov
<draft-aboba-dnsext-mdns-00.txt> Microsoft
March 9, 2000
Multicast DNS
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 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.
1. Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
2. Abstract
Today, with the rise of home networking, there are an increasing number
of small networks operating without a DNS server. In order to allow DNS
name resolution in such environments, the use of a multicast DNS is
proposed.
With wide deployment of the hosts registered with IPv6 addresses by
routers, in the absence of the DHCP server multicast DNS is proposed to
be used to discover available DNS servers, that will be used for unicast
DNS.
3. Introduction
Multicast DNS enables DNS name resolution in the scenarios when
conventional DNS name resolution is not possible. Namely, when there are
no DNS servers available on the network or available DNS servers do not
provide the name resolution for the names of the hosts on the local
Aboba, Esibov & Thaler Standards Track [Page 1]
INTERNET-DRAFT Multicast DNS 9 March 2000
network. The latter case, for example, corresponds to a scenario when a
home network that doesn't have a DNS server is connected to the Internet
through an ISP and the home network hosts are configured with the ISPÆs
DNS server for the name resolution. The ISPÆs DNS server provides the
name resolution for the names registered on the Internet, but doesn't
provide name resolution for the names of the hosts on the home network.
With wide deployment of the hosts autoconfigured with IPv6 addresses by
routers, in the absence of the DHCP servers, multicast DNS is proposed
to be used to discover available DNS server, that will be used for the
conventional unicast DNS name resolution.
This document discusses multicast DNS, an extension to the DNS protocol
which consists of a single change to the method of use, and no change to
the format of DNS packets.
4. Terminology
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [1].
5. Name resolution using Multicast DNS
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. Namely, this extension allows multicast DNS queries to be sent
to and received on port 53 using IP multicast addresses. These addresses
include four addresses (two Local scope addresses for Ipv4 and IPv6 and
two LINKLOCAL addresses for IPv4 and IPv6) in this document referred as
Local Scope and LINKLOCAL [2] mDNS addresses.
The IPv4 Local Scope address is 239.255.255.253. The other three
addresses are yet to be assigned by IANA.
In order to prevent a DNS server from recursive resolution of the
multicast DNS queries, the RD (Recursion Desired) bit in the Header
section of the query MUST be set to 0.
In order to improve scalability, a resolver configured to use multicast
DNS for name resolution always attempts to resolve a multicast query by
sending it to the LINKLOCAL mDNS addresses prior to sending it to the
Local Scope mDNS addresses. If a query sent to the LINKLOCAL mDNS
addresses is not positively resolved (ôpositively resolvedö refers in
this document to the response with the RCODE set to 0) during a limited
amount of time, then resolver SHOULD resend query to a Local Scope mDNS
addresses. Resolvers MAY repeat the transmission of a query in order to
assure themselves that the query has been received by any hosts capable
of answering the query.
Aboba, Esibov & Thaler Standards Track [Page 2]
INTERNET-DRAFT Multicast DNS 9 March 2000
DNS resolvers configured to use multicast DNS for name resolution listen
on port 53 on the LINKLOCAL and Local Scope mDNS addresseses. Resolvers
MUST respond to those queries for which they have a positive
authoritative answer. The resolver responds to such queries after a
random delay in the interval [0,MAX_DELAY). MAX_DELAY MUST never be
longer than the requester's retransmission interval. If a duplicate
response is heard by a resolver during the random delay, the resolver
MUST suppress its own response. The authoritative response MUST contain
AA (Authoritative Answer) bit set to 1. As an example, computer
host.example.com. that receives a multicast DNS query for an A record
for the name host.example.com., will respond with an A record that
contains its IP address in the RDATA of the record.
In addition to this, the resolvers SHOULD respond to the queries if
cached data can be used. Such response contains a AA (Authoritative
Answer) bit set to 0.
Resolvers MUST anticipate receiving no replies to some multicasted
queries, in the event that no multicast-enabled clients are available
within the multicast scope, or in the event that no positive non-null
responses exist to the transmitted query.
If no positive response is received, a resolver treats it as a response
that no records of the specified type and class for the specified name
exist (NXRRSET), which should be cached according to RFC 2308 [15].
Resolvers MUST anticipate receiving multiple replies to the same
multicasted query, in the event that several multicast DNS enabled hosts
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 DNS server would, ordinarily.
Auto-configured hosts:
Reference [3] describes how hosts that are configured to use DHCP,
but cannot find a DHCP server, may auto-configure their IPv4 address
within the 169.254/16 prefix. Such hosts may use multicast DNS as
their name resolution mechanism.
However, since mDNS queries from an auto-configured host will
originate from a linklocal scope unicast addresses, it may not be
possible for a host located on another subnet to answer them, since
the source address is not routable. Thus, the result would be
propagation of useless traffic. As a result, an auto-configured
IPv4 address host MAY send multicast DNS queries to IPv4 LINKLOCAL
mDNS address, and MUST NOT send multicast DNS queries to the IPv4
Local Scope mDNS address. Similarly, a host with an auto-configured
address MUST only listen for multicast DNS queries on the IPv4
LINKLOCAL mDNS address.
An auto-configured host that subsequently locates a DHCP server will
transition to behaving as though it was configured via DHCP, as
described above.
Aboba, Esibov & Thaler Standards Track [Page 3]
INTERNET-DRAFT Multicast DNS 9 March 2000
6. Name conflicts
It is required to verify the uniqueness of the host DNS name when it is
configured to use multicast DNS for the name resolution. When a host
configured to use multicast DNS is joined to a network and/or when its
name changes or when a host becomes configured to use multicast DNS for
name resolution, the resolver sends a multicast A type query with its
own name to discover whether there is any host (within the multicast
scope) with the same name. All the responses with AA (Authoritative
Answer) bit set to 0 MUST be ignored. If the query is not positively
resolved then host starts using its name. If the query is positively
resolved, (and AA (Authoritative Answer) bit is set to 1 in the
response) then the host should verify that the IP addresses specified
in the response are its own IP addresses, possibly from another adapter.
If the host verifies it, then it starts using its name. If the host
canÆt match the returned A records to its IP addresses, then the host
MUST not use the name. This means that the host will not respond
authoritatively to the multicast queries to that name as well as will
not respond to other multicast queries with the records that contain in
RDATA name in conflict (for example, PTR record).
Although the name conflict is detected when a host joins a network (as
described above), such name conflict detection mechanism doesnÆt
prevent name conflicts when ômulticast scopeö changes. As an example of
such change, a router, connecting two networks may be reconfigured to
allow packages sent to local scope addresses to pass through. Similar
examples may consider two separate networks being connected by a router
or bridge. Name conflict in such situation is detected when a host
receives an authoritative multicast response to an A query for its name
or when a client receives more than one authoritative response to a
multicast A type query that it sent. In this situation such client will
send using unicast the first response (preserving the AA (Authoritative
Answer) bit) that it received to the host(s) that authoritatively
responded to the query after the first response was received. A host
that receives a response for a query for itÆs own name, even if it
didnÆt send such query, behaves as if it sent this query, meaning that
the host will stop using the name as it is specified above if the AA bit
is set to 1 and the IP address specified in the response is not its own
IP address.
7. DNS resolver configuration
In general, a DNS resolver may be configured to use for name resolution
only unicast DNS, or only multicast DNS, or both. Following the
notations introduced in the RFC 1001 [16], every DNS resolver may be
configured as one of the following four types of nodes:
p-node û DNS resolver sends only unicast queries. Resolver doesnÆt
listen on multicast addresses.
Aboba, Esibov & Thaler Standards Track [Page 4]
INTERNET-DRAFT Multicast DNS 9 March 2000
h-node û DNS resolver sends unicast query. If the query is not
positively resolved, then it submits the multicast query. Resolver
listens on multicast addresses.
m-node û DNS resolver sends multicast query. If the query is not
positively resolved, then it submits the unicast query. Resolver
listens on multicast addresses.
b-node û DNS resolver sends only multicast queries. Clients listen
on multicast addresses.
Depending on the environments where host is used, different
configurations could be more or less appropriate. While multicast DNS
was designed for use within small networks, it is essential that its
deployment not adversely affect enterprise networks.
A Multicast DNS Node Type DHCP Option [4] enables network
administrators to appropriately configure resolvers to prevent flooding
caused by multicast DNS queries in the administered large networks.
A host that is configured via DHCP, but does not receive a Multicast DNS
Node Type DHCP Option MUST NOT use multicast DNS for name resolution
unless otherwise configured. Thus, it behaves as though it had been
configured as a P-node.
If a DNS server is running on a host, the DNS resolver on such a host
MUST be configured as a p-node, to prevent a DNS resolver from listening
on port 53 and intercepting DNS queries directed to the DNS server.
8. DNS server discovery in IPv6
Multicast DNS MAY be used for the DNS server discovery. This behavior is
expected when IPv6 gets widely deployed in the scenarios where DHCPv6 is
not available. In the presence of a DHCPv6 server it is expected that
administrators will configure the hosts with the DNS servers using the
DNS server configuration option.
A host that is not configured with a DNS server regardless of the
configuration of its Multicast DNS node type MAY attempt to discover a
preferred DNS server by sending a multicast SRV [17] query as described
below. If no response is received, then the host MUST behave according
to its multicast DNS node type configuration, but MAY repeat a multicast
SRV query to discover DNS server on a periodic basis. If a response is
received the host starts using discovered DNS servers for the name
resolution, but it continues to behave according to its multicast DNS
node type configuration.
Aboba, Esibov & Thaler Standards Track [Page 5]
INTERNET-DRAFT Multicast DNS 9 March 2000
To minimize the network load and load on the resolvers that listen to
the multicast DNS queries, the following algorithm will be used if a
resolver attempts a discovery of a DNS server:
1. send a query to the IPv6 LINKLOCAL mDNS address
2. if a query sent to the IPv6 LINKLOCAL mDNS address is not positively
resolved during a limited amount of time, then resolver SHOULD resend
query to the Local Scope All_DNS_servers mDNS address. Resolvers MAY
repeat the transmission of a query in order to assure themselves that
the query has been received by a DNS servers capable of answering the
query.
DNS servers that are configured to be discovered through multicast DNS
queries, MUST listen on the IPv6 LINKLOCAL and IPv6 Local Scope
All_DNS_servers mDNS addresses. They respond to the same multicast
address the query was sent.
DNS server discovery using SRV multicast query
DNS server location information is to be stored using DNS Service
Location Record (SRV)[17]. The data in a SRV record contains the DNS
name of the DNS server, corresponding Port number, and Priority and
Weight fields that enable the resolver to choose an appropriate
server from multiple servers according to the algorithm described in
the SRV protocol[17]. The name of this record is always:
_dns._udp.lcl
where ôdnsö indicates the service provided by the server, and "udp"
is a protocol that should be used to contact a DNS server. This
document doesnÆt imply to change the current standards specifying
when udp and tcp protocols should/should not be used by DNS resolvers
and servers.
Every DNS server that is configured to be discovered through the
multicast DNS query must be authoritative for the zone ôlclö.
Presence of the SRV records for ô_dns._udp.lclö enables resolvers to
find the DNS servers using multicast DNS query. As an example, a
resolver that searches for a DNS server will submit a multicast DNS
query for a set of SRV records with owner name:
_dns._udp.lcl
The resolver will receive the list of SRV records published in DNS
that satisfy the requested criteria. The following is an example of
such record:
_dns._udp.lcl IN SRV 0 0 53 dnsserver.example.net.
The set of returned records may contain multiple records in the case
where multiple DNS servers serve the same network.
Aboba, Esibov & Thaler Standards Track [Page 6]
INTERNET-DRAFT Multicast DNS 9 March 2000
8. IANA Considerations
Authors will contact IANA to reserve:
1. LINKLOCAL IPv4 and IPv6 addresses
2. Local Scope IPv6 address
3. Local Scope All_DNS_servers IPv6 address.
Authors of the draft will contact IANA to reserve a top level domain
ôlclö.
9. Security Considerations
This draft does not prescribe a means of securing the multicast DNS
mechanism. It is possible that hosts will allocate conflicting names for
a period of time, or that non-conforming hosts will attempt to deny
service to other hosts by allocating the same name.
These threats are most serious in wireless networks such as 802.11,
since attackers on a wired network will require physical access to the
home network, while wireless attackers may reside outside the home. In
order to provide for privacy equivalent to a wired network, the 802.11
specification provides for RC4-based encryption. This is known as the
"Wired Equivalency Privacy" (WEP) specification. Where WEP is
implemented, an attacker will need to obtain the WEP key prior to
gaining access to the home network.
The multicast DNS server discovery mechanism introduces another type of
denial of service attack on the DNS servers by sending multicast queries
to the DNS server, but this type is not worse than any other and does
not add additional complication.
All security considerations related to DNS SRV records are inherited by
this document. See the security considerations section in [17] for more
details.
10. Acknowledgements
Authors would like to thank Eric Gutman for productive discussion and
his contribution to the specification of the multicast DNS.
Aboba, Esibov & Thaler Standards Track [Page 7]
INTERNET-DRAFT Multicast DNS 9 March 2000
11. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 (425) 936-6605
EMail: bernarda@microsoft.com
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 (425) 703-8835
EMail: dthaler@microsoft.com
Levon Esibov
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: levone@microsoft.com
12. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[3] Troll, R., "Automatically Choosing an IP Address in an Ad-Hoc
IPv4 Network", Internet draft (work in progress), draft-ietf-dhc-
ipv4-autoconfig-04.txt, April 1999.
[4] Aboba, B., Esibov, L, Thaler, D., "Multicast DNS Configuration
Option", Internet draft (work in progress), draft-aboba-dhc-mdns-
conf-00.txt, February 2000.
[5] Braden, R., "Requirements for Internet Hosts -- Application and
Support", RFC 1123, October 1989.
[6] Hanna, S., Patel, B., and Shah, M., "Multicast Address Dynamic
Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
Aboba, Esibov & Thaler Standards Track [Page 8]
INTERNET-DRAFT Multicast DNS 9 March 2000
[7] Woodcock, B., Manning, B., "Multicast Discovery of DNS Services",
Internet draft (work in progress), draft-manning-multicast-
dns-01.txt, October 1998.
[8] Mockapetris, P., "Domain Names - Implementation and Specification",
RFC 1035, November 1987.
[9] IANA, "Single-source IP Multicast Address Range",
http://www.isi.edu/in-notes/iana/assignments/single-source-
multicast, October 1998.
[10] Handley, M., Thaler, D., and Kermode, R., "Multicast-Scope Zone
Announcement Protocol (MZAP)", Work in progress, draft-ietf-mboned-
mzap-06.txt, December, 1999.
[11] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., Lear,
E., "Address Allocation for Private Internets", RFC 1918, February,
1996.
[13] Vixie, P., et. al., "Dynamic Updates in the Domain Name System (DNS
UPDATE)", RFC 2136, April, 1997.
[14] Troll, R., "DHCP Option to Disable Stateless Auto-
Configuration in IPv4 Clients", RFC 2563, May 1999.
[15] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
RFC 2308, March 1998.
[16] "PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT:
CONCEPTS AND METHODS", RFC 1001, March, 1987.
[17] Gulbrandsen , A., . Vixie, P., Esibov, L. ôA DNS RR for specifying
the location of services (DNS SRV)ö, RFC 2782, February 2000.
13. 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 implmentation 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
Aboba, Esibov & Thaler Standards Track [Page 9]
INTERNET-DRAFT Multicast DNS 9 March 2000
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."
14. Expiration Date
This memo is filed as <draft-aboba-dnsext-mdns-00.txt>, and expires
September 9, 2000.
Aboba, Esibov & Thaler Standards Track [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-22 13:53:14 |