draft-ietf-dnsext-mdns-03.txt   draft-ietf-dnsext-mdns-04.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-03.txt> Microsoft <draft-ietf-dnsext-mdns-04.txt> Microsoft
18 July 2001 13 September 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 11 skipping to change at page 2, line 11
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 ........................................... 7 3. Usage model ........................................... 7
3.1 mDNS configuration .............................. 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 ...................................... 12
6. IANA considerations ................................... 12 6. IANA considerations ................................... 12
7. ARPA domain considerations ............................ 12 7. ARPA domain considerations ............................ 12
8. References ............................................ 13 8. References ............................................ 13
9. Security considerations ............................... 14 9. Security considerations ............................... 14
ACKNOWLEDGMENTS .............................................. 14 ACKNOWLEDGMENTS .............................................. 15
AUTHORS' ADDRESSES ........................................... 15 AUTHORS' ADDRESSES ........................................... 15
Intellectual Property Statement .............................. 15 Intellectual Property Statement .............................. 16
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
provide name resolution for the names of the hosts on the local network. provide name resolution for the names of the hosts on the local network.
The latter case, for example, corresponds to a scenario when a network The latter case, for example, corresponds to a scenario when a network
that doesn't have a DNS server is connected to the Internet through an that doesn't have a DNS server is connected to the Internet through an
skipping to change at page 6, line 9 skipping to change at page 6, line 9
the response if it contains all necessary information, or the sender MAY the response if it contains all necessary information, or the sender MAY
discard the response and resend the query over TCP or using EDNS0 with discard the response and resend the query over TCP or using EDNS0 with
larger window using the unicast address of the responder. The RA larger window using the unicast address of the responder. The RA
(Recursion Available) bit in the header of the response MUST NOT be set. (Recursion Available) bit in the header of the response MUST NOT be set.
Even if the RA bit is set in the response header, the sender MUST ignore Even if the RA bit is set in the response header, the sender MUST ignore
it. it.
2.1.3. mDNS addressing 2.1.3. mDNS addressing
For IPv4 LINKLOCAL addressing, section 2.4 of [6] lays out the rules For IPv4 LINKLOCAL addressing, section 2.4 of [18] lays out the rules
with respect to source address selection, TTL settings, and acceptable with respect to source address selection, TTL settings, and acceptable
source/destination address combinations. IPv6 LINKLOCAL addressing is source/destination address combinations. IPv6 LINKLOCAL addressing is
described in [9]. mDNS queries and responses MUST obey the rules laid described in [9]. mDNS queries and responses MUST obey the rules laid
out in these documents. out in these documents.
In composing an mDNS response, the responder MUST set the Hop Limit In composing an mDNS response, the responder MUST set the Hop Limit
field in the IPv6 header and the TTL field in IPv4 header of the field in the IPv6 header and the TTL field in IPv4 header of the
multicast DNS response to 255. The sender MUST verify that the Hop Limit multicast DNS response to 255. The sender MUST verify that the Hop Limit
field in IPv6 header and TTL field in IPv4 header of each response to field in IPv6 header and TTL field in IPv4 header of each response to
the multicast DNS query is set to 255. If it is not, then sender MUST the multicast DNS query is set to 255. If it is not, then sender MUST
skipping to change at page 7, line 15 skipping to change at page 7, line 15
computers receive the query and respond with valid answers. When this computers receive the query and respond with valid answers. When this
occurs, the responses MAY first be concatenated, and then treated in the occurs, the responses MAY first be concatenated, and then treated in the
same manner that multiple RRs received from the same DNS server would, same manner that multiple RRs received from the same DNS server would,
ordinarily. ordinarily.
3. Usage model 3. Usage model
A host configured to be an mDNS "responder" MUST also be configured as a A host configured to be an mDNS "responder" MUST also be configured as a
"sender". A host not configured as a "responder" MUST NOT be a "sender". "sender". A host not configured as a "responder" MUST NOT be a "sender".
Multicast DNS usage is determined by the domain search configuration as Multicast DNS usage is determined by special treatment of the
well as by special treatment of the ".local.arpa." namespace. Any host ".local.arpa." namespace. The sender treats queries for ".local.arpa."
whose domain search configuration contains the ".local.arpa." domain is as a special case. A sender MUST NOT send a unicast query for names
configured to behave as "responder". The sender treats queries for ending with the ".local.arpa." suffix except when:
".local.arpa." as a special case. The domain search list can be
configured manually or automatically via a DHCP option [3].
A sender MUST NOT send a unicast query for names ending with the
".local.arpa." suffix except when:
a. A sender repeats a query over TCP after it received a response a. A sender repeats a query over TCP after it received a response
to the previous multicast query with the TC bit set, or to the previous multicast query with the TC bit set, or
b. The sender's cache contains an NS resource record that enables b. The sender's cache contains an NS resource record that enables
the sender to send a query directly to the hosts the sender to send a query directly to the hosts
authoritative for the name in the query. authoritative for the name in the query.
It is not expected that a host named "host.example.com." will be It is not expected that a host named "host.example.com." will be
manually configured to have the additional name manually configured to have the additional name
"host.example.com.local.arpa." when it is configured to use multicast "host.example.com.local.arpa." when it is configured to use multicast
DNS. Instead, a responder with a name "host.example.com." configured DNS. Instead, a responder with a name "host.example.com." configured
with ".local.arpa." suffix in its domain search configuration is with ".local.arpa." suffix in its domain search configuration is
authoritative for the name "host.example.com.local.arpa.". For example, authoritative for the name "host.example.com.local.arpa.". For example,
when a responder with the name "host.example.com." receives an A type when a responder with the name "host.example.com." receives an A type
query for the name "host.example.com.local.arpa." it authoritatively query for the name "host.example.com.local.arpa." it authoritatively
responds to the query. responds to the query.
If ".local.arpa" is not in the domain search list, then multicast DNS
MUST NOT be used. This implies that the host will neither listen on the
DNS LINKLOCAL multicast address, nor will it send queries to that
address. An auto-configured host will typically have ".local.arpa" first
in its search list so that it will be enabled to use multicast DNS.
Typically an enterprise host will not have ".local.arpa" in its search
list at all so that it will not use multicast DNS.
The same host MAY use multicast DNS queries for the resolution of names The same host MAY use multicast DNS queries for the resolution of names
ending with ".local.arpa.", and unicast DNS queries for resolution of ending with ".local.arpa.", and unicast DNS queries for resolution of
all other names. When a user or application requests a DNS client to all other names. When a user or application requests a DNS client to
resolve a dot-terminated name that contains a ".local.arpa" suffix, the resolve a dot-terminated name that contains a ".local.arpa" suffix, the
query for such a name MUST be multicast and the name SHOULD NOT be query for such a name MUST be multicast and the name SHOULD NOT be
concatenated with any suffix. concatenated with any suffix.
If a DNS server is running on a host, the host MUST NOT listen for If a DNS server is running on a host, the host MUST NOT listen for
multicast DNS queries, to prevent the host from listening on port 53 and multicast DNS queries, to prevent the host from listening on port 53 and
intercepting DNS queries directed to a DNS server. By default, a DNS intercepting DNS queries directed to a DNS server. By default, a DNS
server MUST NOT listen to multicast DNS queries. For a DNS server, the server MUST NOT listen to multicast DNS queries.
presence of ".local.arpa." in the domain search list MUST NOT enable
multicast DNS. 3.1. mDNS configuration
Multicast DNS usage can be configured manually or automatically. Where
no manual or automatic configuration is provided, multicast DNS is
enabled by default.
For IPv6, the stateless DNS discovery mechanisms described in [19] can
be used to discover whether multicast DNS is enabled or disabled.
Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
configure multicast DNS. The mDNS enable DHCP option, described in [6],
can be used to explicitly enable or disable use of multicast DNS. The
Name Service Search option, described in RFC 2937 [3], can be used to
determine where multicast DNS is used within the name service search
order. DHCP option codes are used as RFC 2937 codes signifying name
services within the search order. As a result, to specify multicast DNS
usage within the name service search order, the option code assigned to
the mDNS enable option is used.
If a host is configured via automatic configuration mechanisms, either
stateful or stateless, and multicast DNS is not explicitly enabled, then
multicast DNS MUST NOT be used, ensuring that upgraded hosts do not
change their default behavior. This implies that the host will neither
listen on the DNS LINKLOCAL multicast address, nor will it send queries
to that address. For a DNS server, automatic configuration mechanisms,
either stateful or stateless, MUST NOT enable multicast DNS.
4. Sequence of events 4. Sequence of events
The sequence of events for multicast DNS usage is as follows: The sequence of events for multicast DNS usage is as follows:
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. The sender then the protocol used) of the response is set to 255. The sender then
verifies compliance with the addressing requirements for IPv4 [6] verifies compliance with the addressing requirements for IPv4 [18]
and IPv6 [9]. 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
query and type of the query. For example it is expected that: query and type of the query. For example it is expected that:
- multiple hosts may respond to a query for a SRV type record - multiple hosts may respond to a query for a SRV type record
- multiple hosts may respond to a query for an A type record for a - multiple hosts may respond to a query for an A type record for a
cluster name (assigned to multiple hosts in the cluster) cluster name (assigned to multiple hosts in the cluster)
- only a single host may respond to a query for an A type record for - only a single host may respond to a query for an A type record for
a hostname. a hostname.
skipping to change at page 13, line 13 skipping to change at page 13, line 27
multicast to transmit these requests. multicast to transmit these requests.
8. References 8. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC [2] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998. 2365, July 1998.
[3] Aboba, B., "DHCP Domain Search Option", Internet draft (work in [3] Smith, C., "The Name Service Search Option for DHCP", RFC 2937,
progress), draft-aboba-dhc-domsearch-02.txt, June 2001. September 2000.
[4] Mockapetris, P., "Domain Names - Implementation and Specification", [4] Mockapetris, P., "Domain Names - Implementation and Specification",
RFC 1035, November 1987. RFC 1035, November 1987.
[5] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC [5] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC
1034, November, 1987. 1034, November, 1987.
[6] Cheshire, S., Aboba, B., "Dynamic Configuration of IPv4 Link-Local [6] Guttman, E., "DHCP mDNS Enable Option", Internet draft (work in
Addresses", Internet draft (work in progress), draft-ietf-zeroconf- progress), draft-guttman-mdns-enable-01.txt, July 2001.
ipv4-linklocal-03.txt, June 2001.
[7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA [7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[9] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", [9] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture",
RFC 2373, July 1998. RFC 2373, July 1998.
skipping to change at page 13, line 46 skipping to change at page 14, line 10
exchange between systems - Local and metropolitan area networks - exchange between systems - Local and metropolitan area networks -
Specific Requirements Part 11: Wireless LAN Medium Access Control Specific Requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications, IEEE Std. (MAC) and Physical Layer (PHY) Specifications, IEEE Std.
802.11-1997, 1997. 802.11-1997, 1997.
[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-03.txt, July 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 [14] Crawford, Matt, "IPv6 Node Information Queries", Internet draft
(work in progress), draft-ietf-ipn-gwg-icmp-name-lookups-07.txt, (work in progress), draft-ietf-ipn-gwg-icmp-name-lookups-07.txt,
August 2000. August 2000.
[15] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, [15] Eastlake, D., "Domain Name System Security Extensions", RFC 2535,
March 1999. March 1999.
[16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April [16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992. 1992.
[17] Aboba, B., "DHCP Domain Search Option", Internet draft (work in
progress), draft-aboba-dhc-domsearch-06.txt, August 2001.
[18] Cheshire, S., Aboba, B., "Dynamic Configuration of IPv4 Link-Local
Addresses", Internet draft (work in progress), draft-ietf-zeroconf-
ipv4-linklocal-05.txt, September 2001.
[19] Thaler, D., Hagino, I., "IPv6 Stateless DNS Discovery", Internet
draft (work in progress), draft-ietf-ipngwg-dns-discovery-02.txt,
July 2001.
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 16, line 26 skipping to change at page 17, line 4
on all such copies and derivative works. However, this document itself 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 may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into Standards process must be followed, or as required to translate it into
languages other than English. The limited permissions granted above are languages other than English. The limited permissions granted above are
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-03.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-04.txt>, and expires
February 1, 2002. March 22, 2002.
 End of changes. 

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