draft-ietf-dnsext-mdns-06.txt   draft-ietf-dnsext-mdns-07.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-06.txt> Microsoft <draft-ietf-dnsext-mdns-07.txt> Microsoft
8 October 2001 15 November 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 3, line 28 skipping to change at page 3, line 28
This document discusses multicast DNS, an extension to the DNS protocol 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 which consists of a single change to the method of use, and no change to
the format of DNS packets. the format of DNS packets.
Service discovery in general as well as discovery of DNS servers using Service discovery in general as well as discovery of DNS servers using
mDNS in particular is outside of the scope of this document, as is name mDNS in particular is outside of the scope of this document, as is name
resolution over non-multicast capable media. resolution over non-multicast capable media.
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"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 RFC 2119 [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, It
Namely, this extension allows multicast DNS queries to be sent to and allows multicast DNS queries to be sent to and received on port 53 using
received on port 53. a LINKLOCAL address as specified in "Administratively Scoped IP
Multicast" [2] for IPv4 and the "solicited name" LINKLOCAL multicast
addresses for IPv6. The mDNS LINKLOCAL address to be used for IPv4 is
<TBD>. LINKLOCAL addresses are used to prevent propagation of multicast
DNS traffic across routers, potentially flooding the network.
This extension allows multicast DNS queries to be sent to and received Propagation of multicast DNS packets on the local link is considered
on port 53 using a LINKLOCAL address as specified in "Administratively sufficient to enable DNS name resolution in small adhoc networks. The
Scoped IP Multicast" [2] for IPv4 and the "solicited name" LINKLOCAL assumption is that if a network has a router, then the network either
multicast addresses for IPv6. The mDNS LINKLOCAL address to be used for has a DNS server or the router can function as a DNS proxy.
IPv4 is <TBD>. LINKLOCAL addresses are used to prevent propagation of
multicast DNS traffic across routers, potentially flooding the network.
Propagation of multicast DNS packets within the local subnet is By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, routers
considered sufficient to enable DNS name resolution in small adhoc can provide name resolution for the names of IPv4 hosts on the local
networks. The assumption is that if a network has a router, then the network. Where all IPv6 hosts also support IPv4, and the DNS proxy
network either has a DNS server or the router can function as a DNS supports AAAA RRs, resolution for the names of dual stack IPv6 hosts on
proxy. By implementing DHCP as well as a DNS proxy and dynamic DNS, the local network can also be provided using this mechanism.
routers can provide name resolution for the names of the hosts on the
local network. This functionality is easily provided, and so in such Within small adhoc IPv6 networks, stateful autoconfiguration is the most
cases it is assumed that multicast DNS need not be enabled by default. likely configuration mechanism. If DHCPv6 is not present, then in order
to support resolution of names of IPv6-only hosts on the local network,
the DNS proxy will need to support dynamic client update as well as DNS
over IPv6.
Given the above mechanisms enabling DNS name resolution in small
networks with a router, it is assumed that multicast DNS need not be
enabled by default.
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 on multiple links
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
skipping to change at page 4, line 32 skipping to change at page 4, line 42
a "responder" cannot be a "sender". a "responder" cannot be a "sender".
2.1.1. Behavior of senders 2.1.1. Behavior of senders
A sender sends multicast DNS query for any legal Type of resource record A sender sends multicast DNS query for any legal Type of resource record
(e.g. A, PTR, etc.) for a name within the ".local.arpa." domain to the (e.g. A, PTR, etc.) for a name within the ".local.arpa." domain to the
LINKLOCAL address. The RD (Recursion Desired) bit MUST NOT be set. If a LINKLOCAL address. The RD (Recursion Desired) bit MUST NOT be set. If a
responder receives a query with the header containing RD set bit, the responder receives a query with the header containing RD set bit, the
responder MUST ignore the RD bit. responder MUST ignore the RD bit.
The IPv6 LINKLOCAL address a given responder listens to, and to which a
sender 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 "IPv6 Node Information Queries" [14]). A
responder that listens for queries for multiple names will necessarily
listen to multiple of these solicited name multicast addresses.
If the multicast query is not positively resolved ("positively resolved" If the multicast query is not positively resolved ("positively resolved"
refers in this document to a response with the RCODE set to 0) during a refers in this document to a response with the RCODE set to 0) during a
limited amount of time, then a sender MAY repeat the transmission of a limited amount of time, then a sender MAY repeat the transmission of a
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 randomized so as to avoid traffic. The delay between attempts should be randomized so as to avoid
synchronization effects. synchronization effects.
2.1.2. Behavior of responders 2.1.2. Behavior of responders
A responder listens on port 53 on the LINKLOCAL address. The IPv6 A responder listens on port 53 on the LINKLOCAL address. Responders
LINKLOCAL address a given responder listens to, and to which a sender MUST respond to multicast queries to those and only those names for
sends, is a link-local multicast address formed as follows: The name of which they are authoritative. As an example, computer
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 "IPv6 Node Information Queries" [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 5, line 49 skipping to change at page 6, line 10
host "child.host.example.com.local.arpa." would send a dynamic update host "child.host.example.com.local.arpa." would send a dynamic update
for the NS and glue A record to "host.example.com.local.arpa.", but this for the NS and glue A record to "host.example.com.local.arpa.", but this
approach significantly complicates implementation of multicast DNS and approach significantly complicates implementation of multicast DNS and
would not be acceptable for lightweight hosts. would not be acceptable for lightweight hosts.
A response to a multicast query is composed in exactly the same manner A response to a multicast query is composed in exactly the same manner
as a response to the unicast DNS query as specified in RFC 1035 [4]. as a response to the unicast DNS query as specified in RFC 1035 [4].
Responders MUST never respond using cached data, and the AA Responders MUST never respond using cached data, and the AA
(Authoritative Answer) bit MUST be set. The response is sent to the (Authoritative Answer) bit MUST be set. The response is sent to the
sender via unicast. A response to an mDNS query MUST have RCODE set to sender via unicast. A response to an mDNS query MUST have RCODE set to
zero, since mDNS responders MUST NOT send error replies in response to zero. mDNS responders may respond only to queries which they can resolve
mDNS queries. positively.
If a TC (truncation) bit is set in the response, then the sender MAY use If a TC (truncation) bit is set in the response, then the sender MAY use
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
skipping to change at page 7, line 50 skipping to change at page 8, line 12
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.
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, then responder MUST NOT listen for
multicast DNS queries, to prevent the host from listening on port 53 and the multicast DNS queries on the same IP addresses on which the DNS
intercepting DNS queries directed to a DNS server. By default, a DNS server listens, since otherwise they would intercept DNS queries
directed to a DNS server. The DNS server MUST respond to the multicast
server MUST NOT listen to multicast DNS queries. DNS queries only for the RRSets owned by the host on which the server is
running, but MUST NOT respond for the records for which the server is
authoritative.
3.1. mDNS configuration 3.1. mDNS configuration
Multicast DNS usage can be configured manually or automatically. On Multicast DNS usage can be configured manually or automatically. On
interfaces where no manual or automatic configuration has been performed interfaces where no manual or automatic configuration has been performed
for a given protocol (IPv4 or IPv6), multicast DNS SHOULD be enabled by for a given protocol (IPv4 or IPv6), multicast DNS SHOULD be enabled by
default for that protocol. default for that protocol.
For IPv6, the stateless DNS discovery mechanisms described in "IPv6 For IPv6, the stateless DNS discovery mechanisms described in "IPv6
Stateless DNS Discovery" [19] can be used to discover whether multicast Stateless DNS Discovery" [19] can be used to discover whether multicast
DNS is globally enabled or disabled. DNS should be enabled or disabled on a per-interface basis.
Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
configure multicast DNS on an interface. The mDNS Enable Option, configure multicast DNS on an interface. The mDNS Enable Option,
described in [6], can be used to explicitly enable or disable use of described in [6], can be used to explicitly enable or disable use of
multicast DNS on an interface for a given protocol, as well as to multicast DNS on an interface for a given protocol, as well as to
specify the order in which DNS and multicast DNS is used on that specify the order in which DNS and multicast DNS is used on that
interface. interface.
The mDNS Enable Option affects only DNS resolver behavior, that is, how The mDNS Enable Option affects only DNS resolver behavior, that is, how
DNS resolution is performed, and whether multicast DNS is used. The DNS resolution is performed, and whether multicast DNS is used. The
skipping to change at page 10, line 41 skipping to change at page 11, line 4
not exist. not exist.
Update section Update section
This section MUST be left empty. This section MUST be left empty.
Additional section Additional section
This section is set according to RFC 2136. This section is set according to RFC 2136.
When a host that owns a UNIQUE record receives a dynamic update request When a host that owns a UNIQUE record receives a dynamic update request
that requests that the UNIQUE resource record set does not exist, the that requests that the UNIQUE resource record set does not exist, the
host MUST respond via unicast with the YXRRSET error, according to the host MUST respond via unicast with the YXRRSET error, according to the
rules described in Section 3 of RFC 2136 [11]. rules described in Section 3 of RFC 2136 [11].
After the client receives an YXRRSET response to its dynamic update After client receives an YXRRSET response to its dynamic update request
request that a UNIQUE resource record does not exist, the host MUST NOT that a UNIQUE resource record does not exist, the host MUST check
use the UNIQUE resource record in responses to multicast queries and whether the response arrived on another interface. If this is the case,
then the client can use the UNIQUE resource record in response to
multicast queries and dynamic update requests. If not, then it MUST NOT
use the UNIQUE resource record in response to multicast queries and
dynamic update requests. dynamic update requests.
Note that this name conflict detection mechanism doesn't prevent name Note that this name conflict detection mechanism doesn't prevent name
conflicts when previously partitioned segments are connected by a conflicts when previously partitioned segments are connected by a
bridge. In such a situation, name conflicts are detected when a sender bridge. In such a situation, name conflicts are detected when a sender
receives more than one response to its multicast DNS query. In this receives more than one response to its multicast DNS query. In this
case, the sender sends the first response that it received to all case, the sender sends the first response that it received to all
responders that responded to this query except the first one, using responders that responded to this query except the first one, using
unicast. A host that receives a query response containing a UNIQUE unicast. A host that receives a query response containing a UNIQUE
resource record that it owns, even if it didn't send such a query, MUST resource record that it owns, even if it didn't send such a query, MUST
verify that no other host within the multicast DNS scope is verify that no other host within the multicast DNS scope is
authoritative for the same name, using the dynamic DNS update request authoritative for the same name, using the dynamic DNS update request
mechanism described above. mechanism described above.
Based on the result, the host detects whether there is a name conflict Based on the result, the host detects whether there is a name conflict
and acts as described above. and acts as described above.
skipping to change at page 12, line 11 skipping to change at page 12, line 26
[A] [myhost] [A] [A] [myhost] [A]
Figure 2. Off-segment name conflict Figure 2. Off-segment name conflict
If host myhost is configured to use mDNS on both interfaces, it will If host myhost is configured to use mDNS on both interfaces, it will
send mDNS queries on both interfaces. When host myhost sends a query send mDNS queries on both interfaces. When host myhost sends a query
for the host RR for name "A" it will receive a response from hosts on for the host RR for name "A" it will receive a response from hosts on
both interfaces. Host myhost will then forward a response from the both interfaces. Host myhost will then forward a response from the
first responder to the second responder, who will attempt to verify the first responder to the second responder, who will attempt to verify the
uniqueness of host RR for its name, but will not discover a conflict, uniqueness of host RR for its name, but will not discover a conflict,
since the conflicting host resides on a different subnet. Therefore it since the conflicting host resides on a different link. Therefore it
will continue using its name. will continue using its name.
Indeed, host myhost cannot distinguish between the situation shown in Indeed, host myhost cannot distinguish between the situation shown in
Figure 2, and that shown in Figure 3 where no conflict exists: Figure 2, and that shown in Figure 3 where no conflict exists:
[A] [A]
| | | |
----- ----- ----- -----
| | | |
[myhost] [myhost]
Figure 3. Multiple paths to same host Figure 3. Multiple paths to same host
This illustrates that the proposed name conflict resolution mechanism This illustrates that the proposed name conflict resolution mechanism
does not support detection or resolution of conflicts between hosts on does not support detection or resolution of conflicts between hosts on
different subnets. This problem can also occur with unicast DNS when a different links. This problem can also occur with unicast DNS when a
multi-homed host is connected to two different networks with separated multi-homed host is connected to two different networks with separated
name spaces. It is not the intent of this document to address the issue name spaces. It is not the intent of this document to address the issue
of uniqueness of names within DNS. of uniqueness of names within DNS.
5.2. API issues 5.2. API issues
RFC 2553 [13] provides an API which can partially solve the name RFC 2553 [13] provides an API which can partially solve the name
ambiguity problem for applications written to use this API, since the ambiguity problem for applications written to use this API, since the
sockaddr_in6 structure exposes the scope within which each scoped sockaddr_in6 structure exposes the scope within which each scoped
address exists, and this structure can be used for both IPv4 (using address exists, and this structure can be used for both IPv4 (using
v4-mapped IPv6 addresses) and IPv6 addresses. v4-mapped IPv6 addresses) and IPv6 addresses.
Following the example in Figure 2, an application on 'myhost' issues the Following the example in Figure 2, an application on 'myhost' issues the
request getaddrinfo("A", ...) with ai_family=AF_INET6 and request getaddrinfo("A", ...) with ai_family=AF_INET6 and
ai_flags=AI_ALL|AI_V4MAPPED. mDNS requests will be sent from both ai_flags=AI_ALL|AI_V4MAPPED. mDNS requests will be sent from both
interfaces and the resolver library will return a list containing interfaces and the resolver library will return a list containing
multiple addrinfo structures, each with an associated sockaddr_in6 multiple addrinfo structures, each with an associated sockaddr_in6
structure. This list will thus contain the IPv4 and IPv6 addresses of structure. This list will thus contain the IPv4 and IPv6 addresses of
skipping to change at page 15, line 12 skipping to change at page 15, line 19
(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 [17] Aboba, B., "DHCP Domain Search Option", Internet draft (work in
progress), draft-aboba-dhc-domsearch-06.txt, August 2001. progress), draft-aboba-dhc-domsearch-08.txt, November 2001.
[18] Cheshire, S., Aboba, B., "Dynamic Configuration of IPv4 Link-Local [18] Cheshire, S., Aboba, B., "Dynamic Configuration of IPv4 Link-Local
Addresses", Internet draft (work in progress), draft-ietf-zeroconf- Addresses", Internet draft (work in progress), draft-ietf-zeroconf-
ipv4-linklocal-05.txt, September 2001. ipv4-linklocal-05.txt, November 2001.
[19] Thaler, D., Hagino, I., "IPv6 Stateless DNS Discovery", Internet [19] Thaler, D., Hagino, I., "IPv6 Stateless DNS Discovery", Internet
draft (work in progress), draft-ietf-ipngwg-dns-discovery-02.txt, draft (work in progress), draft-ietf-ipngwg-dns-discovery-02.txt,
July 2001. July 2001.
[20] Stevens, W., Thomas, M., "Advanced Sockets API for IPv6", RFC 2292, [20] Stevens, W., Thomas, M., "Advanced Sockets API for IPv6", RFC 2292,
February 1998. February 1998.
9. Security Considerations 9. Security Considerations
skipping to change at page 17, line 44 skipping to change at page 18, line 5
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-06.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-07.txt>, and expires May
April 22, 2002. 22, 2002.
 End of changes. 

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