draft-ietf-dnsext-mdns-23.txt   draft-ietf-dnsext-mdns-24.txt 
DNSEXT Working Group Levon Esibov DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler Category: Standards Track Dave Thaler
<draft-ietf-dnsext-mdns-23.txt> Microsoft <draft-ietf-dnsext-mdns-24.txt> Microsoft
11 September 2003 27 September 2003
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
2.3 Unicast queries ................................. 6 2.3 Unicast queries ................................. 6
2.4 Addressing ...................................... 7 2.4 Addressing ...................................... 7
2.5 Off-link detection .............................. 7 2.5 Off-link detection .............................. 7
2.6 Retransmissions ................................. 8 2.6 Retransmissions ................................. 8
2.7 DNS TTL ......................................... 9 2.7 DNS TTL ......................................... 9
2.8 Use of the authority and additional sections .... 9 2.8 Use of the authority and additional sections .... 9
3. Usage model ........................................... 9 3. Usage model ........................................... 9
3.1 Unqualified names ............................... 10 3.1 Unqualified names ............................... 10
3.2 LLMNR configuration ............................. 11 3.2 LLMNR configuration ............................. 11
4. Conflict resolution ................................... 12 4. Conflict resolution ................................... 12
4.1 Considerations for multiple interfaces .......... 14 4.1 Considerations for multiple interfaces .......... 13
4.2 API issues ...................................... 15 4.2 API issues ...................................... 15
5. Security considerations ............................... 15 5. Security considerations ............................... 15
5.1 Scope restriction ............................... 16 5.1 Scope restriction ............................... 16
5.2 Usage restriction ............................... 16 5.2 Usage restriction ............................... 17
5.3 Cache and port separation ....................... 17 5.3 Cache and port separation ....................... 17
5.4 Authentication .................................. 17 5.4 Authentication .................................. 18
6. IANA considerations ................................... 18 6. IANA considerations ................................... 18
7. References ............................................ 18 7. References ............................................ 18
7.1 Normative References ............................ 18 7.1 Normative References ............................ 18
7.2 Informative References .......................... 18 7.2 Informative References .......................... 19
Acknowledgments .............................................. 19 Acknowledgments .............................................. 20
Authors' Addresses ........................................... 20 Authors' Addresses ........................................... 20
Intellectual Property Statement .............................. 20 Intellectual Property Statement .............................. 21
Full Copyright Statement ..................................... 21 Full Copyright Statement ..................................... 21
1. Introduction 1. Introduction
This document discusses Link Local Multicast Name Resolution (LLMNR), This document discusses Link Local Multicast Name Resolution (LLMNR),
which operates on a separate port from the Domain Name System (DNS), which operates on a separate port from the Domain Name System (DNS),
with a distinct resolver cache, but does not change the format of DNS with a distinct resolver cache, but does not change the format of DNS
packets. LLMNR supports all current and future DNS formats, types and packets. LLMNR supports all current and future DNS formats, types and
classes. However, since LLMNR only operates on the local link, it classes. However, since LLMNR only operates on the local link, it
cannot be considered a substitute for DNS. cannot be considered a substitute for DNS.
skipping to change at page 4, line 11 skipping to change at page 4, line 11
In this document, several words are used to signify the requirements of In this document, several words are used to signify the requirements of
the specification. These words are often capitalized. The key words the specification. These words are often capitalized. The key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119]. interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
Responder A host that listens to LLMNR queries, and responds to Responder A host that listens to LLMNR queries, and responds to those
those for which it is authoritative. for which it is authoritative.
Sender A host that sends an LLMNR query. Typically a host is Sender A host that sends an LLMNR query. Typically a host is
configured as both a sender and a responder. However, a configured as both a sender and a responder. However, a host
host may be configured as a sender, but not a responder may be configured as a sender, but not a responder or as a
or as a responder, but not a sender. responder, but not a sender.
Routable address Routable address
An address other than a Link-Local address. This An address other than a Link-Local address. This includes
includes globally routable addresses, as well as private globally routable addresses, as well as private addresses.
addresses.
2. Name resolution using LLMNR 2. Name resolution using LLMNR
A typical sequence of events for LLMNR usage is as follows: A typical sequence of events for LLMNR usage is as follows:
[1] A sender needs to resolve a query for a name "host.example.com", [1] A sender needs to resolve a query for a name "host.example.com",
so it sends an LLMNR query to the link-scope multicast address(es) so it sends an LLMNR query to the link-scope multicast address(es)
defined in Section 2.4. defined in Section 2.4.
[2] A responder responds to this query only if it is authoritative [2] A responder responds to this query only if it is authoritative
skipping to change at page 10, line 20 skipping to change at page 10, line 17
in negative responses due to missing inverse mappings or NS records that in negative responses due to missing inverse mappings or NS records that
point to nonexistent or inappropriate hosts. Given this, support for point to nonexistent or inappropriate hosts. Given this, support for
LLMNR as a secondary name resolution mechanism has the potential to LLMNR as a secondary name resolution mechanism has the potential to
result in a large number of inappropriate queries without the following result in a large number of inappropriate queries without the following
additional restrictions: additional restrictions:
[1] If a DNS query does not receive a response, prior to falling [1] If a DNS query does not receive a response, prior to falling
back to LLMNR, the query SHOULD be retransmitted at least back to LLMNR, the query SHOULD be retransmitted at least
once. once.
[2] A responder with both link-local and routable addresses [2] A sender SHOULD send LLMNR queries for PTR RRs
MUST respond to LLMNR queries for A/AAAA RRs only with
routable address(es). This encourages use of routable
address(es) for establishment of new connections.
[3] A sender SHOULD send LLMNR queries for PTR RRs
via unicast, as specified in Section 2.3. via unicast, as specified in Section 2.3.
It is the responsibility of the responder to ensure that RRs returned in It is the responsibility of the responder to ensure that RRs returned in
LLMNR responses MUST only include values that are valid on the local LLMNR responses MUST only include values that are valid on the local
interface, such as IPv4 or IPv6 addresses valid on the local link or interface, such as IPv4 or IPv6 addresses valid on the local link or
names defended using the mechanism described in Section 4. In names defended using the mechanism described in Section 4. In
particular: particular:
[1] If a link-scope IPv6 address is returned in a AAAA RR, that [1] If a link-scope IPv6 address is returned in a AAAA RR, that
address MUST be valid on the local link over which LLMNR is address MUST be valid on the local link over which LLMNR is
used. used.
[2] If an IPv4 address is returned, it MUST be reachable through [2] If an IPv4 address is returned, it MUST be reachable through
the link over which LLMNR is used. the link over which LLMNR is used.
[3] If a name is returned (for example in a CNAME, MX [3] If a name is returned (for example in a CNAME, MX
or SRV RR), the name MUST be valid on the local interface. or SRV RR), the name MUST be valid on the local interface.
Routable addresses MUST be included first in the response, if available.
This encourages use of routable address(es) for establishment of new
connections.
3.1. Unqualified names 3.1. Unqualified names
If a name is not qualified, for the purposes of LLMNR the implicit If a name is not qualified, for the purposes of LLMNR the implicit
search order is as follows: search order is as follows:
[1] Request the name with the current domain appended. [1] Request the name with the current domain appended.
[2] Request the name with the root domain (".") appended. [2] Request the name with the root domain (".") appended.
This is the behavior suggested by [RFC1536]. This is the behavior suggested by [RFC1536].
skipping to change at page 15, line 44 skipping to change at page 15, line 44
both hosts responding to the name 'A'. Link-local addresses will have a 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 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 the address. Of course, to the application, Figures 2 and 3 are still
indistinguishable, but this API allows the application to communicate indistinguishable, but this API allows the application to communicate
successfully with any address in the list. successfully with any address in the list.
5. Security Considerations 5. Security Considerations
LLMNR is by nature a peer-to-peer name resolution protocol. It is LLMNR is by nature a peer-to-peer name resolution protocol. It is
therefore inherently more vulnerable than DNS, since existing DNS therefore inherently more vulnerable than DNS, since existing DNS
security mechanisms are difficult to apply to LLMNR and an attacker only security mechanisms are difficult to apply to LLMNR. While tools exist
needs to be misconfigured to answer an LLMNR query with incorrect to alllow an attacker to spoof a response to a DNS query, spoofing a
information. response to an LLMNR query is easier since the query is sent to a link-
scope multicast address, which can propagate to multiple switch ports.
In order to address the security vulnerabilities, the following In order to address the security vulnerabilities, the following
mechanisms are contemplated: mechanisms are contemplated:
[1] Scope restrictions. [1] Scope restrictions.
[2] Usage restrictions. [2] Usage restrictions.
[3] Cache and port separation. [3] Cache and port separation.
skipping to change at page 16, line 27 skipping to change at page 16, line 29
other hosts by allocating the same name. Such attacks also allow hosts other hosts by allocating the same name. Such attacks also allow hosts
to receive packets destined for other hosts. to receive packets destined for other hosts.
Since LLMNR is typically deployed in situations where no trust model can Since LLMNR is typically deployed in situations where no trust model can
be assumed, it is likely that LLMNR queries and responses will be be assumed, it is likely that LLMNR queries and responses will be
unauthenticated. In the absence of authentication, LLMNR reduces the unauthenticated. In the absence of authentication, LLMNR reduces the
exposure to such threats by utilizing queries sent to a link-scope exposure to such threats by utilizing queries sent to a link-scope
multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6)
fields to one (1) on both queries and responses. fields to one (1) on both queries and responses.
A TTL of one (1) was chosen so as to limit the likelihood that LLMNR can
be used to launch denial of service attacks. For example, were the TTL
of an LLMNR Response to be set to a value larger than one (1), an
attacker could send a large volume of queries from a spoofed source
address, causing an off-link target to be deluged with responses.
Utilizing a TTL of one (1) in LLMNR responses ensures that they will not
be forwarded off-link. Using a TTL of one (1) to set up a TCP connection
in order to send a unicast LLMNR query reduces the likelihood of both
denial of service attacks and spoofed responses. Checking that an LLMNR
query is sent to a link-scope multicast address should prevent spoofing
of multicast queries by off-link attackers.
While this limits the ability of off-link attackers to spoof LLMNR While this limits the ability of off-link attackers to spoof LLMNR
queries and responses, it does not eliminate it. For example, it is queries and responses, it does not eliminate it. For example, it is
possible for an attacker to spoof a response to a frequent query (such possible for an attacker to spoof a response to a frequent query (such
as an A/AAAA query for a popular Internet host), and using a TTL or Hop as an A/AAAA query for a popular Internet host), and by using a TTL or
Limit field larger than one (1), for the forged response to reach the Hop Limit field larger than one (1), for the forged response to reach
LLMNR sender. There also are scenarios such as public "hotspots" where the LLMNR sender. There also are scenarios such as public "hotspots"
attackers can be present on the same link. where attackers can be present on the same link.
These threats are most serious in wireless networks such as 802.11, These threats are most serious in wireless networks such as 802.11,
since attackers on a wired network will require physical access to the since attackers on a wired network will require physical access to the
home network, while wireless attackers may reside outside the home. home network, while wireless attackers may reside outside the home.
Link-layer security can be of assistance against these threats if it is Link-layer security can be of assistance against these threats if it is
available. available.
5.2. Usage restriction 5.2. Usage restriction
As noted in Section 3, LLMNR is intended for usage in a limited set of As noted in Section 3, LLMNR is intended for usage in a limited set of
scenarios. scenarios.
If an interface has been configured via any automatic configuration While LLMNR can be used to resolve any name, if an interface has been
mechanism which is able to supply DNS configuration information, then configured with DNS server address(es), then LLMNR SHOULD NOT be used as
LLMNR SHOULD NOT be used as the primary name resolution mechanism on the primary name resolution mechanism on that interface, although it MAY
that interface, although it MAY be used as a name resolution mechanism be used as a name resolution mechanism of last resort.
of last resort.
Note: enabling LLMNR for use in situations where a DNS server has been If an LLMNR query is sent whenever a DNS server does not respond in a
configured will result in upgraded hosts changing their default behavior timely way, then an attacker can poison the LLMNR cache by responding to
without a simultaneous update to configuration information. Where this the query with incorrect information. To some extent, these
is considered undesirable, LLMNR SHOULD NOT be enabled by default, so vulnerabilities exist today, since DNS response spoofing tools are
that hosts will neither listen on the link-scope multicast address, nor available that can allow an attacker to respond to a query more quickly
will it send queries to that address. than a distant DNS server.
Use of LLMNR as a name resolution mechanism increases security Since LLMNR queries are sent and responded to on the local-link, an
vulnerabilities. For example, if an LLMNR query is sent whenever a DNS attacker will need to respond more quickly to provide its own response
server does not respond in a timely way, then an attacker can execute a prior to arrival of the response from a legitimate responder. If an
denial of service attack on the DNS server(s) and then poison the LLMNR LLMNR query is sent for an off-link host, spoofing a response in a
cache by responding to the resulting LLMNR queries with incorrect timely way is not difficult, since a legitimate response will never be
information. received.
The vulnerability is more serious if LLMNR is given higher priority than The vulnerability is more serious if LLMNR is given higher priority than
DNS among the enabled name resolution mechanisms. In such a DNS among the enabled name resolution mechanisms. In such a
configuration, a denial of service attack on the DNS server would not be configuration, a denial of service attack on the DNS server would not be
necessary in order to poison the LLMNR cache, since LLMNR queries would necessary in order to poison the LLMNR cache, since LLMNR queries would
be sent even when the DNS server is available. In addition, the LLMNR be sent even when the DNS server is available. In addition, the LLMNR
cache, once poisoned, would take precedence over the DNS cache, cache, once poisoned, would take precedence over the DNS cache,
eliminating the benefits of cache separation. As a result, LLMNR is eliminating the benefits of cache separation. As a result, LLMNR is only
best thought of as a name resolution mechanism of last resort. used as a name resolution mechanism of last resort.
Note: enabling LLMNR for use in situations where a DNS server has been
configured will result in upgraded hosts changing their default behavior
without a simultaneous update to configuration information. Where this
is considered undesirable, LLMNR SHOULD NOT be enabled by default, so
that hosts will neither listen on the link-scope multicast address, nor
will they send queries to that address.
5.3. Cache and port separation 5.3. Cache and port separation
In order to prevent responses to LLMNR queries from polluting the DNS In order to prevent responses to LLMNR queries from polluting the DNS
cache, LLMNR implementations MUST use a distinct, isolated cache for cache, LLMNR implementations MUST use a distinct, isolated cache for
LLMNR on each interface. The use of separate caches is most effective LLMNR on each interface. The use of separate caches is most effective
when LLMNR is used as a name resolution mechanism of last resort, since when LLMNR is used as a name resolution mechanism of last resort, since
this minimizes the opportunities for poisoning the LLMNR cache, and this minimizes the opportunities for poisoning the LLMNR cache, and
decreases reliance on it. decreases reliance on it.
LLMNR operates on a separate port from DNS, reducing the likelihood that LLMNR operates on a separate port from DNS, reducing the likelihood that
a DNS server will unintentionally respond to an LLMNR query. a DNS server will unintentionally respond to an LLMNR query.
5.4. Authentication 5.4. Authentication
LLMNR does not require use of DNSSEC, and as a result, responses to LLMNR does not require use of DNSSEC, and as a result, responses to
skipping to change at page 18, line 26 skipping to change at page 18, line 43
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987. Specification", RFC 1035, November 1987.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
NCACHE)", RFC 2308, March 1998. RFC 2308, March 1998.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
23, RFC 2365, July 1998. 2365, July 1998.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
IANA Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 2434, October
October 1998. 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
RFC 2535, March 1999. 2535, March 1999.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
7.2. Informative References 7.2. Informative References
[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and [RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
Suggested Fixes", RFC 1536, October 1993. Fixes", RFC 1536, October 1993.
[RFC2136] Vixie, P., et al., "Dynamic Updates in the Domain Name [RFC2136] Vixie, P., et al., "Dynamic Updates in the Domain Name System
System (DNS UPDATE)", RFC 2136, April 1997. (DNS UPDATE)", RFC 2136, April 1997.
[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for [RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
IPv6", RFC 2292, February 1998. RFC 2292, February 1998.
[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
"Basic Socket Interface Extensions for IPv6", RFC 2553, Socket Interface Extensions for IPv6", RFC 2553, March 1999.
March 1999.
[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC [RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
2937, September 2000. 2937, September 2000.
[DHCPv6DNS] Droms, R., "A Guide to Implementing Stateless DHCPv6 [DHCPv6DNS]
Service", Internet draft (work in progress), draft-droms- Droms, R., "A Guide to Implementing Stateless DHCPv6 Service",
Internet draft (work in progress), draft-droms-
dhcpv6-stateless-guide-01.txt, October 2002. dhcpv6-stateless-guide-01.txt, October 2002.
[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness [DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
of Caching", IEEE/ACM Transactions on Networking, Volume Caching", IEEE/ACM Transactions on Networking, Volume 10,
10, Number 5, pp. 589, October 2002. Number 5, pp. 589, October 2002.
[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site [DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
local unicast addresses to communicate with recursive DNS unicast addresses to communicate with recursive DNS servers",
servers", Internet draft (work in progress), draft-ietf- Internet draft (work in progress), draft-ietf-ipv6-dns-
ipv6-dns-discovery-07.txt, October 2002. discovery-07.txt, October 2002.
[IPV4Link] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic [IPV4Link]
Configuration of IPv4 Link-Local Addresses", Internet Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
draft (work in progress), draft-ietf-zeroconf- of IPv4 Link-Local Addresses", Internet draft (work in
ipv4-linklocal-09.txt, September 2003. progress), draft-ietf-zeroconf-ipv4-linklocal-10.txt, October
2003.
[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft [LLMNREnable]
(work in progress), draft-guttman-mdns-enable-02.txt, Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
April 2002. in progress), draft-guttman-mdns-enable-02.txt, April 2002.
[NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet [NodeInfo]
draft (work in progress), draft-ietf-ipn-gwg-icmp-name- Crawford, M., "IPv6 Node Information Queries", Internet draft
(work in progress), draft-ietf-ipn-gwg-icmp-name-
lookups-09.txt, May 2002. lookups-09.txt, May 2002.
Acknowledgments Acknowledgments
This work builds upon original work done on multicast DNS by Bill This work builds upon original work done on multicast DNS by Bill
Manning and Bill Woodcock. Bill Manning's work was funded under DARPA Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
grant #F30602-99-1-0523. The authors gratefully acknowledge their grant #F30602-99-1-0523. The authors gratefully acknowledge their
contribution to the current specification. Constructive input has also contribution to the current specification. Constructive input has also
been received from Mark Andrews, Stuart Cheshire, Randy Bush, Robert been received from Mark Andrews, Stuart Cheshire, Randy Bush, Robert
Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron
skipping to change at page 21, line 39 skipping to change at page 22, line 14
Open Issues Open Issues
Open issues with this specification are tracked on the following web Open issues with this specification are tracked on the following web
site: site:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
Expiration Date Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-23.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-24.txt>, and expires
February 22, 2004. February 22, 2004.
 End of changes. 

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