DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler
-<draft-ietf-dnsext-mdns-10.txt> Microsoft
-23 March 2002
+<draft-ietf-dnsext-mdns-11.txt> Microsoft
+20 July 2002
Linklocal Multicast Name Resolution (LLMNR)
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, Link-Local Multicast Name
-Resolution (LLMNR) is proposed.
-
-
+Resolution (LLMNR) is proposed. LLMNR supports all current and future
+DNS formats, types and classes, while operating on a separate port from
+DNS, and with a distinct resolver cache.
-INTERNET-DRAFT LLMNR 23 March 2002
+INTERNET-DRAFT LLMNR 20 July 2002
Table of Contents
-
1. Introduction .......................................... 3
+ 1.1 Requirements .................................... 3
+ 1.2 Terminology ..................................... 3
2. Name resolution using LLMNR ........................... 3
- 2.1 Behavior of the sender and responder ............ 4
-3. Usage model ........................................... 7
+ 2.1 Sender behavior ................................. 4
+ 2.2 Responder behavior .............................. 5
+ 2.3 Addressing ...................................... 6
+ 2.4 TTL ............................................. 7
+ 2.5 No/multiple responses ........................... 7
+3. Usage model ........................................... 8
3.1 LLMNR configuration ............................. 8
4. Sequence of events .................................... 9
-5. Conflict resolution ................................... 9
+5. Conflict resolution ................................... 10
5.1 Considerations for multiple interfaces .......... 11
- 5.2 API issues ...................................... 12
+ 5.2 API issues ...................................... 13
6. Security considerations ............................... 13
- 6.1 Scope restriction ............................... 13
+ 6.1 Scope restriction ............................... 14
6.2 Usage restriction ............................... 14
6.3 Cache and port separation ....................... 15
6.4 Authentication .................................. 15
7. IANA considerations ................................... 15
-8. Normative References .................................. 15
+8. Normative References .................................. 16
9. Informative References ................................ 16
Acknowledgments .............................................. 17
Authors' Addresses ........................................... 17
-
-
-
-
-
-INTERNET-DRAFT LLMNR 23 March 2002
+INTERNET-DRAFT LLMNR 20 July 2002
1. Introduction
This document discusses Link-Local Multicast Name Resolution (LLMNR),
which operates on a separate port from DNS, with a distinct resolver
-cache, but does not change the format of DNS packets.
+cache, but does not change the format of DNS packets. LLMNR supports all
+current and future DNS formats, types and classes.
The goal of LLMNR is to enable name resolution in scenarios in which
conventional DNS name resolution is not possible. These include
LLMNR in particular is outside of the scope of this document, as is name
resolution over non-multicast capable media.
+1.1. Requirements
+
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC2119].
+1.2. Terminology
+
+Responder A host that listens to (but not necessarily responds to)
+ a LLMNR query is called "responder".
+
+Sender A host that sends an LLMNR query. The same host may be
+ configured as a "sender", but not a "responder" and vice
+ versa, i.e. as a "responder", but not a "sender".
+
2. Name resolution using LLMNR
While operating on a different port with a distinct resolver cache,
LLMNR queries are sent to and received on port 5353 using a LINKLOCAL
address as specified in "Administratively Scoped IP Multicast" [RFC2365]
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 3]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 20 July 2002
+
+
for IPv4 and the "solicited name" LINKLOCAL multicast addresses for
IPv6, and using a unicast addresses in a few scenarios described below
in Section 3. The LLMNR LINKLOCAL address to be used for IPv4 is
well as a DNS proxy and dynamic DNS, home gateways can provide name
resolution for the names of IPv4 hosts on the local network.
-
-
-Esibov, Aboba & Thaler Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 23 March 2002
-
-
For small IPv6 networks, equivalent functionality can be provided by a
home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as
well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name
reevaluate which multicast scopes are appropriate for use with multicast
name resolution mechanisms.
-2.1. Behavior of the sender and responder
-
-For the purpose of this document a host that sends a LLMNR query is
-called a "sender", while a host that listens to (but not necessarily
-responds to) a LLMNR query is called "responder". Although the same host
-may be configured as a "sender", but not a "responder" and vice versa,
-i.e. as a "responder", but not a "sender", the host configured as a
-"responder" MUST act as a sender by using LLMNR dynamic update requests
-to verify the uniqueness of names as described in Section 5.
-
-2.1.1. Behavior of senders
+2.1. Sender behavior
A sender sends an LLMNR query for any legal Type of resource record
(e.g. A, PTR, etc.) to the LINKLOCAL address. Notice that in some
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
-INTERNET-DRAFT LLMNR 23 March 2002
+INTERNET-DRAFT LLMNR 20 July 2002
+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
-[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.
+alphabetic characters in lower case. The first label of the FQDN in the
+query is then hashed using the MD5 algorithm, described in [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 LLMNR query is not resolved during a limited amount of time
(LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in
traffic. The delay between attempts should be randomized so as to avoid
synchronization effects.
-2.1.2. Behavior of responders
+2.2. Responder behavior
A responder listens on port 5353 on the LINKLOCAL address and on the
unicast address(es) that could be set as the source address(es) when the
-responder responds to the LLMNR query. Responders MUST respond to LLMNR
-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 LLMNR 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.
+responder responds to the LLMNR query. The host configured as a
+"responder" MUST act as a sender by using LLMNR dynamic update requests
+to verify the uniqueness of names as described in Section 5.
+
+Responders MUST NOT respond to LLMNR queries for names they are not
+authoritative for. Responders SHOULD respond to LLMNR queries for names
+and addresses they are authoritative for. This applies to both forward
+and reverse lookups.
+
+As an example, assume that computer "host.example.com." is authoritative
+for the domain "host.example.com.". On receiving a LLMNR A resource
+record query for the name "host.example.com." the host responds with A
+record(s) that contain IP address(es) in the RDATA of the resource
+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 LLMNR query for
-an A record for the name "child.host.example.com." would result in two
+terminology, an LLMNR responder is authoritative only for the zone root.
-INTERNET-DRAFT LLMNR 23 March 2002
+INTERNET-DRAFT LLMNR 20 July 2002
+
+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.". As a result, "host" cannot reply to a query
+for "child" with NXDOMAIN. 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 LLMNR 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, LLMNR enabled hosts could perform a dynamic update of
Even if the RA bit is set in the response header, the sender MUST ignore
it.
-2.1.3. LLMNR addressing
+2.3. Addressing
For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic Configuration of
IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect to
IPv6 LINKLOCAL addressing is described in [RFC2373]. LLMNR queries and
responses MUST obey the rules laid out in these documents.
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 6]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 20 July 2002
+
+
In composing an LLMNR response, the responder MUST set the Hop Limit
field in the IPv6 header and the TTL field in IPv4 header of the LLMNR
response to 255. The sender MUST verify that the Hop Limit field in IPv6
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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 23 March 2002
-
-
Limit.
-2.1.4. Use of LLMNR TTL
+2.4. TTL
The responder should use a pre-configured TTL value in the records
returned in the LLMNR query response. Due to the TTL minimalization
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
+2.5. No/multiple responses
The sender MUST anticipate receiving no replies to some LLMNR queries,
in the event that no responders are available within the linklocal
resolver treats it as a response that no records of the specified type
and class for the specified name exist (NXRRSET).
+Since the responder MUST NOT respond to queries for names it is not
+authoritative for, a responder MUST NOT respond to an A, A6 or AAAA RR
+query with an NXRRSET. However, for other queries, such a response is
+possible; for example, if the host has a AAAA RR, but no MX RR, and an
+MX RR query is received.
+
The sender MUST anticipate receiving multiple replies to the same LLMNR
query, in the event that several LLMNR enabled computers receive the
query and respond with valid answers. When this occurs, the responses
However, after receiving an initial response, the sender is not required
to wait for LLMNR_TIMEOUT for additional responses.
-3. Usage model
-The same host may be configured as a "sender", but not a "responder" and
-vice versa (as a "responder", but not "sender"). However, the host
-configured as a "responder" MUST at least use "sender"'s capability to
-send LLMNR dynamic update requests to verify the uniqueness of the names
-as described in Section 5. An LLMNR "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 LLMNR, 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]. LLMNR uses this technique
-to resolve unqualified host names.
-If a DNS server is running on a host that supports LLMNR, the DNS server
-MUST respond to LLMNR 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]
-Esibov, Aboba & Thaler Standards Track [Page 7]
+INTERNET-DRAFT LLMNR 20 July 2002
+
+
+3. Usage model
+The same host may be configured as a "sender", but not a "responder" and
+vice versa (as a "responder", but not "sender"). However, a host
+configured as a "responder" MUST at least use a "sender's" capability to
+send LLMNR dynamic update requests to verify the uniqueness of the
+names, as described in Section 5. An LLMNR "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 LLMNR, the implicit search order is
+as follows:
+[1] Request the name with the current domain appended.
+[2] Request just the name.
-INTERNET-DRAFT LLMNR 23 March 2002
+This is the behavior suggested by [RFC1536]. LLMNR uses this technique
+to resolve unqualified host names. The same host MAY use LLMNR queries
+for the resolution of unqualified host names, and conventional DNS
+queries for resolution of other DNS names.
+If a DNS server is running on a host that supports LLMNR, the DNS server
+MUST respond to LLMNR queries only for the RRSets owned by the host on
+which the server is running, but MUST NOT respond for other records for
+which the server is authoritative.
A sender MUST NOT send a unicast LLMNR query except when:
A type LLMNR query for the name "host.example.com." it authoritatively
responds to the query.
-The same host MAY use LLMNR queries for the resolution of the local
-names, and conventional DNS queries for resolution of other DNS names.
-
3.1. LLMNR configuration
LLMNR usage can be configured manually or automatically. On interfaces
For IPv6, the stateless DNS discovery mechanisms described in "IPv6
Stateless DNS Discovery" [DNSDisc] or "Using DHCPv6 for DNS
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 8]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 20 July 2002
+
+
Configuration in Hosts" [DHCPv6DNS] can be used to discover whether
LLMNR should be enabled or disabled on a per-interface basis.
via DHCPv6. As a result, unless the DNS proxy supports client update, it
will not be able to respond to AAAA RR queries for local names sent over
IPv4 or IPv6, preventing IPv6 hosts from resolving the names of other
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 23 March 2002
-
-
IPv6 hosts on the local link. In this situation, LLMNR enables
resolution of dynamic names, and it will be enabled for use with IPv6,
even though it is disabled for use with IPv4.
response. If not, then the sender ignores the response and continues
waiting for the response.
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 9]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 20 July 2002
+
+
5. Conflict resolution
There are some scenarios when multiple responders MAY respond to the
2. MUST NOT include a UNIQUE resource record in the
response without having verified its uniqueness.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 23 March 2002
-
-
Where a host is configured to respond to LLMNR 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
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
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 10]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 20 July 2002
+
+
the UNIQUE record.
Prerequisite section
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 LLMNR queries and dynamic update requests. If not, then it MUST NOT
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 23 March 2002
-
-
use the UNIQUE resource record in response to LLMNR queries and dynamic
update requests.
should a host wish to configure LLMNR on more than one of its active
interfaces, there are some additional precautions it MUST take.
Implementers who are not planning to support LLMNR on multiple
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 11]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 20 July 2002
+
+
interfaces simultaneously may skip this section.
A multi-homed host checks the uniqueness of UNIQUE records as described
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 LLMNR 23 March 2002
-
-
Since names are only unique per-link, hosts on different links could be
using the same name. If an LLMNR client sends requests over multiple
interfaces, and receives replies from more than one, the result returned
host resides on a different link. Therefore it will continue using its
name.
+
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 12]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 20 July 2002
+
+
Indeed, host myhost cannot distinguish between the situation shown in
Figure 2, and that shown in Figure 3 where no conflict exists:
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 LLMNR 23 March 2002
-
-
addresses) and IPv6 addresses.
Following the example in Figure 2, an application on 'myhost' issues the
In order to address the security vulnerabilities, the following
mechanisms are contemplated:
+
+
+Esibov, Aboba & Thaler Standards Track [Page 13]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 20 July 2002
+
+
[1] Scope restrictions.
[2] Usage restrictions.
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
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 23 March 2002
-
-
a neighbor.
While restricting ignoring packets received from off-link senders
listen on the LINKLOCAL multicast address, nor will it send queries to
that address.
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 14]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 20 July 2002
+
+
Violation of this guideline can significantly increases security
vulnerabilities. For example, if an LLMNR query were to be sent
whenever a DNS server did not respond in a timely way, then an attacker
configuration of additional DNS servers or DNS server clustering is
recommended; LLMNR is not an appropriate "failsafe" mechanism.
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 23 March 2002
-
-
6.3. Cache and port separation
In order to prevent responses to LLMNR queries from polluting the DNS
This specification does not create any new name spaces for IANA
administration. Since it uses a port (5353) and link scope multicast
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 15]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 20 July 2002
+
+
IPv4 address (224.0.0.251) previously allocated for use with LLMNR, no
additional IANA allocations are required.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP
23, RFC 2365, July 1998.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 23 March 2002
-
-
[RFC2373] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 16]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 20 July 2002
+
+
October 1998.
[RFC2553] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic
draft (work in progress), draft-ietf-ipn-gwg-icmp-name-
lookups-08.txt, July 2001.
-
-
-Esibov, Aboba & Thaler Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 23 March 2002
-
-
Acknowledgments
This work builds upon original work done on multicast DNS by Bill
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
-
-
-
-
-
-
-
-
-
-
+Esibov, Aboba & Thaler Standards Track [Page 17]
-Esibov, Aboba & Thaler Standards Track [Page 17]
+INTERNET-DRAFT LLMNR 20 July 2002
+EMail: bernarda@microsoft.com
-INTERNET-DRAFT LLMNR 23 March 2002
+Dave Thaler
+Microsoft Corporation
+One Microsoft Way
+Redmond, WA 98052
+Phone: +1 425 703 8835
+EMail: dthaler@microsoft.com
Intellectual Property Statement
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
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 18]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 20 July 2002
+
+
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
-Esibov, Aboba & Thaler Standards Track [Page 18]
-INTERNET-DRAFT LLMNR 23 March 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 19]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 20 July 2002
Expiration Date
-This memo is filed as <draft-ietf-dnsext-mdns-10.txt>, and expires
-October 22, 2002.
+This memo is filed as <draft-ietf-dnsext-mdns-11.txt>, and expires
+February 22, 2003.
-Esibov, Aboba & Thaler Standards Track [Page 19]
+Esibov, Aboba & Thaler Standards Track [Page 20]
projects / thirdparty / bind9.git / commitdiff
