+++ /dev/null
-
-
-
-
-
-
-DNSEXT Working Group Levon Esibov
-INTERNET-DRAFT Bernard Aboba
-Category: Standards Track Dave Thaler
-<draft-ietf-dnsext-mdns-07.txt> Microsoft
-15 November 2001
-
-
- Multicast DNS
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC 2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other groups
-may also distribute working documents as Internet- Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-Copyright Notice
-
-Copyright (C) The Internet Society (2001). All Rights Reserved.
-
-Abstract
-
-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
-name resolution in such environments, the use of a multicast DNS is
-proposed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 1]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-Table of Contents
-
-1. Introduction .......................................... 3
-2. Name resolution using multicast DNS ................... 3
- 2.1 Behavior of the sender and responder ............ 4
-3. Usage model ........................................... 7
- 3.1 mDNS configuration .............................. 8
-4. Sequence of events .................................... 9
-5. Conflict resolution ................................... 9
- 5.1 Considerations for multiple interfaces .......... 11
- 5.2 API issues ...................................... 12
-6. IANA considerations ................................... 13
-7. ARPA domain considerations ............................ 13
-8. References ............................................ 14
-9. Security considerations ............................... 15
-Acknowledgments .............................................. 16
-Authors' Addresses ........................................... 16
-Intellectual Property Statement .............................. 16
-Full Copyright Statement ..................................... 17
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 2]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-1. 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 name resolution for the names of the hosts on the local 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
-ISP and the 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 network.
-
-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.
-
-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
-resolution over non-multicast capable media.
-
-In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
-"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
-described in RFC 2119 [1].
-
-2. Name resolution using Multicast DNS
-
-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, It
-allows multicast DNS queries to be sent to and received on port 53 using
-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.
-
-Propagation of multicast DNS packets on the local link is considered
-sufficient to enable DNS name resolution in small adhoc 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 proxy.
-
-By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, routers
-can provide name resolution for the names of IPv4 hosts on the local
-network. Where all IPv6 hosts also support IPv4, and the DNS proxy
-supports AAAA RRs, resolution for the names of dual stack IPv6 hosts on
-the local network can also be provided using this mechanism.
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-Within small adhoc IPv6 networks, stateful autoconfiguration is the most
-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
-multicast scope. This would occur if LINKLOCAL mDNS deployment is
-successful, the assumption that mDNS is not needed on multiple links
-proves incorrect, and multicast routing becomes ubiquitous. For
-example, it is not clear that this assumption will be valid in large
-adhoc networking scenarios.
-
-Once we have experience in mDNS deployment in terms of administrative
-issues, usability and impact on the network it will be possible
-reevaluate which multicast scopes are appropriate for use with mDNS.
-
-2.1. Behavior of the sender and responder
-
-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
-responds to) a multicast query is called "responder". A host configured
-to be a "responder" may also be a "sender". A host configured to not be
-a "responder" cannot be a "sender".
-
-2.1.1. Behavior of senders
-
-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
-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 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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 4]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-listen to multiple of these solicited name multicast addresses.
-
-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
-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
-a host capable of responding to the query.
-
-Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be
-repeated more often than once per second to reduce unnecessary network
-traffic. The delay between attempts should be randomized so as to avoid
-synchronization effects.
-
-2.1.2. Behavior of responders
-
-A responder listens on port 53 on the LINKLOCAL address. 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.". On receiving a multicast DNS A record
-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.
-
-In conventional DNS terminology a DNS server authoritative for a zone is
-authoritative for all the domain names under the zone root except for
-the branches delegated into separate zones. Contrary to conventional DNS
-terminology, a responder is authoritative only for the zone root. For
-example the host "host.example.com.local.arpa." is not authoritative for
-the name "child.host.example.com.local.arpa." unless the host is
-configured with multiple names, including "host.example.com.local.arpa."
-and "child.host.example.com.local.arpa.". The purpose of limiting the
-name authority scope of a responder is to prevent complications that
-could be caused by coexistence of two or more hosts with the names
-representing child and parent (or grandparent) nodes in the DNS tree,
-for example, "host.example.com.local.arpa." and
-"child.host.example.com.local.arpa.".
-
-In this example (unless this limitation is introduced) a multicast query
-for an A record for the name "child.host.example.com.local.arpa." would
-result in two authoritative responses: name error received from
-"host.example.com.local.arpa.", and a requested A record - from
-"child.host.example.com.local.arpa.". To prevent this ambiguity,
-multicast enabled hosts could perform a dynamic update of the parent (or
-grandparent) zone with a delegation to a child zone. In this example a
-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
-approach significantly complicates implementation of multicast DNS and
-would not be acceptable for lightweight hosts.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-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].
-Responders MUST never respond using cached data, and the AA
-(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
-zero. mDNS responders may respond only to queries which they can resolve
-positively.
-
-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
-discard the response and resend the query over TCP or using EDNS0 with
-larger window using the unicast address of the responder. The RA
-(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
-it.
-
-2.1.3. mDNS addressing
-
-For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic Configuration of
-IPv4 Link-Local Addresses" [18] lays out the rules with respect to
-source address selection, TTL settings, and acceptable
-source/destination address combinations. IPv6 LINKLOCAL addressing is
-described in RFC 2373 [9]. mDNS queries and responses MUST obey the
-rules laid out in these documents.
-
-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
-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
-the multicast DNS query is set to 255. If it is not, then sender MUST
-ignore the response.
-
- Implementation note:
-
- In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket
- options are used to specify the TTL of outgoing unicast and multicast
- packets. The IP_RECVTTL socket option is available on some platforms
- to receive the IPv4 TTL of received packets with recvmsg(). RFC 2292
- [20] specifies similar options for specifying and receiving the IPv6
- Hop Limit.
-
-2.1.4. Use of DNS TTL
-
-The responder should use a pre-configured TTL value in the records
-returned in the multicast DNS query response. Due to the TTL
-minimalization necessary when caching an RRset, all TTLs in an RRset
-MUST be set to the same value. In the additional and authority section
-of the response the responder includes the same records as a DNS server
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-would insert in the response to the unicast DNS query.
-
-2.1.5. No/multiple responses
-
-The sender MUST anticipate receiving no replies to some multicast
-queries, in the event that no responders are available within the
-multicast scope, or in the event that no positive non-null responses
-exist for 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).
-
-The sender MUST anticipate receiving multiple replies to the same
-multicast query, in the event that several multicast DNS enabled
-computers 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.
-
-3. Usage model
-
-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".
-
-Multicast DNS usage is determined by special treatment of the
-".local.arpa." namespace. The sender treats queries for ".local.arpa."
-as a special case. A sender MUST NOT send a unicast query for names
-ending with the ".local.arpa." suffix except when:
-
- a. A sender repeats a query after it received a response
- to the previous multicast query with the TC bit set, or
-
- b. The sender's cache contains an NS resource record that enables
- the sender to send a query directly to the hosts
- authoritative for the name in the query.
-
-It is not expected that a host named "host.example.com." will be
-manually configured to have the additional name
-"host.example.com.local.arpa." when it is configured to use multicast
-DNS. Instead, a responder with a name "host.example.com." configured
-with ".local.arpa." suffix in its domain search configuration is
-authoritative for the name "host.example.com.local.arpa.". For example,
-when a responder with the name "host.example.com." receives an A type
-query for the name "host.example.com.local.arpa." it authoritatively
-responds to the query.
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-The same host MAY use multicast DNS queries for the resolution of names
-ending with ".local.arpa.", and unicast DNS queries for resolution of
-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
-query for such a name MUST be multicast and the name SHOULD NOT be
-concatenated with any suffix.
-
-If a DNS server is running on a host, then responder MUST NOT listen for
-the multicast DNS queries on the same IP addresses on which the DNS
-server listens, since otherwise they would intercept DNS queries
-directed to a DNS server. The DNS server MUST respond to the multicast
-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
-
-Multicast DNS usage can be configured manually or automatically. On
-interfaces where no manual or automatic configuration has been performed
-for a given protocol (IPv4 or IPv6), multicast DNS SHOULD be enabled by
-default for that protocol.
-
-For IPv6, the stateless DNS discovery mechanisms described in "IPv6
-Stateless DNS Discovery" [19] can be used to discover whether multicast
-DNS should be enabled or disabled on a per-interface basis.
-
-Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
-configure multicast DNS on an interface. The mDNS Enable Option,
-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
-specify the order in which DNS and multicast DNS is used on that
-interface.
-
-The mDNS Enable Option affects only DNS resolver behavior, that is, how
-DNS resolution is performed, and whether multicast DNS is used. The
-mDNS Enable Option does not determine whether or in which order DNS
-itself is used for name resolution. This can be specified, for example,
-using the Name Service Search Option for DHCP, RFC 2937 [3], which can
-be used to globally determine where DNS is used within the name service
-search order.
-
-If an interface has been configured for a given protocol via any
-automatic configuration mechanism which is able to supply DNS
-configuration information, then multicast DNS SHOULD NOT be used on that
-interface for that protocol unless it has been explicitly enabled,
-whether via that mechanism or any other. This ensures that upgraded
-hosts do not change their default behavior, without requiring the source
-of the configuration information to be simultaneously updated. This
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-implies that on the interface, the host will neither listen on the DNS
-LINKLOCAL multicast address, nor will it send queries to that address.
-
-Note that it is possible for mDNS to be enabled for use with IPv6 at the
-same time it is disabled for IPv4, and vice versa. For example, where a
-home gateway implements a DNS proxy and DHCPv4, but not DHCPv6 or DNS
-autoconfiguration, there may be no mechanism for allowing IPv6 hosts to
-resolve the names of other IPv6 hosts on the home network. In this
-situation, mDNS is useful for resolution of dynamic names, and it will
-be enabled for use with IPv6, even though it is disabled for use with
-IPv4.
-
-4. Sequence of events
-
-The sequence of events for multicast DNS usage is as follows:
-
-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
- LINKLOCAL multicast address.
-
-2. A responder responds to this query only if it is authoritative
- for the domain name "host.example.com.local.arpa". The responder sends
- a response to the sender via unicast over UDP.
-
-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
- the protocol used) of the response is set to 255. The sender then
- verifies compliance with the addressing requirements for IPv4,
- described in [18], and IPv6, described in RFC 2373 [9]. If these
- conditions are met, then the sender uses and caches the returned
- response. If not, then the sender ignores the response and continues
- waiting for the response.
-
-5. Conflict resolution
-
-There are some scenarios when multiple responders MAY respond to the
-same query. There are other scenarios when only one responder may
-respond to a query. Resource records for which the latter queries are
-submitted are referred as UNIQUE throughout this document. 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:
-
- - 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
- cluster name (assigned to multiple hosts in the cluster)
- - only a single host may respond to a query for an A type record for
- a hostname.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-Every responder that responds to a multicast DNS query and/or dynamic
-update request AND includes a UNIQUE record in the response:
-
- 1. MUST verify that there is no other host within the scope of the
- multicast DNS query propagation that can return a DNS record
- for the same name, type and class.
- 2. MUST NOT include a UNIQUE resource record in the
- response without having verified its uniqueness.
-
-Where a host is configured to respond to multicast DNS queries on more
-than one interface, the host MUST verify resource record uniqueness on
-each interface for each UNIQUE resource record that could be used on
-that interface. To accomplish this, the host MUST multicast a dynamic
-DNS update request as specified in RFC 2136 [11] for each new UNIQUE
-resource record. Uniqueness verification is carried out when the host:
-
- - starts up or
- - is configured to respond to the multicast DNS queries on
- some interface or
- - is configured to respond to the multicast DNS queries using
- additional UNIQUE DNS records.
-
-Below we describe the data to be specified in the dynamic update
-request:
-
-Header section
- contains values according to RFC 2136 [11].
-
-Zone section
- 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
- SOA. The zone class in the zone section MUST be set to the class of
- the UNIQUE record.
-
-Prerequisite section
- This section MUST contain a record set whose semantics are
- described in RFC 2136 [11], Section 2.4.3 "RRset Does Not Exist",
- requesting that RRs with the NAME and TYPE of the UNIQUE record do
- not exist.
-
-Update section
- This section MUST be left empty.
-
-Additional section
- This section is set according to RFC 2136.
-
-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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-host MUST respond via unicast with the YXRRSET error, according to the
-rules described in Section 3 of RFC 2136 [11].
-
-After client receives an YXRRSET response to its dynamic update request
-that a UNIQUE resource record does not exist, the host MUST check
-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.
-
-Note that this name conflict detection mechanism doesn't prevent name
-conflicts when previously partitioned segments are connected by a
-bridge. In such a situation, name conflicts are detected when a sender
-receives more than one response to its multicast DNS query. In this
-case, the sender sends the first response that it received to all
-responders that responded to this query except the first one, using
-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
-verify that no other host within the multicast DNS scope is
-authoritative for the same name, using the dynamic DNS update request
-mechanism described above.
-
-Based on the result, the host detects whether there is a name conflict
-and acts as described above.
-
-5.1. Considerations for Multiple Interfaces
-
-A multi-homed host may elect to configure multicast DNS on only one of
-its active interfaces. In many situations this will be adequate.
-However, should a host wish to configure multicast DNS on more than one
-of its active interfaces, there are some additional precautions it MUST
-take. Implementers who are not planning to support multicast DNS on
-multiple interfaces simultaneously may skip this section.
-
-A multi-homed host checks the uniqueness of UNIQUE records as described
-in Section 5. The situation is illustrated in figure 1 below:
-
- ---------- ----------
- | | | |
- [A] [myhost] [myhost]
-
- Figure 1. LINKLOCAL name conflict
-
-In this situation, the multi-homed myhost will probe for, and defend,
-its host name on both interfaces. A conflict will be detected on one
-interface, but not the other. The multi-homed myhost will not be able to
-respond with a host RR for "myhost" on the interface on the right (see
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 11]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-Figure 1). The multi-homed host may, however, be configured to use the
-"myhost" name on the interface on the left.
-
-Since names are only unique per-link, hosts on different links could be
-using the same name. If an mDNS client sends requests over multiple
-interfaces, and receives replies from more than one, the result returned
-to the client is defined by the implementation. The situation is
-illustrated in figure 2 below.
-
- ---------- ----------
- | | | |
- [A] [myhost] [A]
-
-
- Figure 2. Off-segment name conflict
-
-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
-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
-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,
-since the conflicting host resides on a different link. Therefore it
-will continue using its name.
-
-Indeed, host myhost cannot distinguish between the situation shown in
-Figure 2, and that shown in Figure 3 where no conflict exists:
-
-
- [A]
- | |
- ----- -----
- | |
- [myhost]
-
- Figure 3. Multiple paths to same host
-
-This illustrates that the proposed name conflict resolution mechanism
-does not support detection or resolution of conflicts between hosts on
-different links. This problem can also occur with unicast DNS when a
-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
-of uniqueness of names within DNS.
-
-5.2. API issues
-
-RFC 2553 [13] provides an API which can partially solve the name
-ambiguity problem for applications written to use this API, since the
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 12]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-sockaddr_in6 structure exposes the scope within which each scoped
-address exists, and this structure can be used for both IPv4 (using
-v4-mapped IPv6 addresses) and IPv6 addresses.
-
-Following the example in Figure 2, an application on 'myhost' issues the
-request getaddrinfo("A", ...) with ai_family=AF_INET6 and
-ai_flags=AI_ALL|AI_V4MAPPED. mDNS requests will be sent from both
-interfaces and the resolver library will return a list containing
-multiple addrinfo structures, each with an associated sockaddr_in6
-structure. This list will thus contain the IPv4 and IPv6 addresses of
-both hosts responding to the name 'A'. Link-local addresses will have a
-sin6_scope_id value that disambiguates which interface is used to reach
-the address. Of course, to the application, Figures 2 and 3 are still
-indistinguishable, but this API allows the application to communicate
-successfully with any address in the list.
-
-6. IANA Considerations
-
-This specification requires allocation of a link scope IPv4 multicast
-addresses for use by multicast DNS.
-
-7. ARPA domain considerations
-
-This document specifies the use of a new sub-domain of the "ARPA"
-domain. According to Section 2.1 of the ARPA Guidelines [12], this
-specification requires description and justification.
-
-The 'local.arpa' domain is used to distinguish a local namespace. This
-namespace differs from others in the following respects:
-
- - Name servers responding to requests for names in this
- domain have different rules concerning authority. As
- explained in Section 2.1, mDNS servers have limited
- scope of authority, not extending to sub-domains of
- domain they are authoritative for.
-
- - DNS servers SHOULD NOT forward or recursively resolve
- queries for domain names in the local.arpa domain - if the
- server cannot answer the query from its own database,
- it MUST NOT reply.
-
- - Hosts may derive their own names in this namespace,
- independent of centralized authorization and registration
- (as defined in section 3 and section 5).
-
- - There is no delegation or administrative structure to
- sub-domains of '.local.arpa'.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-How protocol objects are mapped into lookup keys:
-
- Names are associated with resources which can be requested
- according to the DNS protocol. However, recursive lookup
- is impossible. Further, mDNS specifies only the use of
- multicast to transmit these requests.
-
-8. 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] Smith, C., "The Name Service Search Option for DHCP", RFC 2937,
- September 2000.
-
-[4] Mockapetris, P., "Domain Names - Implementation and Specification",
- RFC 1035, November 1987.
-
-[5] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC
- 1034, November, 1987.
-
-[6] Guttman, E., "DHCP mDNS Enable Option", Internet draft (work in
- progress), draft-guttman-mdns-enable-01.txt, July 2001.
-
-[7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-[8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
- Specification", RFC 2460, December 1998.
-
-[9] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture",
- RFC 2373, July 1998.
-
-[10] Information technology - Telecommunications and information
- exchange between systems - Local and metropolitan area networks -
- Specific Requirements Part 11: Wireless LAN Medium Access Control
- (MAC) and Physical Layer (PHY) Specifications, IEEE Std.
- 802.11-1997, 1997.
-
-[11] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates in
- the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
-
-[12] Huston, G., "Management Guidelines & Operational Requirements for
- the Internet Infrastructure Domain ("ARPA")", Internet draft (work
- in progress), draft-iab-arpa-03.txt, July 2001.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-[13] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic Socket
- 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.
-
-[17] Aboba, B., "DHCP Domain Search Option", Internet draft (work in
- progress), draft-aboba-dhc-domsearch-08.txt, November 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, November 2001.
-
-[19] Thaler, D., Hagino, I., "IPv6 Stateless DNS Discovery", Internet
- draft (work in progress), draft-ietf-ipngwg-dns-discovery-02.txt,
- July 2001.
-
-[20] Stevens, W., Thomas, M., "Advanced Sockets API for IPv6", RFC 2292,
- February 1998.
-
-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. Such attacks also
-allow nodes to receive packets destined for other nodes. The protocol
-reduces the exposure to such threats in the absence of authentication by
-ignoring multicast DNS query response packets received from off-link
-senders.
-
-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
-routers decrement the Hop Limit on all packets they forward, received
-packets containing a Hop Limit of 255 must have originated from a
-neighbor.
-
-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.
-Link-layer security will serve to secure mDNS against the above threats
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-if it is available. For example, where 802.11 "Wired Equivalency
-Privacy" (WEP) [10] is implemented, a casual attacker is likely to be
-deterred from gaining access to the home network.
-
-The mechanism specified in this draft does not require use of DNSSEC.
-As a result, responses to multicast DNS queries MAY NOT be
-authenticated. If a network contains a "signed key distribution center"
-for some of the DNS zones that the responders are authoritative for, and
-senders on that network are configured with the key for the top zone
-"local.arpa." (hosted by "signed keys distribution center"), then
-senders MAY authenticate the responses using DNSSEC.
-
-Acknowledgments
-
-This work builds upon original work done on multicast DNS by Bill
-Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
-grant #F30602-99-1-0523. The authors gratefully acknowledge their
-contribution to the current specification. Constructive input has also
-been received from Mark Andrews, Stuart Cheshire, Robert Elz, James
-Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Hattig, Thomas Narten,
-Erik Nordmark, Sander Van-Valkenburg and Tomohide Nagashima.
-
-Authors' Addresses
-
-Levon Esibov
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-
-EMail: levone@microsoft.com
-
-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
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-Intellectual Property Statement
-
-The IETF takes no position regarding the validity or scope of any
-intellectual property or other rights that might be claimed to pertain
-to the implementation or use of the technology described in this
-document or the extent to which any license under such rights might or
-might not be available; neither does it represent that it has made any
-effort to identify any such rights. Information on the IETF's
-procedures with respect to rights in standards-track and standards-
-related documentation can be found in BCP-11. Copies of claims of
-rights made available for publication and any assurances of licenses to
-be made available, or the result of an attempt made to obtain a general
-license or permission for the use of such proprietary rights by
-implementors or users of this specification can be obtained from the
-IETF Secretariat.
-
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary rights
-which may cover technology that may be required to practice this
-standard. Please address the information to the IETF Executive
-Director.
-
-Full Copyright Statement
-
-Copyright (C) The Internet Society (2001). 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 implementation 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
-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."
-
-Expiration Date
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 17]
-
-
-
-
-
-INTERNET-DRAFT Multicast DNS 15 November 2001
-
-
-This memo is filed as <draft-ietf-dnsext-mdns-07.txt>, and expires May
-22, 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 18]
-
-
--- /dev/null
+
+
+
+
+
+
+DNSEXT Working Group Levon Esibov
+INTERNET-DRAFT Bernard Aboba
+Category: Standards Track Dave Thaler
+<draft-ietf-dnsext-mdns-08.txt> Microsoft
+21 December 2001
+
+
+ Linklocal Multicast DNS (LMDNS)
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC 2026.
+
+Internet-Drafts are working documents of the Internet Engineering Task
+Force (IETF), its areas, and its working groups. Note that other groups
+may also distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time. It is inappropriate to use Internet-Drafts as reference material
+or to cite them other than as "work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+Copyright Notice
+
+Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+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
+name resolution in such environments, Linklocal Multicast DNS (LMDNS) is
+proposed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 1]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+Table of Contents
+
+1. Introduction .......................................... 3
+2. Name resolution using LMDNS ........................... 3
+ 2.1 Behavior of the sender and responder ............ 4
+3. Usage model ........................................... 7
+ 3.1 LMDNS configuration ............................. 8
+4. Sequence of events .................................... 9
+5. Conflict resolution ................................... 9
+ 5.1 Considerations for multiple interfaces .......... 11
+ 5.2 API issues ...................................... 12
+6. Security considerations ............................... 13
+7. IANA considerations ................................... 14
+8. Normative References .................................. 14
+9. Informative References ................................ 14
+Acknowledgments .............................................. 15
+Authors' Addresses ........................................... 15
+Intellectual Property Statement .............................. 16
+Full Copyright Statement ..................................... 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 2]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+1. Introduction
+
+Linklocal Multicast DNS (LMDNS) enables 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 name resolution for the names of the hosts on the
+local 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 ISP and the 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
+network.
+
+This document discusses Linklocal Multicast DNS (LMDNS), which operates
+on a separate port from DNS, with a distinct resolver cache, but does
+not change the format of DNS packets.
+
+Service discovery in general, as well as discovery of DNS servers using
+LMDNS in particular is outside of the scope of this document, as is name
+resolution over non-multicast capable media.
+
+In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
+"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
+described in [RFC2119].
+
+2. Name resolution using LMDNS
+
+While operating on a different port with a distinct resolver cache,
+LMDNS makes no change to the current format of DNS packets.
+
+Linklocal multicast DNS queries are sent to and received on port 5353
+using a LINKLOCAL address as specified in "Administratively Scoped IP
+Multicast" [RFC2365] for IPv4 and the "solicited name" LINKLOCAL
+multicast addresses for IPv6. The LMDNS LINKLOCAL address to be used
+for IPv4 is 224.0.0.251. LINKLOCAL addresses are used to prevent
+propagation of LMDNS traffic across routers, potentially flooding the
+network.
+
+Propagation of multicast DNS packets on the local link is considered
+sufficient to enable name resolution in small adhoc 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 proxy.
+
+By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, routers
+can provide name resolution for the names of IPv4 hosts on the local
+network. Where the DNS proxy supports AAAA RRs, resolution for the names
+of dual stack IPv6 hosts on the local network can also be provided using
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 3]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+this mechanism.
+
+Within small adhoc IPv6 networks, stateful autoconfiguration is the most
+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 LMDNS need not be enabled by
+default.
+
+In the future, multicast DNS may be defined to support greater than
+LINKLOCAL multicast scope. This would occur if LMDNS deployment is
+successful, the assumption that multicast DNS is not needed on multiple
+links proves incorrect, and multicast routing becomes ubiquitous. For
+example, it is not clear that this assumption will be valid in large
+adhoc networking scenarios.
+
+Once we have experience in LMDNS deployment in terms of administrative
+issues, usability and impact on the network it will be possible
+reevaluate which multicast scopes are appropriate for use with multicast
+DNS.
+
+2.1. Behavior of the sender and responder
+
+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
+responds to) a multicast query is called "responder". A host configured
+to be a "responder" MAY also be a "sender". A host configured not to be
+"responder" SHOULD NOT be a "sender". While hosts configured only as
+senders can detect name conflicts, they cannot notify other senders of
+potential conflicts for their name. Thus, implementation of both
+responder and sender functionality is encouraged.
+
+2.1.1. Behavior of senders
+
+A sender sends an LMDNS query for any legal Type of resource record
+(e.g. A, PTR, etc.) to the 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 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 [RFC2535], 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, described in
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 4]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+[RFC1321]. 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" [NodeInfo]). 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 resolved during a limited amount of time
+(LMDNS_TIMEOUT), then a sender MAY repeat the transmission of a query in
+order to assure themselves that the query has been received by a host
+capable of responding to the query.
+
+Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be
+repeated more often than once per second to reduce unnecessary network
+traffic. The delay between attempts should be randomized so as to avoid
+synchronization effects.
+
+2.1.2. Behavior of responders
+
+An LMDNS responder listens on port 5353 on the LINKLOCAL address.
+Responders MUST respond to multicast queries to those and only those
+names for which they are authoritative. As an example, computer
+"host.example.com." is authoritative for the domain "host.example.com.".
+On receiving a linklocal multicast DNS A record query for the name
+"host.example.com." such a host responds 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
+authoritative for all the domain names under the zone root except for
+the branches delegated into separate zones. Contrary to conventional DNS
+terminology, a responder is authoritative only for the zone root. For
+example the host "host.example.com." is not authoritative for the name
+"child.host.example.com." unless the host is configured with multiple
+names, including "host.example.com." and "child.host.example.com.". The
+purpose of limiting the name authority scope of a responder is to
+prevent complications that could be caused by coexistence of two or more
+hosts with the names representing child and parent (or grandparent)
+nodes in the DNS tree, for example, "host.example.com." and
+"child.host.example.com.".
+
+In this example (unless this limitation is introduced) a multicast query
+for an A record for the name "child.host.example.com." would result in
+two authoritative responses: name error received from
+"host.example.com.", and a requested A record - from
+"child.host.example.com.". To prevent this ambiguity, multicast enabled
+hosts could perform a dynamic update of the parent (or grandparent) zone
+with a delegation to a child zone. In this example a host
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 5]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+"child.host.example.com." would send a dynamic update for the NS and
+glue A record to "host.example.com.", but this approach significantly
+complicates implementation of multicast DNS and would not be acceptable
+for lightweight hosts.
+
+A response to a multicast query is composed in exactly the same manner
+as a response to the unicast DNS query as specified in [RFC1035].
+Responders MUST never respond using cached data, and the AA
+(Authoritative Answer) bit MUST be set. The response is sent to the
+sender via unicast. A response to an LMDNS query MUST have RCODE set to
+zero. Responses with RCODE set to zero are referred to in this document
+as "positively resolved". LMDNS responders may respond only to queries
+which they can resolve positively.
+
+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
+discard the response and resend the query over TCP or using EDNS0 with
+larger window using the unicast address of the responder. The RA
+(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
+it.
+
+2.1.3. LMDNS addressing
+
+For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic Configuration of
+IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect to
+source address selection, TTL settings, and acceptable
+source/destination address combinations. IPv6 is described in [RFC2460];
+IPv6 LINKLOCAL addressing is described in [RFC2373]. LMDNS queries and
+responses MUST obey the rules laid out in these documents.
+
+In composing an LMDNS response, the responder MUST set the Hop Limit
+field in the IPv6 header and the TTL field in IPv4 header of the LMDNS
+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 the LMDNS query
+is set to 255. If it is not, then sender MUST ignore the response.
+
+ Implementation note:
+
+ In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket
+ options are used to specify the TTL of outgoing unicast and multicast
+ packets. The IP_RECVTTL socket option is available on some platforms
+ to receive the IPv4 TTL of received packets with recvmsg(). [RFC2292]
+ specifies similar options for specifying and receiving the IPv6 Hop
+ Limit.
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 6]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+2.1.4. Use of DNS TTL
+
+The responder should use a pre-configured TTL value in the records
+returned in the LMDNS query response. Due to the TTL minimalization
+necessary when caching an RRset, all TTLs in an RRset MUST be set to the
+same value. In the additional and authority section of the response the
+responder includes the same records as a DNS server would insert in the
+response to the unicast DNS query.
+
+2.1.5. No/multiple responses
+
+The sender MUST anticipate receiving no replies to some multicast
+queries, in the event that no responders are available within the
+linklocal multicast scope, or in the event that no positive non-null
+responses exist for 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).
+
+The sender MUST anticipate receiving multiple replies to the same
+linklocal multicast query, in the event that several linklocal multicast
+DNS enabled computers 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. However, after receiving an initial response,
+the sender is not required to wait for LMDNS_TIMEOUT for additional
+responses.
+
+3. Usage model
+
+A host configured to be an LMDNS "responder" MUST also be configured as
+a "sender". A host not configured as a "responder" MUST NOT be a
+"sender". An LMDNS "sender" MAY multicast requests for any name. If
+that name is not qualified and does not end in a trailing dot, for the
+purposes of LMDNS, the implicit search order is as follows:
+
+[1] Request the name with the current domain appended.
+
+[2] Request just the name.
+
+This is the behavior suggested by [RFC1536]. LMDNS uses this technique
+to resolve unqualified host names.
+
+If a DNS server is running on a host that supports LMDNS, the DNS server
+MUST respond to LMDNS 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.
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 7]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+3.1. LMDNS configuration
+
+LMDNS usage can be configured manually or automatically. On interfaces
+where no manual or automatic configuration has been performed for a
+given protocol (IPv4 or IPv6), LMDNS SHOULD be enabled by default for
+that protocol.
+
+For IPv6, the stateless DNS discovery mechanisms described in "IPv6
+Stateless DNS Discovery" [DNSDisc] can be used to discover whether
+linklocal multicast DNS should be enabled or disabled on a per-interface
+basis.
+
+Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
+configure multicast DNS on an interface. The Multicast DNS Enable
+Option, described in [mDNSEnable], can be used to explicitly enable or
+disable use of linklocal multicast DNS on an interface for a given
+protocol, as well as to specify the order in which DNS and LMDNS is used
+on that interface.
+
+The Multicast DNS Enable Option affects only DNS resolver behavior, that
+is, how DNS resolution is performed, and whether LMDNS is used. The
+Multicast DNS Enable Option does not determine whether or in which order
+DNS itself is used for name resolution. This can be specified, for
+example, using the Name Service Search Option for DHCP, [RFC2937], which
+can be used to globally determine where DNS is used within the name
+service search order.
+
+If an interface has been configured for a given protocol via any
+automatic configuration mechanism which is able to supply DNS
+configuration information, then LMDNS SHOULD NOT be used on that
+interface for that protocol unless it has been explicitly enabled,
+whether via that mechanism or any other. This ensures that upgraded
+hosts do not change their default behavior, without requiring the source
+of the configuration information to be simultaneously updated. This
+implies that on the interface, the host will neither listen on the DNS
+LINKLOCAL multicast address, nor will it send queries to that address.
+
+Note that it is possible for LMDNS to be enabled for use with IPv6 at
+the same time it is disabled for IPv4, and vice versa. For example,
+where a home gateway implements a DNS proxy and DHCPv4, but not DHCPv6
+or DNS autoconfiguration, there may be no mechanism for allowing IPv6
+hosts to resolve the names of other IPv6 hosts on the home network. In
+this situation, LMDNS is useful for resolution of dynamic names, and it
+will be enabled for use with IPv6, even though it is disabled for use
+with IPv4.
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 8]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+4. Sequence of events
+
+The sequence of events for LMDNS usage is as follows:
+
+1. If a sender needs to resolve a query for a name
+ "host.example.com", then it sends a multicast query to the
+ LINKLOCAL multicast address.
+
+2. A responder responds to this query only if it is authoritative
+ for the domain name "host.example.com". The responder sends
+ a response to the sender via unicast over UDP.
+
+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
+ the protocol used) of the response is set to 255. The sender then
+ verifies compliance with the addressing requirements for IPv4,
+ described in [IPV4Link], and IPv6, described in [RFC2373]. If these
+ conditions are met, then the sender uses and caches the returned
+ response. If not, then the sender ignores the response and continues
+ waiting for the response.
+
+5. Conflict resolution
+
+There are some scenarios when multiple responders MAY respond to the
+same query. There are other scenarios when only one responder may
+respond to a query. Resource records for which the latter queries are
+submitted are referred as UNIQUE throughout this document. 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:
+
+ - 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
+ cluster name (assigned to multiple hosts in the cluster)
+ - only a single host may respond to a query for an A type record for
+ a hostname.
+
+Every responder that responds to a linklocal multicast DNS query and/or
+dynamic update request AND includes a UNIQUE record in the response:
+
+ 1. MUST verify that there is no other host within the scope of the
+ LMDNS query propagation that can return a DNS record
+ for the same name, type and class.
+ 2. MUST NOT include a UNIQUE resource record in the
+ response without having verified its uniqueness.
+
+Where a host is configured to respond to linklocal multicast DNS queries
+on more than one interface, the host MUST verify resource record
+uniqueness on each interface for each UNIQUE resource record that could
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 9]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+be used on that interface. To accomplish this, the host MUST multicast a
+dynamic DNS update request as specified in [RFC2136] for each new UNIQUE
+resource record. Uniqueness verification is carried out when the host:
+
+ - starts up or
+ - is configured to respond to the linklocal multicast DNS queries on
+ some interface or
+ - is configured to respond to the linklocal multicast DNS queries using
+ additional UNIQUE DNS records.
+
+Below we describe the data to be specified in the dynamic update
+request:
+
+Header section
+ contains values according to [RFC2136].
+
+Zone section
+ 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
+ SOA. The zone class in the zone section MUST be set to the class of
+ the UNIQUE record.
+
+Prerequisite section
+ This section MUST contain a record set whose semantics are
+ described in [RFC2136], Section 2.4.3 "RRset Does Not Exist",
+ requesting that RRs with the NAME and TYPE of the UNIQUE record do
+ not exist.
+
+Update section
+ This section MUST be left empty.
+
+Additional section
+ This section is set according to [RFC2136].
+
+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
+host MUST respond via unicast with the YXRRSET error, according to the
+rules described in Section 3 of [RFC2136].
+
+After the client receives an YXRRSET response to its dynamic update
+request stating that a UNIQUE resource record does not exist, the host
+MUST check 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 linklocal multicast
+queries and dynamic update requests.
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 10]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+Note that this name conflict detection mechanism doesn't prevent name
+conflicts when previously partitioned segments are connected by a
+bridge. In such a situation, name conflicts are detected when a sender
+receives more than one response to its linklocal multicast DNS query.
+In this case, the sender sends the first response that it received to
+all responders that responded to this query except the first one, using
+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
+verify that no other host within the linklocal multicast DNS scope is
+authoritative for the same name, using the dynamic DNS update request
+mechanism described above.
+
+Based on the result, the host detects whether there is a name conflict
+and acts as described above.
+
+5.1. Considerations for Multiple Interfaces
+
+A multi-homed host may elect to configure LMDNS on only one of its
+active interfaces. In many situations this will be adequate. However,
+should a host wish to configure LMDNS on more than one of its active
+interfaces, there are some additional precautions it MUST take.
+Implementers who are not planning to support linklocal multicast DNS on
+multiple interfaces simultaneously may skip this section.
+
+A multi-homed host checks the uniqueness of UNIQUE records as described
+in Section 5. The situation is illustrated in figure 1 below:
+
+ ---------- ----------
+ | | | |
+ [A] [myhost] [myhost]
+
+ Figure 1. LINKLOCAL name conflict
+
+In this situation, the multi-homed myhost will probe for, and defend,
+its host name on both interfaces. A conflict will be detected on one
+interface, but not the other. The multi-homed myhost will not be able to
+respond with a host RR for "myhost" on the interface on the right (see
+Figure 1). The multi-homed host may, however, be configured to use the
+"myhost" name on the interface on the left.
+
+
+
+
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 11]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+Since names are only unique per-link, hosts on different links could be
+using the same name. If an LMDNS client sends requests over multiple
+interfaces, and receives replies from more than one, the result returned
+to the client is defined by the implementation. The situation is
+illustrated in figure 2 below.
+
+ ---------- ----------
+ | | | |
+ [A] [myhost] [A]
+
+
+ Figure 2. Off-segment name conflict
+
+If host myhost is configured to use LMDNS on both interfaces, it will
+send LMDNS 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
+both interfaces.
+
+Host myhost will then forward a response from 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, since the conflicting
+host resides on a different link. Therefore it will continue using its
+name.
+
+Indeed, host myhost cannot distinguish between the situation shown in
+Figure 2, and that shown in Figure 3 where no conflict exists:
+
+ [A]
+ | |
+ ----- -----
+ | |
+ [myhost]
+
+ Figure 3. Multiple paths to same host
+
+This illustrates that the proposed name conflict resolution mechanism
+does not support detection or resolution of conflicts between hosts on
+different links. This problem can also occur with unicast DNS when a
+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
+of uniqueness of names within DNS.
+
+5.2. API issues
+
+[RFC2553] provides an API which can partially solve the name ambiguity
+problem for applications written to use this API, since the sockaddr_in6
+structure exposes the scope within which each scoped address exists, and
+this structure can be used for both IPv4 (using v4-mapped IPv6
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 12]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+addresses) and IPv6 addresses.
+
+Following the example in Figure 2, an application on 'myhost' issues the
+request getaddrinfo("A", ...) with ai_family=AF_INET6 and
+ai_flags=AI_ALL|AI_V4MAPPED. LMDNS requests will be sent from both
+interfaces and the resolver library will return a list containing
+multiple addrinfo structures, each with an associated sockaddr_in6
+structure. This list will thus contain the IPv4 and IPv6 addresses of
+both hosts responding to the name 'A'. Link-local addresses will have a
+sin6_scope_id value that disambiguates which interface is used to reach
+the address. Of course, to the application, Figures 2 and 3 are still
+indistinguishable, but this API allows the application to communicate
+successfully with any address in the list.
+
+6. Security Considerations
+
+This draft does not prescribe a means of securing the LMDNS 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. Such attacks also allow nodes
+to receive packets destined for other nodes. The protocol reduces the
+exposure to such threats in the absence of authentication by ignoring
+LMDNS query response packets received from off-link senders.
+
+In order to prevent responses to LMDNS queries from polluting the DNS
+cache, LMDNS implementations MUST use a distinct, isolated cache for
+LMDNS.
+
+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
+routers decrement the Hop Limit on all packets they forward, received
+packets containing a Hop Limit of 255 must have originated from a
+neighbor.
+
+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.
+Link-layer security will serve to secure LMDNS against the above threats
+if it is available. For example, where 802.11 "Wired Equivalency
+Privacy" (WEP) [IEEE80211] is implemented, a casual attacker is likely
+to be deterred from gaining access to the home network.
+
+The mechanism specified in this draft does not require use of DNSSEC.
+As a result, responses to LMDNS queries MAY NOT be authenticated. If
+authentication is desired, and a pre-arranged security configuration is
+possible, then IPsec ESP with a null-transform MAY be used to
+authenticate LMDNS responses. In a small network without a certificate
+authority, this can be most easily accomplished through configuration of
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 13]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+a group pre-shared key for trusted hosts.
+
+7. IANA Considerations
+
+This specification does not create any new name spaces for IANA
+administration. Since it uses a port (5353) and link scope multicast
+IPv4 address (224.0.0.251) previously allocated for use with LMDNS, no
+additional IANA allocations are required.
+
+8. Normative References
+
+[RFC1035] Mockapetris, P., "Domain Names - Implementation and
+ Specification", RFC 1035, November 1987.
+
+[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic
+ Updates in the Domain Name System (DNS UPDATE)", RFC
+ 2136, April 1997.
+
+[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP
+ 23, RFC 2365, July 1998.
+
+[RFC2373] Hinden, R., Deering, S., "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
+
+[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
+ 2937, September 2000.
+
+[IPV4Link] Cheshire, S., Aboba, B., "Dynamic Configuration of IPv4
+ Link-Local Addresses", Internet draft (work in progress),
+ draft-ietf-zeroconf-ipv4-linklocal-05.txt, November 2001.
+
+[mDNSEnable] Guttman, E., "DHCP Multicast DNS Enable Option", Internet
+ draft (work in progress), draft-guttman-mdns-
+ enable-01.txt, July 2001.
+
+9. Informative References
+
+[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ April 1992.
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 14]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+[RFC1536] Kumar, A., et. al. "DNS Implementation Errors and
+ Suggested Fixes", RFC 1536, October 1993.
+
+[RFC2292] Stevens, W., Thomas, M., "Advanced Sockets API for IPv6",
+ RFC 2292, February 1998.
+
+[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+[RFC2553] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic
+ Socket Interface Extensions for IPv6", RFC 2553, March
+ 1999.
+
+[IEEE80211] Information technology - Telecommunications and
+ information exchange between systems - Local and
+ metropolitan area networks - Specific Requirements Part
+ 11: Wireless LAN Medium Access Control (MAC) and
+ Physical Layer (PHY) Specifications, IEEE Std.
+ 802.11-1997, 1997.
+
+[DNSDisc] Thaler, D., Hagino, I., "IPv6 Stateless DNS Discovery",
+ Internet draft (work in progress), draft-ietf-ipngwg-dns-
+ discovery-02.txt, July 2001.
+
+[NodeInfo] Crawford, Matt, "IPv6 Node Information Queries", Internet
+ draft (work in progress), draft-ietf-ipn-gwg-icmp-name-
+ lookups-07.txt, August 2000.
+
+Acknowledgments
+
+This work builds upon original work done on multicast DNS by Bill
+Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
+grant #F30602-99-1-0523. The authors gratefully acknowledge their
+contribution to the current specification. Constructive input has also
+been received from Mark Andrews, Stuart Cheshire, Robert Elz, Rob
+Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Hattig,
+Thomas Narten, Erik Nordmark, Sander Van-Valkenburg and Tomohide
+Nagashima.
+
+Authors' Addresses
+
+Levon Esibov
+Microsoft Corporation
+One Microsoft Way
+Redmond, WA 98052
+
+EMail: levone@microsoft.com
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 15]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+Bernard Aboba
+Microsoft Corporation
+One Microsoft Way
+Redmond, WA 98052
+
+Phone: +1 425 706 6605
+EMail: bernarda@microsoft.com
+
+Dave Thaler
+Microsoft Corporation
+One Microsoft Way
+Redmond, WA 98052
+
+Phone: +1 425 703 8835
+EMail: dthaler@microsoft.com
+
+Intellectual Property Statement
+
+The IETF takes no position regarding the validity or scope of any
+intellectual property or other rights that might be claimed to pertain
+to the implementation or use of the technology described in this
+document or the extent to which any license under such rights might or
+might not be available; neither does it represent that it has made any
+effort to identify any such rights. Information on the IETF's
+procedures with respect to rights in standards-track and standards-
+related documentation can be found in BCP-11. Copies of claims of
+rights made available for publication and any assurances of licenses to
+be made available, or the result of an attempt made to obtain a general
+license or permission for the use of such proprietary rights by
+implementors or users of this specification can be obtained from the
+IETF Secretariat.
+
+The IETF invites any interested party to bring to its attention any
+copyrights, patents or patent applications, or other proprietary rights
+which may cover technology that may be required to practice this
+standard. Please address the information to the IETF Executive
+Director.
+
+Full Copyright Statement
+
+Copyright (C) The Internet Society (2001). 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 implementation 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
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 16]
+
+
+
+
+
+INTERNET-DRAFT Linklocal Multicast DNS 21 December 2001
+
+
+or references to the Internet Society or other Internet organizations,
+except as needed for the purpose of developing Internet standards in
+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."
+
+Expiration Date
+
+This memo is filed as <draft-ietf-dnsext-mdns-08.txt>, and expires
+June 22, 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 17]
+
+
projects / thirdparty / bind9.git / commitdiff
