draft-ietf-dnsext-mdns-42.txt   draft-ietf-dnsext-mdns-43.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-42.txt> Microsoft Corporation <draft-ietf-dnsext-mdns-43.txt> Microsoft Corporation
4 August 2005 29 August 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 February 15, 2006. This Internet-Draft will expire on March 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 ............................. 6 2.1 LLMNR Packet Format ............................. 6
2.2 Sender Behavior ................................. 9 2.2 Sender Behavior ................................. 9
2.3 Responder Behavior .............................. 9 2.3 Responder Behavior .............................. 10
2.4 Unicast Queries and Responses ................... 11 2.4 Unicast Queries and Responses ................... 12
2.5 Off-link Detection .............................. 12 2.5 Off-link Detection .............................. 13
2.6 Responder Responsibilities ...................... 13 2.6 Responder Responsibilities ...................... 13
2.7 Retransmission and Jitter ....................... 13 2.7 Retransmission and Jitter ....................... 14
2.8 DNS TTL ......................................... 15 2.8 DNS TTL ......................................... 15
2.9 Use of the Authority and Additional Sections .... 15 2.9 Use of the Authority and Additional Sections .... 15
3. Usage model ........................................... 15 3. Usage model ........................................... 16
3.1 LLMNR Configuration ............................. 16 3.1 LLMNR Configuration ............................. 17
4. Conflict Resolution ................................... 18 4. Conflict Resolution ................................... 18
4.1 Uniqueness Verification ......................... 18 4.1 Uniqueness Verification ......................... 19
4.2 Conflict Detection and Defense .................. 19 4.2 Conflict Detection and Defense .................. 20
4.3 Considerations for Multiple Interfaces .......... 20 4.3 Considerations for Multiple Interfaces .......... 21
4.4 API issues ...................................... 21 4.4 API issues ...................................... 22
5. Security Considerations ............................... 22 5. Security Considerations ............................... 22
5.1 Denial of Service ............................... 22 5.1 Denial of Service ............................... 23
5.2 Spoofing ...............,........................ 22 5.2 Spoofing ...............,........................ 23
5.3 Authentication .................................. 23 5.3 Authentication .................................. 24
5.4 Cache and Port Separation ....................... 24 5.4 Cache and Port Separation ....................... 25
6. IANA considerations ................................... 24 6. IANA considerations ................................... 25
7. Constants ............................................. 25 7. Constants ............................................. 25
8. References ............................................ 25 8. References ............................................ 25
8.1 Normative References ............................ 25 8.1 Normative References ............................ 25
8.2 Informative References .......................... 26 8.2 Informative References .......................... 26
Acknowledgments .............................................. 27 Acknowledgments .............................................. 27
Authors' Addresses ........................................... 27 Authors' Addresses ........................................... 28
Intellectual Property Statement .............................. 28 Intellectual Property Statement .............................. 28
Disclaimer of Validity ....................................... 28 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.
skipping to change at page 5, line 23 skipping to change at page 5, line 23
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.
An LLMNR sender may send a request for any name. However, by By default, LLMNR queries MAY 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 performed. [1] No manual or automatic DNS configuration has been performed.
If DNS server address(es) have been configured, then LLMNR If DNS server address(es) have been configured, then LLMNR
SHOULD NOT be used as the primary name resolution mechanism, SHOULD NOT be used as the primary name resolution mechanism,
although it MAY be used as a secondary name resolution although it MAY be used as a secondary name resolution
mechanism. For dual stack hosts configured with DNS server mechanism. A dual stack host SHOULD attempt to reach DNS
address(es) for one protocol but not another, this implies servers overall protocols on which DNS server address(es) are
that DNS queries SHOULD be sent over the protocol configured configured, prior to sending LLMNR queries. For dual stack
with a DNS server, prior to sending LLMNR queries. hosts configured with DNS server address(es) for one protocol
but not another, this inplies that DNS queries SHOULD be sent
over the protocol configured with a DNS server, prior to
sending LLMNR queries.
[2] All attempts to resolve the name via DNS on all interfaces [2] All attempts to resolve the name via DNS on all interfaces
have failed after exhausting the searchlist. This can occur have failed after exhausting the searchlist. This can occur
because DNS servers did not respond, or because they because DNS servers did not respond, or because they
responded to DNS queries with RCODE=3 (Authoritative Name responded to DNS queries with RCODE=3 (Authoritative Name
Error) or RCODE=0, and an empty answer section. A dual Error) or RCODE=0, and an empty answer section. Where a
stack host SHOULD attempt to reach DNS servers over all single resolver call generates DNS queries for A and AAAA RRs,
protocols on which DNS server address(es) are configured, an implementation MAY choose not to send LLMNR queries if any
prior to use of LLMNR. of the DNS queries is successful. An LLMNR query SHOULD only
be sent for the originally requested name; a searchlist
is not used to form additional LLMNR queries.
While these conditions are necessary for sending an LLMNR query, they
are not sufficient. While an LLMNR sender MAY send a query for any
name, it also MAY impose additional conditions on sending LLMNR
queries. For example, a sender configured with a DNS server MAY send
LLMNR queries only for unqualified names and for fully qualified
domain names within configured zones.
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 attempts to resolve the [a] DNS servers are not configured or attempts to resolve the
name via DNS have failed, after exhausting the searchlist. name via DNS have failed, after exhausting the searchlist.
Also, the name to be queried satisfies the restrictions
imposed by the implementation.
[b] An LLMNR sender sends an LLMNR query to the link-scope [b] An LLMNR sender sends an LLMNR query to the link-scope
multicast address(es) defined above, unless a unicast multicast address(es), unless a unicast query is indicated,
query is indicated. A sender SHOULD send LLMNR queries as specified in Section 2.4.
for PTR RRs via unicast, as specified in Section 2.4.
[c] A responder responds to this query only if it is authoritative [c] A responder responds to this query only if it is authoritative
for the domain name in the query. A responder responds to a for the domain name in the query. A responder responds to a
multicast query by sending a unicast UDP response to the sender. multicast query by sending a unicast UDP response to the sender.
Unicast queries are responded to as indicated in Section 2.4. Unicast queries are responded to as indicated in Section 2.4.
[d] Upon reception of the response, the sender processes it. [d] Upon reception of the response, the sender processes it.
Further details of sender and responder behavior are provided in the The sections that follow provide further details on sender and
sections that follow. responder behavior.
2.1. LLMNR Packet Format 2.1. LLMNR Packet Format
LLMNR is based on the DNS packet format defined in [RFC1035] Section LLMNR is based on the DNS packet format defined in [RFC1035] Section
4 for both queries and responses. LLMNR implementations SHOULD send 4 for both queries and responses. LLMNR implementations SHOULD send
UDP queries and responses only as large as are known to be UDP queries and responses only as large as are known to be
permissible without causing fragmentation. When in doubt a maximum permissible without causing fragmentation. When in doubt a maximum
packet size of 512 octets SHOULD be used. LLMNR implementations MUST packet size of 512 octets SHOULD be used. LLMNR implementations MUST
accept UDP queries and responses as large as the smaller of the link accept UDP queries and responses as large as the smaller of the link
MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22 MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
skipping to change at page 9, line 14 skipping to change at page 9, line 33
responders MUST silently discard LLMNR queries with NSCOUNT not responders MUST silently discard LLMNR queries with NSCOUNT not
equal to zero. equal to zero.
ARCOUNT ARCOUNT
An unsigned 16 bit integer specifying the number of resource An unsigned 16 bit integer specifying the number of resource
records in the additional records section. Additional record records in the additional records section. Additional record
section processing is described in Section 2.9. section processing is described in Section 2.9.
2.2. Sender Behavior 2.2. Sender Behavior
A sender may send an LLMNR query for any legal resource record type A sender MAY send an LLMNR query for any legal resource record type
(e.g., A, AAAA, SRV, etc.) to the link-scope multicast address. (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
As described in Section 2.4, a sender MAY also send a unicast query.
As described in Section 2.4, a sender may also send a unicast query.
Sections 2 and 3 describe the circumstances in which LLMNR queries
may be sent.
The sender MUST anticipate receiving no replies to some LLMNR The sender MUST anticipate receiving no replies to some LLMNR
queries, in the event that no responders are available within the queries, in the event that no responders are available within the
link-scope or in the event no positive non-null responses exist for link-scope. If no response is received, a resolver treats it as a
the transmitted query. If no positive response is received, a response that the name does not exist (RCODE=3 is returned). A
resolver treats it as a response that no records of the specified sender can handle duplicate responses by discarding responses with a
type and class exist for the specified name (it is treated the same source IP address and ID field that duplicate a response already
as a response with RCODE=0 and an empty answer section). received.
When multiple valid LLMNR responses are received with the 'C' bit
set, they SHOULD be concatenated and treated in the same manner that
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 clear; instead, only the responses with
the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are
received along with error response(s), then the error responses are
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
skipping to change at page 10, line 50 skipping to change at page 11, line 35
[e] Responders MUST NOT respond using data from the LLMNR or DNS [e] Responders MUST NOT respond using data from the LLMNR or DNS
resolver cache. resolver cache.
[f] If a DNS server is running on a host that supports LLMNR, the DNS [f] If a DNS server is running on a host that supports LLMNR, the DNS
server MUST respond to LLMNR queries only for the RRSets relating server MUST respond to LLMNR queries only for the RRSets relating
to the host on which the server is running, but MUST NOT respond to the host on which the server is running, but MUST NOT respond
for other records for which the server is authoritative. DNS for other records for which the server is authoritative. DNS
servers also MUST NOT send LLMNR queries in order to resolve DNS servers also MUST NOT send LLMNR queries in order to resolve DNS
queries. queries.
[g] If a responder is authoritative for a name, it SHOULD respond with [g] If a responder is authoritative for a name, it MUST respond with
RCODE=0 and an empty answer section, if the type of query does not RCODE=0 and an empty answer section, if the type of query does not
match a RR that the responder has. match a RR that the responder has.
As an example, a host configured to respond to LLMNR queries for the As an example, a host configured to respond to LLMNR queries for the
name "foo.example.com." is authoritative for the name name "foo.example.com." is authoritative for the name
"foo.example.com.". On receiving an LLMNR query for an A RR with the "foo.example.com.". On receiving an LLMNR query for an A RR with the
name "foo.example.com." the host authoritatively responds with A name "foo.example.com." the host authoritatively responds with A
RR(s) that contain IP address(es) in the RDATA of the resource RR(s) that contain IP address(es) in the RDATA of the resource
record. If the responder has a AAAA RR, but no A RR, and an A RR record. If the responder has a AAAA RR, but no A RR, and an A RR
query is received, the responder would respond with RCODE=0 and an query is received, the responder would respond with RCODE=0 and an
skipping to change at page 13, line 46 skipping to change at page 14, line 30
then the responder SHOULD include a link-scope address first then the responder SHOULD include a link-scope address first
in the response, if available. in the response, if available.
[e] If the source address of the query is a routable address, [e] If the source address of the query is a routable address,
then the responder MUST include a routable address first then the responder MUST include a routable address first
in the response, if available. 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. Rather than using a static when to retransmit an LLMNR query. An LLMNR sender SHOULD either
timeout, an LLMNR sender SHOULD dynamically compute the value of estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
LLMNR_TIMEOUT for each transmission, on a per-interface basis. high initial timeout. Suggested constants are described in Section
7.
For example, the algorithms described in RFC 2988 [RFC2988] compute
an RTO (including exponential backoff), which is used as the value of
LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO
(discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO
(discussed in Section 2 of [RFC2988], paragraph 2.4), and the
maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).
Recommended values for constants (including LLMNR_TIMEOUT if it is
set statically) are given in Section 7. In order to take slow
responders into account, an LLMNR sender SHOULD include responses
received after LLMNR_TIMEOUT in the computations.
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,
Retransmission of UDP queries SHOULD NOT be attempted more than 3 while increasing the value of LLMNR_TIMEOUT exponentially. An LLMNR
times. Where LLMNR queries are sent using TCP, retransmission is query SHOULD NOT be sent more than three times.
handled by the transport layer. Queries with the 'C' bit set MUST be
sent over multicast UDP and MUST NOT be retransmitted. Responses to Where LLMNR queries are sent using TCP, retransmission is handled by
queries with the 'C' bit set are not taken into account within the transport layer. Queries with the 'C' bit set MUST be sent using
retransmission timeout computations. multicast UDP and MUST NOT be retransmitted.
An LLMNR sender cannot know in advance if a query sent using An LLMNR sender cannot know in advance if a query sent using
multicast will receive no response, one response, or more than one multicast will receive no response, one response, or more than one
response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
has been received, or if it is necessary to collect all potential has been received, or if it is necessary to collect all potential
responses, such as if a uniqueness verification query is being made. responses, such as if a uniqueness verification query is being made.
Otherwise an LLMNR sender SHOULD consider a multicast query answered Otherwise an LLMNR sender SHOULD consider a multicast query answered
after the first response is received, if that response has the 'C' after the first response is received, if that response has the 'C'
bit clear. bit clear.
skipping to change at page 15, line 27 skipping to change at page 15, line 48
Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
concept of delegation. In LLMNR, the NS resource record type may be concept of delegation. In LLMNR, the NS resource record type may be
stored and queried for like any other type, but it has no special stored and queried for like any other type, but it has no special
delegation semantics as it does in the DNS. Responders MAY have NS delegation semantics as it does in the DNS. Responders MAY have NS
records associated with the names for which they are authoritative, records associated with the names for which they are authoritative,
but they SHOULD NOT include these NS records in the authority but they SHOULD NOT include these NS records in the authority
sections of responses. sections of responses.
Responders SHOULD insert an SOA record into the authority section of Responders SHOULD insert an SOA record into the authority section of
a negative response, to facilitate negative caching as specified in a negative response, to facilitate negative caching as specified in
[RFC2308]. The owner name of this SOA record MUST be equal to the [RFC2308]. The TTL of this record is set from the minimum of the
query name. MINIMUM field of the SOA record and the TTL of the SOA itself, and
indicates how long a resolver may cache the negative answer. The
owner name of the SOA record (MNAME) MUST be set to the query name.
The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
by senders. Negative responses without SOA records SHOULD NOT be
cached.
In LLMNR, the additional section is primarily intended for use by In LLMNR, the additional section is primarily intended for use by
EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set, EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set,
senders MAY only include pseudo RR-types in the additional section of senders MAY only include pseudo RR-types in the additional section of
a query; unless the 'C' bit is set, responders MUST ignore the a query; unless the 'C' bit is set, responders MUST ignore the
additional section of queries containing other RR types. additional section of queries containing other RR types.
In queries where the 'C' bit is set, the sender SHOULD include the In queries where the 'C' bit is set, the sender SHOULD include the
conflicting RRs in the additional section. Since conflict conflicting RRs in the additional section. Since conflict
notifications are advisory, responders SHOULD log information from notifications are advisory, responders SHOULD log information from
skipping to change at page 19, line 9 skipping to change at page 19, line 38
To verify uniqueness, a responder MUST send an LLMNR query with the To verify uniqueness, a responder MUST send an LLMNR query with the
'C' bit clear, over all protocols on which it responds to LLMNR 'C' bit clear, over all protocols on which it responds to LLMNR
queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify
uniqueness of a name by sending a query for the name with type='ANY'. uniqueness of a name by sending a query for the name with type='ANY'.
If no response is received, the sender retransmits the query, as If no response is received, the sender retransmits the query, as
specified in Section 2.7. If a response is received, the sender MUST specified in Section 2.7. If a response is received, the sender MUST
check if the source address matches the address of any of its check if the source address matches the address of any of its
interfaces; if so, then the response is not considered a conflict, interfaces; if so, then the response is not considered a conflict,
since it originates from the sender. since it originates from the sender. To avoid triggering conflict
detection, a responder that detects that it is connected to the same
link on multiple interfaces SHOULD set the 'C' bit in responses.
If a response is received with the 'T' bit clear, the responder MUST If a response is received with the 'T' bit clear, the responder MUST
NOT use the name in response to LLMNR queries received over any NOT use the name in response to LLMNR queries received over any
protocol (IPv4 or IPv6). If a response is received with the 'T' bit protocol (IPv4 or IPv6). If a response is received with the 'T' bit
set, the responder MUST check if the source IP address in the set, the responder MUST check if the source IP address in the
response, interpreted as an unsigned integer, is less than the source response, interpreted as an unsigned integer, is less than the source
IP address in the query. If so, the responder MUST NOT use the name IP address in the query. If so, the responder MUST NOT use the name
in response to LLMNR queries received over any protocol (IPv4 or in response to LLMNR queries received over any protocol (IPv4 or
IPv6). For the purpose of uniqueness verification, the contents of IPv6). For the purpose of uniqueness verification, the contents of
the answer section in a response is irrelevant. the answer section in a response is irrelevant.
skipping to change at page 19, line 49 skipping to change at page 20, line 31
SHOULD send another query for the same name, type and class, this SHOULD send another query for the same name, type and class, this
time with the 'C' bit set, with the potentially conflicting resource time with the 'C' bit set, with the potentially conflicting resource
records included in the additional section. records included in the additional section.
Queries with the 'C' bit set are considered advisory and responders Queries with the 'C' bit set are considered advisory and responders
MUST verify the existence of a conflict before acting on it. A MUST verify the existence of a conflict before acting on it. A
responder receiving a query with the 'C' bit set MUST NOT respond. responder receiving a query with the 'C' bit set MUST NOT respond.
If the query is for a UNIQUE name, then the responder MUST send its If the query is for a UNIQUE name, then the responder MUST send its
own query for the same name, type and class, with the 'C' bit clear. own query for the same name, type and class, with the 'C' bit clear.
If a response is received, then a conflict has been detected. If a response is received, the sender MUST check if the source
address matches the address of any of its interfaces; if so, then the
response is not considered a conflict, since it originates from the
sender. To avoid triggering conflict detection, a responder that
detects that it is connected to the same link on multiple interfaces
SHOULD set the 'C' bit in responses.
An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
log them. Upon detecting a conflict, an LLMNR responder MUST log them. Upon detecting a conflict, an LLMNR responder MUST
immediately stop using the conflicting name in response to LLMNR immediately stop using the conflicting name in response to LLMNR
queries received over any supported protocol, if the source IP queries received over any supported protocol, if the source IP
address in the response, interpreted as an unsigned integer, is less address in the response, interpreted as an unsigned integer, is less
than the source IP address in the uniqueness verification query. than the source IP address in the uniqueness verification query.
After stopping the use of a name, the responder MAY elect to After stopping the use of a name, the responder MAY elect to
configure a new name. However, since name reconfiguration may be configure a new name. However, since name reconfiguration may be
skipping to change at page 23, line 18 skipping to change at page 24, line 5
response to a query (such as an A or AAAA query for a popular response to a query (such as an A or AAAA query for a popular
Internet host), and by using a TTL or Hop Limit field larger than one Internet host), and by using a TTL or Hop Limit field larger than one
(1), for the forged response to reach the LLMNR sender. Since the (1), for the forged response to reach the LLMNR sender. Since the
forged response will only be accepted if it contains a matching ID forged response will only be accepted if it contains a matching ID
field, choosing a pseudo-random ID field within queries provides some field, choosing a pseudo-random ID field within queries provides some
protection against off-link responders. protection against off-link responders.
Since LLMNR queries can be sent when DNS server(s) do not respond, an Since LLMNR queries can be sent when DNS server(s) do not respond, an
attacker can execute a denial of service attack on the DNS server(s) attacker can execute a denial of service attack on the DNS server(s)
and then poison the LLMNR cache by responding to an LLMNR query with and then poison the LLMNR cache by responding to an LLMNR query with
incorrect information. To some extent, these vulnerabilities exist incorrect information. As noted in "Threat Analysis of the Domain
today, since DNS response spoofing tools are available that can allow Name System (DNS)" [RFC3833] these threats also exist with DNS, since
an attacker to respond to a query more quickly than a distant DNS DNS response spoofing tools are available that can allow an attacker
server. However, switched networks or link layer security may make to respond to a query more quickly than a distant DNS server.
it difficult for an on-link attacker to snoop unicast DNS queries, However, while switched networks or link layer security may make it
whereas multicast LLMNR queries are propagated to all hosts on the difficult for an on-link attacker to snoop unicast DNS queries,
link, making it easier for an on-link attacker to spoof LLMNR multicast LLMNR queries are propagated to all hosts on the link,
responses. making it possible for an on-link attacker to spoof LLMNR responses
without having to guess the value of the ID field in the query.
Since LLMNR queries are sent and responded to on the local-link, an Since LLMNR queries are sent and responded to on the local-link, an
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 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 a response in a timely way is not difficult, since a legitimate
response will never be received. response will never be received.
Limiting the situations in which LLMNR queries are sent, as described Limiting the situations in which LLMNR queries are sent, as described
in Section 2, is the best protection against these attacks. If LLMNR in Section 2, is the best protection against these attacks. If LLMNR
skipping to change at page 24, line 5 skipping to change at page 24, line 41
5.3. Authentication 5.3. Authentication
LLMNR is a peer-to-peer name resolution protocol, and as a result, LLMNR is a peer-to-peer name resolution protocol, and as a result,
it is often deployed in situations where no trust model can be it is often deployed in situations where no trust model can be
assumed. This makes it difficult to apply existing DNS security assumed. This makes it difficult to apply existing DNS security
mechanisms to LLMNR. mechanisms to LLMNR.
LLMNR does not support "delegated trust" (CD or AD bits). As a LLMNR does not support "delegated trust" (CD or AD bits). As a
result, unless LLMNR senders are DNSSEC aware, it is not feasible to result, unless LLMNR senders are DNSSEC aware, it is not feasible to
use DNSSEC with LLMNR. use DNSSEC [RFC4033] with LLMNR.
If authentication is desired, and a pre-arranged security If authentication is desired, and a pre-arranged security
configuration is possible, then the following security mechanisms may configuration is possible, then the following security mechanisms may
be used: be used:
[a] LLMNR implementations MAY support TSIG and/or SIG(0) security [a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
mechanisms. "DNS Name Service based on Secure Multicast DNS for [RFC2931] security mechanisms. "DNS Name Service based on Secure
IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes the use of TSIG Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
to secure LLMNR responses, based on group keys. the use of TSIG to secure LLMNR responses, based on group keys.
[b] IPsec ESP with a null-transform MAY be used to authenticate unicast [b] IPsec ESP with a null-transform MAY be used to authenticate unicast
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. pre-shared key for trusted hosts.
Where these mechanisms cannot be supported, responses to LLMNR Where these mechanisms cannot be supported, responses to LLMNR
queries may be unauthenticated. queries may be unauthenticated.
skipping to change at page 25, line 11 skipping to change at page 25, line 44
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.
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) LLMNR_TIMEOUT 1 second (if set statically on all interfaces)
RTOinit 500 ms (initial value of LLMNR_TIMEOUT) 100 ms (IEEE 802 media, including IEEE 802.11)
RTOmax 5 seconds (maximum value of LLMNR_TIMEOUT)
RTOmin 100 ms (minimum value of LLMNR_TIMEOUT)
8. References 8. References
8.1. Normative References 8.1. Normative References
[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,
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.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997. Specification", RFC 2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
RFC 2308, March 1998. RFC 2308, March 1998.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
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 IANA [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999. August 1999.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
Timer", RFC 2988, November 2000. "Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s)", RFC 2931, September 2000.
8.2. Informative References 8.2. Informative References
[Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft
(work in progress), draft-cheshire-dnsext-multicastdns-05.txt,
June 2005.
[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
Caching", IEEE/ACM Transactions on Networking, Volume 10,
Number 5, pp. 589, October 2002.
[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
unicast addresses to communicate with recursive DNS servers",
Internet draft (work in progress), draft-ietf-ipv6-dns-
discovery-07.txt, October 2002.
[IEEE-802.11i] [IEEE-802.11i]
Institute of Electrical and Electronics Engineers, "Supplement Institute of Electrical and Electronics Engineers, "Supplement
to Standard for Telecommunications and Information Exchange to Standard for Telecommunications and Information Exchange
Between Systems - LAN/MAN Specific Requirements - Part 11: Between Systems - LAN/MAN Specific Requirements - Part 11:
Wireless LAN Medium Access Control (MAC) and Physical Layer Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications: Specification for Enhanced Security", (PHY) Specifications: Specification for Enhanced Security",
IEEE 802.11i, July 2004. IEEE 802.11i, July 2004.
[LLMNREnable]
Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
in progress), draft-guttman-mdns-enable-02.txt, April 2002.
[LLMNRSec] [LLMNRSec]
Jeong, J., Park, J. and H. Kim, "DNS Name Service based on Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
2004, Phoenix Park, Korea, February 9-11, 2004. 2004, Phoenix Park, Korea, February 9-11, 2004.
[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
Portable Operating System Interface (POSIX). Open Group
Technical Standard: Base Specifications, Issue 6, December
2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested [RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
Fixes", RFC 1536, October 1993. Fixes", RFC 1536, October 1993.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", [RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
RFC 2292, February 1998. RFC 2292, February 1998.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[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.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
System (DNS)", RFC 3833, August 2004.
[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of Link-Local IPv4 Addresses", RFC 3927, October 2004. of Link-Local IPv4 Addresses", RFC 3927, October 2004.
[Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
(work in progress), draft-cheshire-dnsext-multicastdns-05.txt, "DNS Security Introduction and Requirement", RFC 4033, March
June 2005. 2005.
[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
Caching", IEEE/ACM Transactions on Networking, Volume 10,
Number 5, pp. 589, October 2002.
[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
unicast addresses to communicate with recursive DNS servers",
Internet draft (work in progress), draft-ietf-ipv6-dns-
discovery-07.txt, October 2002.
[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
Portable Operating System Interface (POSIX). Open Group
Technical Standard: Base Specifications, Issue 6, December
2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
[LLMNREnable]
Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
in progress), draft-guttman-mdns-enable-02.txt, April 2002.
[NodeInfo]
Crawford, M., "IPv6 Node Information Queries", Internet draft
(work in progress), draft-ietf-ipn-gwg-icmp-name-
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 Manning and Bill Woodcock. Bill Manning's work was funded under
DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge
their contribution to the current specification. Constructive input their contribution to the current specification. Constructive input
has also been received from Mark Andrews, Rob Austein, Randy Bush, has also been received from Mark Andrews, Rob Austein, Randy Bush,
Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
 End of changes. 

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