draft-ietf-dnsext-mdns-02.txt   draft-ietf-dnsext-mdns-03.txt 
DNSEXT Working Group Levon Esibov DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler Category: Standards Track Dave Thaler
<draft-ietf-dnsext-mdns-02.txt> Microsoft <draft-ietf-dnsext-mdns-03.txt> Microsoft
14 July 2001 18 July 2001
Multicast DNS Multicast DNS
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet- Drafts. may also distribute working documents as Internet- Drafts.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Today, with the rise of home networking, there are an increasing number Today, with the rise of home networking, there are an increasing number
of ad-hoc networks operating without a DNS server. In order to allow DNS of ad-hoc networks operating without a DNS server. In order to allow DNS
name resolution in such environments, the use of a multicast DNS is name resolution in such environments, the use of a multicast DNS is
proposed. proposed.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
2. Name resolution using multicast DNS ................... 3 2. Name resolution using multicast DNS ................... 3
2.1 Behavior of the sender and responder ............ 4 2.1 Behavior of the sender and responder ............ 4
3. Usage model ........................................... 6 3. Usage model ........................................... 7
4. Sequence of events .................................... 8 4. Sequence of events .................................... 8
5. Conflict resolution ................................... 8 5. Conflict resolution ................................... 8
5.1 Considerations for multiple interfaces .......... 10 5.1 Considerations for multiple interfaces .......... 10
5.2 API issues ...................................... 11 5.2 API issues ...................................... 11
6. IANA considerations ................................... 12 6. IANA considerations ................................... 12
7. ARPA domain considerations ............................ 12 7. ARPA domain considerations ............................ 12
8. References ............................................ 12 8. References ............................................ 13
9. Security considerations ............................... 13 9. Security considerations ............................... 14
ACKNOWLEDGMENTS .............................................. 14 ACKNOWLEDGMENTS .............................................. 14
AUTHORS' ADDRESSES ........................................... 15 AUTHORS' ADDRESSES ........................................... 15
Intellectual Property Statement .............................. 15 Intellectual Property Statement .............................. 15
Full Copyright Statement ..................................... 16 Full Copyright Statement ..................................... 16
1. Introduction 1. Introduction
Multicast DNS enables DNS name resolution in the scenarios when Multicast DNS enables DNS name resolution in the scenarios when
conventional DNS name resolution is not possible. Namely, when there are conventional DNS name resolution is not possible. Namely, when there are
no DNS servers available on the network or available DNS servers do not no DNS servers available on the network or available DNS servers do not
skipping to change at page 3, line 37 skipping to change at page 3, line 37
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [1]. described in [1].
2. Name resolution using Multicast DNS 2. Name resolution using Multicast DNS
This extension to the DNS protocol consists of a single change to the This extension to the DNS protocol consists of a single change to the
method of use, and no change to the current format of DNS packets. method of use, and no change to the current format of DNS packets.
Namely, this extension allows multicast DNS queries to be sent to and Namely, this extension allows multicast DNS queries to be sent to and
received on port 53. received on port 53.
The messages are sent using the LINKLOCAL addresses [2] for IPv4 and This extension allows multicast DNS queries to be sent to and received
IPv6 (below referred as the LINKLOCAL address), which are yet to be on port 53 using a LINKLOCAL address [2] for IPv4 and the "solicited
assigned by IANA. LINKLOCAL addresses are used to prevent propagation of name" LINKLOCAL multicast addresses for IPv6. LINKLOCAL addresses are
multicast DNS traffic across routers, potentially flooding the network. used to prevent propagation of multicast DNS traffic across routers,
potentially flooding the network.
Propagation of multicast DNS packets within the local subnet is Propagation of multicast DNS packets within the local subnet is
considered sufficient to enable DNS name resolution in small adhoc considered sufficient to enable DNS name resolution in small adhoc
networks. The assumption is that if a network has a router, then the networks. The assumption is that if a network has a router, then the
network either has a DNS server or the router can function as a DNS network either has a DNS server or the router can function as a DNS
proxy, possibly implementing dynamic DNS. proxy, possibly implementing dynamic DNS.
In the future, mDNS may be defined to support greater than LINKLOCAL In the future, mDNS may be defined to support greater than LINKLOCAL
multicast scope. This would occur if LINKLOCAL mDNS deployment is multicast scope. This would occur if LINKLOCAL mDNS deployment is
successful, the assumption that mDNS is not needed in multiple subnets successful, the assumption that mDNS is not needed in multiple subnets
proves incorrect, and multicast routing becomes ubiquitous. For proves incorrect, and multicast routing becomes ubiquitous. For
example, it is not clear that this assumption will be valid in large
example, it is not clear that this assumption will be valid in large
adhoc networking scenarios. adhoc networking scenarios.
Once we have experience in mDNS deployment in terms of administrative Once we have experience in mDNS deployment in terms of administrative
issues, usability and impact on the network it will be possible issues, usability and impact on the network it will be possible
reevaluate which multicast scopes are appropriate for use with mDNS. reevaluate which multicast scopes are appropriate for use with mDNS.
2.1. Behavior of the sender and responder 2.1. Behavior of the sender and responder
For the purpose of this document a host that sends a multicast query is For the purpose of this document a host that sends a multicast query is
called a "sender", while a host that listens to (but not necessarily called a "sender", while a host that listens to (but not necessarily
skipping to change at page 4, line 40 skipping to change at page 4, line 41
query in order to assure themselves that the query has been received by query in order to assure themselves that the query has been received by
a host capable of responding to the query. a host capable of responding to the query.
Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be
repeated more often than once per second to reduce unnecessary network repeated more often than once per second to reduce unnecessary network
traffic. The delay between attempts should be randomised so as to avoid traffic. The delay between attempts should be randomised so as to avoid
synchronisation effects. synchronisation effects.
2.1.2. Behavior of responders 2.1.2. Behavior of responders
A responder listens on port 53 on the LINKLOCAL address. Responders MUST A responder listens on port 53 on the LINKLOCAL address. The IPv6
respond to multicast queries to those and only those names for which LINKLOCAL address a given responder listens to, and to which a sender
they are authoritative. As an example, computer sends, is a link-local multicast address formed as follows: The name of
the resource record in question is expressed in its canonical form (see
RFC 2535 [15], section 8.1), which is uncompressed with all alphabetic
characters in lower case. The first label of the resource record name
is then hashed using the MD5 algorithm (see RFC 1321 [16]). The first
32 bits of the resultant 128-bit hash is then appended to the prefix
FF02:0:0:0:0:2::/96 to yield the 128-bit "solicited name multicast
address". (Note: this procedure is intended to be the same as that
specified in section 3 of [14]) A responder that listens for queries
for multiple names will necessarily listen to multiple of these
solicited name multicast addresses.
Responders MUST respond to multicast queries to those and only those
names for which they are authoritative. As an example, computer
"host.example.com.local.arpa." is authoritative for the domain "host.example.com.local.arpa." is authoritative for the domain
"host.example.com.local.arpa.". On receiving a multicast DNS A record "host.example.com.local.arpa.". On receiving a multicast DNS A record
query for the name "host.example.com.local.arpa." such a host responds query for the name "host.example.com.local.arpa." such a host responds
with A record(s) that contain IP address(es) in the RDATA of the record. with A record(s) that contain IP address(es) in the RDATA of the record.
In conventional DNS terminology a DNS server authoritative for a zone is In conventional DNS terminology a DNS server authoritative for a zone is
authoritative for all the domain names under the zone root except for authoritative for all the domain names under the zone root except for
the branches delegated into separate zones. Contrary to conventional DNS the branches delegated into separate zones. Contrary to conventional DNS
terminology, a responder is authoritative only for the zone root. For terminology, a responder is authoritative only for the zone root. For
example the host "host.example.com.local.arpa." is not authoritative for example the host "host.example.com.local.arpa." is not authoritative for
skipping to change at page 8, line 19 skipping to change at page 8, line 30
1. If a sender needs to resolve a query for a name 1. If a sender needs to resolve a query for a name
"host.example.com.local.arpa", then it sends a multicast query to the "host.example.com.local.arpa", then it sends a multicast query to the
LINKLOCAL multicast address. LINKLOCAL multicast address.
2. A responder responds to this query only if it is authoritative 2. A responder responds to this query only if it is authoritative
for the domain name "host.example.com.local.arpa". The responder sends for the domain name "host.example.com.local.arpa". The responder sends
a response to the sender via unicast over UDP. a response to the sender via unicast over UDP.
3. Upon the reception of the response, the sender verifies that the Hop 3. Upon the reception of the response, the sender verifies that the Hop
Limit field in IPv6 header or TTL field in IPv4 header (depending on Limit field in IPv6 header or TTL field in IPv4 header (depending on
the protocol used) of the response is set to 255. If the destination the protocol used) of the response is set to 255. The sender then
address is a LINKLOCAL address, then the sender verifies use of a verifies compliance with the addressing requirements for IPv4 [6]
LINKLOCAL source address. If these conditions are met, then the sender and IPv6 [9]. If these conditions are met, then the sender
uses and caches the returned response. If not, then the sender ignores uses and caches the returned response. If not, then the sender ignores
the response and continues waiting for the response. the response and continues waiting for the response.
5. Conflict resolution 5. Conflict resolution
There are some scenarios when multiple responders MAY respond to the There are some scenarios when multiple responders MAY respond to the
same query. There are other scenarios when only one responder may same query. There are other scenarios when only one responder may
respond to a query. Resource records for which the latter queries are respond to a query. Resource records for which the latter queries are
submitted are referred as UNIQUE throughout this document. The submitted are referred as UNIQUE throughout this document. The
uniqueness of a resource record depends on a nature of the name in the uniqueness of a resource record depends on a nature of the name in the
skipping to change at page 9, line 18 skipping to change at page 9, line 28
- starts up or - starts up or
- is configured to respond to the multicast DNS queries on - is configured to respond to the multicast DNS queries on
some interface or some interface or
- is configured to respond to the multicast DNS queries using - is configured to respond to the multicast DNS queries using
additional UNIQUE DNS records. additional UNIQUE DNS records.
Below we describe the data to be specified in the dynamic update Below we describe the data to be specified in the dynamic update
request: request:
Header section Header section
contains values according to [RFC 2136]. contains values according to RFC 2136 [11].
Zone section Zone section
The zone name in the zone section MUST be set to the name of the The zone name in the zone section MUST be set to the name of the
UNIQUE record. The zone type in the zone section MUST be set to UNIQUE record. The zone type in the zone section MUST be set to
SOA. The zone class in the zone section MUST be set to the class of SOA. The zone class in the zone section MUST be set to the class of
the UNIQUE record. the UNIQUE record.
Prerequisite section Prerequisite section
This section MUST contain a record set whose semantics are This section MUST contain a record set whose semantics are
described in RFC 2136 [11], Section 2.4.3 "RRset Does Not Exist", described in RFC 2136 [11], Section 2.4.3 "RRset Does Not Exist",
skipping to change at page 13, line 40 skipping to change at page 13, line 51
[11] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates in [11] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates in
the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[12] Huston, G., "Management Guidelines & Operational Requirements for [12] Huston, G., "Management Guidelines & Operational Requirements for
the Internet Infrastructure Domain ("ARPA")", Internet draft (work the Internet Infrastructure Domain ("ARPA")", Internet draft (work
in progress), draft-iab-arpa-02.txt, May 2001. in progress), draft-iab-arpa-02.txt, May 2001.
[13] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic Socket [13] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic Socket
Interface Extensions for IPv6", RFC 2553, March 1999. Interface Extensions for IPv6", RFC 2553, March 1999.
[14] Crawford, Matt, "IPv6 Node Information Queries", Internet draft
(work in progress), draft-ietf-ipn-gwg-icmp-name-lookups-07.txt,
August 2000.
[15] Eastlake, D., "Domain Name System Security Extensions", RFC 2535,
March 1999.
[16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
9. Security Considerations 9. Security Considerations
This draft does not prescribe a means of securing the multicast DNS This draft does not prescribe a means of securing the multicast DNS
mechanism. It is possible that hosts will allocate conflicting names for mechanism. It is possible that hosts will allocate conflicting names for
a period of time, or that non-conforming hosts will attempt to deny a period of time, or that non-conforming hosts will attempt to deny
service to other hosts by allocating the same name. Such attacks also service to other hosts by allocating the same name. Such attacks also
allow nodes to receive packets destined for other nodes. The protocol allow nodes to receive packets destined for other nodes. The protocol
reduces the exposure to such threats in the absence of authentication by reduces the exposure to such threats in the absence of authentication by
ignoring multicast DNS query response packets received from off-link ignoring multicast DNS query response packets received from off-link
senders. senders.
skipping to change at page 14, line 4 skipping to change at page 14, line 25
mechanism. It is possible that hosts will allocate conflicting names for mechanism. It is possible that hosts will allocate conflicting names for
a period of time, or that non-conforming hosts will attempt to deny a period of time, or that non-conforming hosts will attempt to deny
service to other hosts by allocating the same name. Such attacks also service to other hosts by allocating the same name. Such attacks also
allow nodes to receive packets destined for other nodes. The protocol allow nodes to receive packets destined for other nodes. The protocol
reduces the exposure to such threats in the absence of authentication by reduces the exposure to such threats in the absence of authentication by
ignoring multicast DNS query response packets received from off-link ignoring multicast DNS query response packets received from off-link
senders. senders.
In all received responses, the Hop Limit field in IPv6 and the TTL field In all received responses, the Hop Limit field in IPv6 and the TTL field
in IPv4 are verified to contain 255, the maximum legal value. Since in IPv4 are verified to contain 255, the maximum legal value. Since
routers decrement the Hop Limit on all packets they forward, received routers decrement the Hop Limit on all packets they forward, received
packets containing a Hop Limit of 255 must have originated from a packets containing a Hop Limit of 255 must have originated from a
neighbor. Packets destined for a LINKLOCAL address are verified to have neighbor.
been sent from a LINKLOCAL source address.
These threats are most serious in wireless networks such as 802.11, These threats are most serious in wireless networks such as 802.11,
since attackers on a wired network will require physical access to the since attackers on a wired network will require physical access to the
home network, while wireless attackers may reside outside the home. home network, while wireless attackers may reside outside the home.
Link-layer security will serve to secure mDNS against the above threats Link-layer security will serve to secure mDNS against the above threats
if it is available. For example, where 802.11 "Wired Equivalency if it is available. For example, where 802.11 "Wired Equivalency
Privacy" (WEP) [10] is implemented, a casual attacker is likely to be Privacy" (WEP) [10] is implemented, a casual attacker is likely to be
deterred from gaining access to the home network. deterred from gaining access to the home network.
The mechanism specified in this draft does not require use of the The mechanism specified in this draft does not require use of the
skipping to change at page 16, line 30 skipping to change at page 16, line 33
perpetual and will not be revoked by the Internet Society or its perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Expiration Date Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-02.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-03.txt>, and expires
January 30, 2002. February 1, 2002.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/