draft-ietf-dnsext-mdns-44.txt   draft-ietf-dnsext-mdns-45.txt 
DNSEXT Working Group Bernard Aboba DNSEXT Working Group Bernard Aboba
INTERNET-DRAFT Dave Thaler INTERNET-DRAFT Dave Thaler
Category: Standards Track Levon Esibov Category: Standards Track Levon Esibov
<draft-ietf-dnsext-mdns-44.txt> Microsoft Corporation <draft-ietf-dnsext-mdns-45.txt> Microsoft Corporation
30 September 2005 6 October 2005
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 March 15, 2006. This Internet-Draft will expire on April 15, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2005. Copyright (C) The Internet Society 2005.
Abstract Abstract
The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
name resolution in scenarios in which conventional DNS name name resolution in scenarios in which conventional DNS name
resolution is not possible. LLMNR supports all current and future resolution is not possible. LLMNR supports all current and future
skipping to change at page 2, line 13 skipping to change at page 2, line 13
DNS. DNS.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements .................................... 4 1.1 Requirements .................................... 4
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 4
2. Name Resolution Using LLMNR ........................... 4 2. Name Resolution Using LLMNR ........................... 4
2.1 LLMNR Packet Format ............................. 5 2.1 LLMNR Packet Format ............................. 5
2.2 Sender Behavior ................................. 8 2.2 Sender Behavior ................................. 8
2.3 Responder Behavior .............................. 9 2.3 Responder Behavior .............................. 8
2.4 Unicast Queries and Responses ................... 11 2.4 Unicast Queries and Responses ................... 11
2.5 Off-link Detection .............................. 12 2.5 Off-link Detection .............................. 11
2.6 Responder Responsibilities ...................... 13 2.6 Responder Responsibilities ...................... 12
2.7 Retransmission and Jitter ....................... 13 2.7 Retransmission and Jitter ....................... 13
2.8 DNS TTL ......................................... 14 2.8 DNS TTL ......................................... 14
2.9 Use of the Authority and Additional Sections .... 14 2.9 Use of the Authority and Additional Sections .... 14
3. Usage model ........................................... 15 3. Usage model ........................................... 15
3.1 LLMNR Configuration ............................. 17 3.1 LLMNR Configuration ............................. 16
4. Conflict Resolution ................................... 18 4. Conflict Resolution ................................... 18
4.1 Uniqueness Verification ......................... 19 4.1 Uniqueness Verification ......................... 18
4.2 Conflict Detection and Defense .................. 20 4.2 Conflict Detection and Defense .................. 19
4.3 Considerations for Multiple Interfaces .......... 21 4.3 Considerations for Multiple Interfaces .......... 20
4.4 API issues ...................................... 22 4.4 API issues ...................................... 22
5. Security Considerations ............................... 22 5. Security Considerations ............................... 22
5.1 Denial of Service ............................... 23 5.1 Denial of Service ............................... 22
5.2 Spoofing ...............,........................ 23 5.2 Spoofing ...............,........................ 23
5.3 Authentication .................................. 24 5.3 Authentication .................................. 24
5.4 Cache and Port Separation ....................... 25 5.4 Cache and Port Separation ....................... 24
6. IANA considerations ................................... 25 6. IANA considerations ................................... 25
7. Constants ............................................. 25 7. Constants ............................................. 25
8. References ............................................ 26 8. References ............................................ 26
8.1 Normative References ............................ 26 8.1 Normative References ............................ 26
8.2 Informative References .......................... 27 8.2 Informative References .......................... 26
Acknowledgments .............................................. 28 Acknowledgments .............................................. 28
Authors' Addresses ........................................... 28 Authors' Addresses ........................................... 28
Intellectual Property Statement .............................. 29 Intellectual Property Statement .............................. 29
Disclaimer of Validity ....................................... 29 Disclaimer of Validity ....................................... 29
Copyright Statement .......................................... 29 Copyright Statement .......................................... 29
1. Introduction 1. Introduction
This document discusses Link Local Multicast Name Resolution (LLMNR), This document discusses Link Local Multicast Name Resolution (LLMNR),
which is based on the DNS packet format and supports all current and which is based on 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
conventional DNS name resolution is not possible. Usage scenarios
(discussed in more detail in Section 3.1) include situations in which
hosts are not configured with the address of a DNS server; where the
DNS server is unavailable or unreachable; where there is no DNS
server authoritative for the name of a host, or where the
authoritative DNS server does not have the desired RRs, as described
in Section 2.
Since LLMNR only operates on the local link, it cannot be considered Since LLMNR only operates on the local link, it cannot be considered
a substitute for DNS. Link-scope multicast addresses are used to a substitute for DNS. Link-scope multicast addresses are used to
prevent propagation of LLMNR traffic across routers, potentially prevent propagation of LLMNR traffic across routers, potentially
flooding the network. LLMNR queries can also be sent to a unicast flooding the network. LLMNR queries can also be sent to a unicast
address, as described in Section 2.4. address, as described in Section 2.4.
Propagation of LLMNR packets on the local link is considered Propagation of LLMNR packets on the local link is considered
sufficient to enable name resolution in small networks. In such sufficient to enable name resolution in small networks. In such
networks, if a network has a gateway, then typically the network is networks, if a network has a gateway, then typically the network is
able to provide DNS server configuration. Configuration issues are able to provide DNS server configuration. Configuration issues are
skipping to change at page 9, line 11 skipping to change at page 8, line 41
When multiple valid LLMNR responses are received with the 'C' bit When multiple valid LLMNR responses are received with the 'C' bit
set, they SHOULD be concatenated and treated in the same manner that set, they SHOULD be concatenated and treated in the same manner that
multiple RRs received from the same DNS server would be. However, multiple RRs received from the same DNS server would be. However,
responses with the 'C' bit set SHOULD NOT be concatenated with responses with the 'C' bit set SHOULD NOT be concatenated with
responses with the 'C' bit clear; instead, only the responses with responses with the 'C' bit clear; instead, only the responses with
the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are
received along with error response(s), then the error responses are received along with error response(s), then the error responses are
silently discarded. silently discarded.
If error responses are received from both DNS and LLMNR, then the
lowest RCODE value should be returned. For example, if either DNS or
LLMNR receives a response with RCODE=0, then this should returned to
the caller.
Since the responder may order the RRs in the response so as to Since the responder may order the RRs in the response so as to
indicate preference, the sender SHOULD preserve ordering in the indicate preference, the sender SHOULD preserve ordering in the
response to the querying application. response to the querying application.
2.3. Responder Behavior 2.3. Responder Behavior
An LLMNR response MUST be sent to the sender via unicast. An LLMNR response MUST be sent to the sender via unicast.
Upon configuring an IP address, responders typically will synthesize Upon configuring an IP address, responders typically will synthesize
corresponding A, AAAA and PTR RRs so as to be able to respond to corresponding A, AAAA and PTR RRs so as to be able to respond to
skipping to change at page 14, line 25 skipping to change at page 13, line 47
SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect
all possible responses. When multiple valid answers are received, all possible responses. When multiple valid answers are received,
they may first be concatenated, and then treated in the same manner they may first be concatenated, and then treated in the same manner
that multiple RRs received from the same DNS server would. A unicast that multiple RRs received from the same DNS server would. A unicast
query sender considers the query answered after the first response is query sender considers the query answered after the first response is
received. received.
Since it is possible for a response with the 'C' bit clear to be Since it is possible for a response with the 'C' bit clear to be
followed by a response with the 'C' bit set, an LLMNR sender SHOULD followed by a response with the 'C' bit set, an LLMNR sender SHOULD
be prepared to process additional responses for the purposes of be prepared to process additional responses for the purposes of
conflict detection and LLMNR_TIMEOUT estimation, even after it has conflict detection, even after it has considered a query answered.
considered a query answered.
In order to avoid synchronization, the transmission of each LLMNR In order to avoid synchronization, the transmission of each LLMNR
query and response SHOULD delayed by a time randomly selected from query and response SHOULD delayed by a time randomly selected from
the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
responders responding with names which they have previously responders responding with names which they have previously
determined to be UNIQUE (see Section 4 for details). determined to be UNIQUE (see Section 4 for details).
2.8. DNS TTL 2.8. DNS TTL
The responder should insert a pre-configured TTL value in the records The responder should insert a pre-configured TTL value in the records
skipping to change at page 15, line 34 skipping to change at page 15, line 8
the additional section, but otherwise MUST ignore the additional the additional section, but otherwise MUST ignore the additional
section. section.
Senders MUST NOT cache RRs from the authority or additional section Senders MUST NOT cache RRs from the authority or additional section
of a response as answers, though they may be used for other purposes of a response as answers, though they may be used for other purposes
such as negative caching. such as negative caching.
3. Usage Model 3. Usage Model
LLMNR is a peer-to-peer name resolution protocol that is not intended LLMNR is a peer-to-peer name resolution protocol that is not intended
as a replacement for DNS. By default, an LLMNR sender SHOULD send as a replacement for DNS; rather, it enables name resolution in
LLMNR queries only for single-label names. In order to reduce scenarios in which conventional DNS name resolution is not possible.
unnecessary DNS queries, stub resolvers supporting both DNS and LLMNR This includes situations in which hosts are not configured with the
SHOULD avoid sending DNS queries for single-label names. An LLMNR address of a DNS server; where the DNS server is unavailable or
sender SHOULD NOT be enabled to send a query for any name, except unreachable; where there is no DNS server authoritative for the name
where security mechanisms (described in Section 5.3) can be utilized. of a host, or where the authoritative DNS server does not have the
desired RRs.
If LLMNR is given higher priority than DNS among the enabled name By default, an LLMNR sender SHOULD send LLMNR queries only for
resolution mechanisms, a denial of service attack on the DNS server single-label names. In order to reduce unnecessary DNS queries, stub
would not be necessary in order to poison the LLMNR cache, since resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS
LLMNR queries would be sent even when the DNS server is available. queries for single-label names. An LLMNR sender SHOULD NOT be
In addition, the LLMNR cache, once poisoned, would take precedence enabled to send a query for any name, except where security
over the DNS cache, eliminating the benefits of cache separation. As mechanisms (described in Section 5.3) can be utilized.
a result, LLMNR is only used as a name resolution mechanism of last
resort, and queries SHOULD NOT be sent unless one of the following Regardless of whether security mechanisms can be utilized, LLMNR
conditions are met: queries SHOULD NOT be sent unless one of the following conditions are
met:
[1] No manual or automatic DNS configuration has been performed. [1] No manual or automatic DNS configuration has been performed.
If DNS server address(es) have been configured, a If DNS server address(es) have been configured, a
host SHOULD attempt to reach DNS servers over all protocols host SHOULD attempt to reach DNS servers over all protocols
on which DNS server address(es) are configured, prior to sending on which DNS server address(es) are configured, prior to sending
LLMNR queries. For dual stack hosts configured with DNS server LLMNR queries. For dual stack hosts configured with DNS server
address(es) for one protocol but not another, this implies that address(es) for one protocol but not another, this implies that
DNS queries SHOULD be sent over the protocol configured with DNS queries SHOULD be sent over the protocol configured with
a DNS server, prior to sending LLMNR queries. a DNS server, prior to sending LLMNR queries.
skipping to change at page 17, line 6 skipping to change at page 16, line 30
policies are likely to avoid unnecessary LLMNR queries. policies are likely to avoid unnecessary LLMNR queries.
[RFC1536] Section 3 describes zero answer bugs, which if addressed [RFC1536] Section 3 describes zero answer bugs, which if addressed
will also reduce unnecessary LLMNR queries. will also reduce unnecessary LLMNR queries.
[RFC1536] Section 6 describes name error bugs and recommended [RFC1536] Section 6 describes name error bugs and recommended
searchlist processing that will reduce unnecessary RCODE=3 searchlist processing that will reduce unnecessary RCODE=3
(authoritative name) errors, thereby also reducing unnecessary LLMNR (authoritative name) errors, thereby also reducing unnecessary LLMNR
queries. queries.
If error responses are received from both DNS and LLMNR, then the
lowest RCODE value should be returned. For example, if either DNS or
LLMNR receives a response with RCODE=0, then this should returned to
the caller.
3.1. LLMNR Configuration 3.1. LLMNR Configuration
LLMNR usage MAY be configured manually or automatically on a per LLMNR usage MAY be configured manually or automatically on a per
interface basis. By default, LLMNR responders SHOULD be enabled on interface basis. By default, LLMNR responders SHOULD be enabled on
all interfaces, at all times. Enabling LLMNR for use in situations all interfaces, at all times. Enabling LLMNR for use in situations
where a DNS server has been configured will result in a change in where a DNS server has been configured will result in a change in
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.
skipping to change at page 25, line 4 skipping to change at page 24, line 35
LLMNR queries and responses or LLMNR responses to multicast LLMNR queries and responses or LLMNR responses to multicast
queries. In a small network without a certificate authority, this queries. In a small network without a certificate authority, this
can be most easily accomplished through configuration of a group can be most easily accomplished through configuration of a group
pre-shared key for trusted hosts. As with TSIG, this does not pre-shared key for trusted hosts. As with TSIG, this does not
protect against forgery by an attacker with access to the group protect against forgery by an attacker with access to the group
pre-shared key. pre-shared key.
[c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to [c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to
support DNSSEC, LLMNR implementations MAY be configured with trust support DNSSEC, LLMNR implementations MAY be configured with trust
anchors, or they MAY make use of keys obtained from DNS queries. anchors, or they MAY make use of keys obtained from DNS queries.
Since LLMNR does not support "delegated trust" (CD or AD bits), Since LLMNR does not support "delegated trust" (CD or AD bits),
LLMNR implementations cannot make use of DNSSEC unless they are LLMNR implementations cannot make use of DNSSEC unless they are
DNSSEC aware. Unlike approaches [a] or [b], DNSSEC permits a DNSSEC-aware and support validation. Unlike approaches [a] or [b],
responder to demonstrate ownership of a name, not just membership DNSSEC permits a responder to demonstrate ownership of a name, not
within a trusted group. As a result, it enables protection against just membership within a trusted group. As a result, it enables
forgery. protection against forgery.
5.4. Cache and Port Separation 5.4. 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 LLMNR on each interface. The use of separate caches is most
effective when LLMNR is used as a name resolution mechanism of last effective when LLMNR is used as a name resolution mechanism of last
resort, since this minimizes the opportunities for poisoning the resort, since this minimizes the opportunities for poisoning the
LLMNR cache, and decreases reliance on it. LLMNR cache, and decreases reliance on it.
LLMNR operates on a separate port from DNS, reducing the likelihood LLMNR operates on a separate port from DNS, reducing the likelihood
that a DNS server will unintentionally respond to an LLMNR query. that a DNS server will unintentionally respond to an LLMNR query.
If LLMNR is given higher priority than DNS among the enabled name
resolution mechanisms, a denial of service attack on the DNS server
would not 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 LLMNR cache, once poisoned, would take precedence
over the DNS cache, eliminating the benefits of cache separation. As
a result, LLMNR SHOULD NOT be used as a primary name resolution
mechanism.
6. IANA Considerations 6. IANA Considerations
LLMNR requires allocation of port 5355 for both TCP and UDP. LLMNR requires allocation of port 5355 for both TCP and UDP.
LLMNR requires allocation of link-scope multicast IPv4 address LLMNR requires allocation of link-scope multicast IPv4 address
224.0.0.252, as well as link-scope multicast IPv6 address 224.0.0.252, as well as link-scope multicast IPv6 address
FF02:0:0:0:0:0:1:3. FF02:0:0:0:0:0:1:3.
This specification creates two new name spaces: the LLMNR namespace This specification creates two new name spaces: the LLMNR namespace
and the reserved bits in the LLMNR header. The reserved bits in the and the reserved bits in the LLMNR header. The reserved bits in the
skipping to change at page 25, line 48 skipping to change at page 25, line 38
administration of the LLMNR namespace will piggyback on the administration of the LLMNR namespace will piggyback on the
administration of the DNS namespace. administration of the DNS namespace.
The rights to use a fully qualified domain name (FQDN) within LLMNR The rights to use a fully qualified domain name (FQDN) within LLMNR
are obtained coincident with acquiring the rights to use that name are obtained coincident with acquiring the rights to use that name
within DNS. Those wishing to use a FQDN within LLMNR should first within DNS. Those wishing to use a FQDN within LLMNR should first
acquire the rights to use the corresponding FQDN within DNS. Using a acquire the rights to use the corresponding FQDN within DNS. Using a
FQDN within LLMNR without ownership of the corresponding name in DNS FQDN within LLMNR without ownership of the corresponding name in DNS
creates the possibility of conflict and therefore is discouraged. creates the possibility of conflict and therefore is discouraged.
LLMNR responders that have not obtained the rights to use of an FQDN LLMNR responders may self-allocate a name within the single-label
may self-allocate a name within the single-label name space, first name space, first defined in [RFC1001]. Since single-label names are
defined in [RFC1001]. Since single-label names are not unique, no not unique, no registration process is required.
registration process is required.
7. Constants 7. Constants
The following timing constants are used in this protocol; they are The following timing constants are used in this protocol; they are
not intended to be user configurable. not intended to be user configurable.
JITTER_INTERVAL 100 ms JITTER_INTERVAL 100 ms
LLMNR_TIMEOUT 1 second (if set statically on all interfaces) LLMNR_TIMEOUT 1 second (if set statically on all interfaces)
100 ms (IEEE 802 media, including IEEE 802.11) 100 ms (IEEE 802 media, including IEEE 802.11)
 End of changes. 19 change blocks. 
53 lines changed or deleted 52 lines changed or added

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