draft-ietf-dnsext-mdns-36.txt   draft-ietf-dnsext-mdns-37.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-36.txt> Microsoft <draft-ietf-dnsext-mdns-37.txt> Microsoft
8 September 2004 20 October 2004
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2005. This Internet-Draft will expire on April 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2004. All rights reserved. Copyright (C) The Internet Society 2004. All rights reserved.
Abstract Abstract
Today, with the rise of home networking, there are an increasing Today, with the rise of home networking, there are an increasing
number of ad-hoc networks operating without a Domain Name System number of ad-hoc networks operating without a Domain Name System
(DNS) server. The goal of Link-Local Multicast Name Resolution (DNS) server. The goal of Link-Local Multicast Name Resolution
skipping to change at page 2, line 31 skipping to change at page 2, line 31
3.1 LLMNR configuration ............................. 15 3.1 LLMNR configuration ............................. 15
4. Conflict resolution ................................... 17 4. Conflict resolution ................................... 17
4.1 Considerations for multiple interfaces .......... 18 4.1 Considerations for multiple interfaces .......... 18
4.2 API issues ...................................... 19 4.2 API issues ...................................... 19
5. Security considerations ............................... 20 5. Security considerations ............................... 20
5.1 Scope restriction ............................... 20 5.1 Scope restriction ............................... 20
5.2 Usage restriction ............................... 21 5.2 Usage restriction ............................... 21
5.3 Cache and port separation ....................... 22 5.3 Cache and port separation ....................... 22
5.4 Authentication .................................. 22 5.4 Authentication .................................. 22
6. IANA considerations ................................... 22 6. IANA considerations ................................... 22
7. References ............................................ 22 7. References ............................................ 23
7.1 Normative References ............................ 22 7.1 Normative References ............................ 23
7.2 Informative References .......................... 23 7.2 Informative References .......................... 23
Acknowledgments .............................................. 24 Acknowledgments .............................................. 25
Authors' Addresses ........................................... 25 Authors' Addresses ........................................... 25
Intellectual Property Statement .............................. 25 Intellectual Property Statement .............................. 25
Disclaimer of Validity ....................................... 26 Disclaimer of Validity ....................................... 26
Full Copyright Statement ..................................... 26 Copyright Statement .......................................... 26
1. Introduction 1. Introduction
This document discusses Link Local Multicast Name Resolution (LLMNR), This document discusses Link Local Multicast Name Resolution (LLMNR),
which utilizes the DNS packet format and supports all current and which utilizes the DNS packet format and supports all current and
future DNS formats, types and classes. LLMNR operates on a separate future DNS formats, types and classes. LLMNR operates on a separate
port from the Domain Name System (DNS), with a distinct resolver port from the Domain Name System (DNS), with a distinct resolver
cache. cache.
The goal of LLMNR is to enable name resolution in scenarios in which The goal of LLMNR is to enable name resolution in scenarios in which
skipping to change at page 5, line 25 skipping to change at page 5, line 25
default behavior without a simultaneous update to configuration default behavior without a simultaneous update to configuration
information. Where this is considered undesirable, LLMNR SHOULD NOT information. Where this is considered undesirable, LLMNR SHOULD NOT
be enabled by default, so that hosts will neither listen on the link- be enabled by default, so that hosts will neither listen on the link-
scope multicast address, nor will they send queries to that address. scope multicast address, nor will they send queries to that address.
An LLMNR sender may send a request for any name. However, by An LLMNR sender may send a request for any name. However, by
default, LLMNR requests SHOULD be sent only when one of the following default, LLMNR requests SHOULD be sent only when one of the following
conditions are met: conditions are met:
[1] No manual or automatic DNS configuration has been [1] No manual or automatic DNS configuration has been
performed. If an interface has been configured with DNS performed. If DNS server address(es) have been
server address(es), or if DNS server address(es) have configured, then LLMNR SHOULD NOT be used as the
been configured which apply to all interfaces, then primary name resolution mechanism, although it MAY
LLMNR SHOULD NOT be used as the primary name resolution be used as a secondary name resolution mechanism.
mechanism on that interface, although it MAY be used
as a secondary name resolution mechanism.
[2] DNS servers do not respond. [2] DNS servers do not respond.
[3] DNS servers respond to a DNS query with RCODE=3 [3] DNS servers respond to a DNS query with RCODE=3
(Authoritative Name Error) or RCODE=0, and an empty (Authoritative Name Error) or RCODE=0, and an empty
answer section. answer section.
A typical sequence of events for LLMNR usage is as follows: A typical sequence of events for LLMNR usage is as follows:
[a] DNS servers are not configured or do not respond to a [a] DNS servers are not configured or do not respond to a
skipping to change at page 13, line 13 skipping to change at page 13, line 12
that address MUST be valid on the local link over which that address MUST be valid on the local link over which
LLMNR is used. LLMNR is used.
[b] If an IPv4 address is returned, it MUST be reachable [b] If an IPv4 address is returned, it MUST be reachable
through the link over which LLMNR is used. through the link over which LLMNR is used.
[c] If a name is returned (for example in a CNAME, MX [c] If a name is returned (for example in a CNAME, MX
or SRV RR), the name MUST be resolvable on the local or SRV RR), the name MUST be resolvable on the local
link over which LLMNR is used. link over which LLMNR is used.
Routable addresses MUST be included first in the response, if Where multiple addresses represent valid responses to a query, the
available. This encourages use of routable address(es) for order in which the addresses are returned is as follows:
establishment of new connections.
[d] If the source address of the query is a link-scope address,
then the responder SHOULD include a link-scope address first
in the response, if available.
[e] If the source address of the query is a routable address,
then the responder MUST include a routable address first
in the response, if available.
2.7. Retransmission and jitter 2.7. Retransmission and jitter
An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
when to retransmit an LLMNR query and how long to collect responses when to retransmit an LLMNR query and how long to collect responses
to an LLMNR query. to an LLMNR query.
If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
then a sender SHOULD repeat the transmission of the query in order to then a sender SHOULD repeat the transmission of the query in order to
assure that it was received by a host capable of responding to it. assure that it was received by a host capable of responding to it.
skipping to change at page 20, line 48 skipping to change at page 21, line 4
Limit (IPv6) fields to one (1) on TCP queries and responses. Limit (IPv6) fields to one (1) on TCP queries and responses.
Using a TTL of one (1) to set up a TCP connection in order to send a 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 unicast LLMNR query reduces the likelihood of both denial of service
attacks and spoofed responses. Checking that an LLMNR query is sent attacks and spoofed responses. Checking that an LLMNR query is sent
to a link-scope multicast address should prevent spoofing of to a link-scope multicast address should prevent spoofing of
multicast queries by off-link attackers. 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 possible for an attacker to spoof a response to a query (such as an A
(such as an A or AAAA query for a popular Internet host), and by or AAAA query for a popular Internet host), and by using a TTL or Hop
using a TTL or Hop Limit field larger than one (1), for the forged Limit field larger than one (1), for the forged response to reach the
response to reach the LLMNR sender. LLMNR sender.
When LLMNR queries are sent to a link-scope multicast address, it is When LLMNR queries are sent to a link-scope multicast address, it is
possible that some routers may not properly implement link-scope possible that some routers may not properly implement link-scope
multicast, or that link-scope multicast addresses may leak into the multicast, or that link-scope multicast addresses may leak into the
multicast routing system. multicast routing system.
Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than
one in an LLMNR UDP response may enable denial of service attacks one in an LLMNR UDP response may enable denial of service attacks
across the Internet. However, since LLMNR responders only respond to across the Internet. However, since LLMNR responders only respond to
queries for which they are authoritative, and LLMNR does not provide queries for which they are authoritative, and LLMNR does not provide
skipping to change at page 21, line 46 skipping to change at page 21, line 50
attacker will need to respond more quickly to provide its own attacker will need to respond more quickly to provide its own
response prior to arrival of the response from a legitimate response prior to arrival of the response from a legitimate
responder. If an LLMNR query is sent for an off-link host, spoofing a responder. If an LLMNR query is sent for an off-link host, spoofing a
response in a timely way is not difficult, since a legitimate response in a timely way is not difficult, since a legitimate
response will never be received. response will never be received.
The vulnerability is more serious if LLMNR is given higher priority The vulnerability is more serious if LLMNR is given higher priority
than DNS among the enabled name resolution mechanisms. In such a than DNS among the enabled name resolution mechanisms. In such a
configuration, a denial of service attack on the DNS server would not configuration, a denial of service attack on the DNS server would not
be necessary in order to poison the LLMNR cache, since LLMNR queries be necessary in order to poison the LLMNR cache, since LLMNR queries
would be sent even when the DNS server is available. In addition, the would be sent even when the DNS server is available. In addition,
LLMNR cache, once poisoned, would take precedence over the DNS cache, the LLMNR cache, once poisoned, would take precedence over the DNS
eliminating the benefits of cache separation. As a result, LLMNR is cache, eliminating the benefits of cache separation. As a result,
only used as a name resolution mechanism of last resort. LLMNR is only used as a name resolution mechanism of last resort.
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, when LLMNR is used as a name resolution mechanism of last resort,
since this minimizes the opportunities for poisoning the LLMNR cache, since this minimizes the opportunities for poisoning the LLMNR cache,
and decreases reliance on it. and decreases reliance on it.
skipping to change at page 24, line 21 skipping to change at page 24, line 27
[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
Socket Interface Extensions for IPv6", RFC 2553, March 1999. Socket Interface Extensions for IPv6", RFC 2553, 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.
[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for [RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of Link-Local IPv4 Addresses", RFC 3927, October 2004.
[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of [DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
Caching", IEEE/ACM Transactions on Networking, Volume 10, Caching", IEEE/ACM Transactions on Networking, Volume 10,
Number 5, pp. 589, October 2002. Number 5, pp. 589, October 2002.
[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local [DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
unicast addresses to communicate with recursive DNS servers", unicast addresses to communicate with recursive DNS servers",
Internet draft (work in progress), draft-ietf-ipv6-dns- Internet draft (work in progress), draft-ietf-ipv6-dns-
discovery-07.txt, October 2002. discovery-07.txt, October 2002.
[IPV4Link]
Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of IPv4 Link-Local Addresses", Internet draft (work in
progress), draft-ietf-zeroconf-ipv4-linklocal-17.txt, July
2004.
[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- [POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
Portable Operating System Interface (POSIX). Open Group Portable Operating System Interface (POSIX). Open Group
Technical Standard: Base Specifications, Issue 6, December Technical Standard: Base Specifications, Issue 6, December
2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
[LLMNREnable] [LLMNREnable]
Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
in progress), draft-guttman-mdns-enable-02.txt, April 2002. in progress), draft-guttman-mdns-enable-02.txt, April 2002.
 End of changes. 

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