draft-ietf-dnsext-mdns-43.txt   draft-ietf-dnsext-mdns-44.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-43.txt> Microsoft Corporation <draft-ietf-dnsext-mdns-44.txt> Microsoft Corporation
29 August 2005 30 September 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 2, line 11 skipping to change at page 2, line 11
from DNS, and with a distinct resolver cache. Since LLMNR only from DNS, and with a distinct resolver cache. Since LLMNR only
operates on the local link, it cannot be considered a substitute for operates on the local link, it cannot be considered a substitute for
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 ............................. 5
2.2 Sender Behavior ................................. 9 2.2 Sender Behavior ................................. 8
2.3 Responder Behavior .............................. 10 2.3 Responder Behavior .............................. 9
2.4 Unicast Queries and Responses ................... 12 2.4 Unicast Queries and Responses ................... 11
2.5 Off-link Detection .............................. 13 2.5 Off-link Detection .............................. 12
2.6 Responder Responsibilities ...................... 13 2.6 Responder Responsibilities ...................... 13
2.7 Retransmission and Jitter ....................... 14 2.7 Retransmission and Jitter ....................... 13
2.8 DNS TTL ......................................... 15 2.8 DNS TTL ......................................... 14
2.9 Use of the Authority and Additional Sections .... 15 2.9 Use of the Authority and Additional Sections .... 14
3. Usage model ........................................... 16 3. Usage model ........................................... 15
3.1 LLMNR Configuration ............................. 17 3.1 LLMNR Configuration ............................. 17
4. Conflict Resolution ................................... 18 4. Conflict Resolution ................................... 18
4.1 Uniqueness Verification ......................... 19 4.1 Uniqueness Verification ......................... 19
4.2 Conflict Detection and Defense .................. 20 4.2 Conflict Detection and Defense .................. 20
4.3 Considerations for Multiple Interfaces .......... 21 4.3 Considerations for Multiple Interfaces .......... 21
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 ............................... 23
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 ....................... 25
6. IANA considerations ................................... 25 6. IANA considerations ................................... 25
7. Constants ............................................. 25 7. Constants ............................................. 25
8. References ............................................ 25 8. References ............................................ 26
8.1 Normative References ............................ 25 8.1 Normative References ............................ 26
8.2 Informative References .......................... 26 8.2 Informative References .......................... 27
Acknowledgments .............................................. 27 Acknowledgments .............................................. 28
Authors' Addresses ........................................... 28 Authors' Addresses ........................................... 28
Intellectual Property Statement .............................. 28 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.
skipping to change at page 4, line 18 skipping to change at page 4, line 18
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
1.2. Terminology 1.2. Terminology
This document assumes familiarity with DNS terminology defined in This document assumes familiarity with DNS terminology defined in
[RFC1035]. Other terminology used in this document includes: [RFC1035]. Other terminology used in this document includes:
Positively Resolved
Responses with RCODE set to zero are referred to in this document
as "positively resolved".
Routable Address Routable Address
An address other than a Link-Local address. This includes globally An address other than a Link-Local address. This includes globally
routable addresses, as well as private addresses. routable addresses, as well as private addresses.
Reachable Reachable
An LLMNR responder considers one of its addresses reachable over a An LLMNR responder considers one of its addresses reachable over a
link if it will respond to an ARP or Neighbor Discovery query for link if it will respond to an ARP or Neighbor Discovery query for
that address received on that link. that address received on that link.
Responder Responder
skipping to change at page 4, line 48 skipping to change at page 4, line 44
UNIQUE UNIQUE
There are some scenarios when multiple responders may respond to There are some scenarios when multiple responders may respond to
the same query. There are other scenarios when only one responder the same query. There are other scenarios when only one responder
may respond to a query. Names for which only a single responder is may respond to a query. Names for which only a single responder is
anticipated are referred to as UNIQUE. Name uniqueness is anticipated are referred to as UNIQUE. Name uniqueness is
configured on the responder, and therefore uniqueness verification configured on the responder, and therefore uniqueness verification
is the responder's responsibility. is the responder's responsibility.
2. Name Resolution Using LLMNR 2. Name Resolution Using LLMNR
LLMNR is a peer-to-peer name resolution protocol that is not intended LLMNR queries are sent to and received on port 5355. The IPv4 link-
as a replacement for DNS. LLMNR queries are sent to and received on scope multicast address a given responder listens to, and to which a
port 5355. The IPv4 link-scope multicast address a given responder sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast
listens to, and to which a sender sends queries, is 224.0.0.252. The address a given responder listens to, and to which a sender sends all
IPv6 link-scope multicast address a given responder listens to, and queries, is FF02:0:0:0:0:0:1:3.
to which a sender sends all queries, is FF02:0:0:0:0:0:1:3.
Typically a host is configured as both an LLMNR sender and a Typically a host is configured as both an LLMNR sender and a
responder. A host MAY be configured as a sender, but not a responder. A host MAY be configured as a sender, but not a
responder. However, a host configured as a responder MUST act as a responder. However, a host configured as a responder MUST act as a
sender, if only to verify the uniqueness of names as described in sender, if only to verify the uniqueness of names as described in
Section 4. This document does not specify how names are chosen or Section 4. This document does not specify how names are chosen or
configured. This may occur via any mechanism, including DHCPv4 configured. This may occur via any mechanism, including DHCPv4
[RFC2131] or DHCPv6 [RFC3315]. [RFC2131] or DHCPv6 [RFC3315].
LLMNR usage MAY be configured manually or automatically on a per
interface basis. By default, LLMNR responders SHOULD be enabled on
all interfaces, at all times. Enabling LLMNR for use in situations
where a DNS server has been configured will result in a change in
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.
By default, LLMNR queries MAY be sent only when one of the following
conditions are met:
[1] No manual or automatic DNS configuration has been performed.
If DNS server address(es) have been configured, then LLMNR
SHOULD NOT be used as the primary name resolution mechanism,
although it MAY be used as a secondary name resolution
mechanism. A dual stack host SHOULD attempt to reach DNS
servers overall protocols on which DNS server address(es) are
configured, prior to sending LLMNR queries. For dual stack
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
have failed after exhausting the searchlist. This can occur
because DNS servers did not respond, or because they
responded to DNS queries with RCODE=3 (Authoritative Name
Error) or RCODE=0, and an empty answer section. Where a
single resolver call generates DNS queries for A and AAAA RRs,
an implementation MAY choose not to send LLMNR queries if any
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] An LLMNR sender sends an LLMNR query to the link-scope
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
multicast address(es), unless a unicast query is indicated, multicast address(es), unless a unicast query is indicated,
as specified in Section 2.4. as specified in Section 2.4.
[c] A responder responds to this query only if it is authoritative [b] 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 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. [c] Upon reception of the response, the sender processes it.
The sections that follow provide further details on sender and The sections that follow provide further details on sender and
responder behavior. 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
skipping to change at page 8, line 9 skipping to change at page 7, line 9
In an LLMNR response, if the name is considered UNIQUE, then the In an LLMNR response, if the name is considered UNIQUE, then the
'C' bit is clear, otherwise it is set. LLMNR senders do not 'C' bit is clear, otherwise it is set. LLMNR senders do not
retransmit queries with the 'C' bit set. Responders MUST NOT retransmit queries with the 'C' bit set. Responders MUST NOT
respond to LLMNR queries with the 'C' bit set, but may start the respond to LLMNR queries with the 'C' bit set, but may start the
uniqueness verification process, as described in Section 4.2. uniqueness verification process, as described in Section 4.2.
TC TrunCation - specifies that this message was truncated due to TC TrunCation - specifies that this message was truncated due to
length greater than that permitted on the transmission channel. length greater than that permitted on the transmission channel.
The TC bit MUST NOT be set in an LLMNR query and if set is ignored The TC bit MUST NOT be set in an LLMNR query and if set is ignored
by an LLMNR responder. If the TC bit is set in an LLMNR response, by an LLMNR responder. If the TC bit is set in an LLMNR response,
then the sender SHOULD discard the response and resend the LLMNR then the sender SHOULD resend the LLMNR query over TCP using the
query over TCP using the unicast address of the responder as the unicast address of the responder as the destination address. If
destination address. See [RFC2181] and Section 2.4 of this the sender receives a response to the TCP query, then it SHOULD
specification for further discussion of the TC bit. discard the UDP response with the TC bit set. See [RFC2181] and
Section 2.4 of this specification for further discussion of the TC
bit.
T Tentative. The 'T'entative bit is set in a response if the T Tentative. The 'T'entative bit is set in a response if the
responder is authoritative for the name, but has not yet verified responder is authoritative for the name, but has not yet verified
the uniqueness of the name. A responder MUST ignore the 'T' bit in the uniqueness of the name. A responder MUST ignore the 'T' bit in
a query, if set. A response with the 'T' bit set is silently a query, if set. A response with the 'T' bit set is silently
discarded by the sender, except if it is a uniqueness query, in discarded by the sender, except if it is a uniqueness query, in
which case a conflict has been detected and a responder MUST which case a conflict has been detected and a responder MUST
resolve the conflict as described in Section 4.1. resolve the conflict as described in Section 4.1.
Z Reserved for future use. Implementations of this specification Z Reserved for future use. Implementations of this specification
skipping to change at page 8, line 44 skipping to change at page 7, line 46
response to a multicast LLMNR query MUST have RCODE set to zero. A response to a multicast LLMNR query MUST have RCODE set to zero. A
sender MUST silently discard an LLMNR response with a non-zero sender MUST silently discard an LLMNR response with a non-zero
RCODE sent in response to a multicast query. RCODE sent in response to a multicast query.
If an LLMNR responder is authoritative for the name in a multicast If an LLMNR responder is authoritative for the name in a multicast
query, but an error is encountered, the responder SHOULD send an query, but an error is encountered, the responder SHOULD send an
LLMNR response with an RCODE of zero, no RRs in the answer section, LLMNR response with an RCODE of zero, no RRs in the answer section,
and the TC bit set. This will cause the query to be resent using and the TC bit set. This will cause the query to be resent using
TCP, and allow the inclusion of a non-zero RCODE in the response to TCP, and allow the inclusion of a non-zero RCODE in the response to
the TCP query. Responding with the TC bit set is preferable to not the TCP query. Responding with the TC bit set is preferable to not
sending a response, since it enables errors to be diagnosed. sending a response, since it enables errors to be diagnosed. This
Errors include those defined in [RFC2845], such as BADSIG(16), may be required, for example, when an LLMNR query includes a TSIG
BADKEY(17) and BADTIME(18). RR in the additional section, and the responder encounters a
problem that requires returning a non-zero RCODE. TSIG error
conditions defined in [RFC2845] include a TSIG RR in an
unacceptable position (RCODE=1) or a TSIG RR which does not
validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16 (BADSIG)).
Since LLMNR responders only respond to LLMNR queries for names for Since LLMNR responders only respond to LLMNR queries for names for
which they are authoritative, LLMNR responders MUST NOT respond which they are authoritative, LLMNR responders MUST NOT respond
with an RCODE of 3; instead, they should not respond at all. with an RCODE of 3; instead, they should not respond at all.
LLMNR implementations MUST support EDNS0 [RFC2671] and extended LLMNR implementations MUST support EDNS0 [RFC2671] and extended
RCODE values. RCODE values.
QDCOUNT QDCOUNT
An unsigned 16 bit integer specifying the number of entries in the An unsigned 16 bit integer specifying the number of entries in the
skipping to change at page 11, line 6 skipping to change at page 10, line 9
ip6.arpa IN PTR host1. (line split for formatting reasons) ip6.arpa IN PTR host1. (line split for formatting reasons)
IN PTR host1.example.com. IN PTR host1.example.com.
An LLMNR responder might be further manually configured with the name An LLMNR responder might be further manually configured with the name
of a local mail server with an MX RR included in the "host1." and of a local mail server with an MX RR included in the "host1." and
"host1.example.com." records. "host1.example.com." records.
In responding to queries: In responding to queries:
[a] Responders MUST listen on UDP port 5355 on the link-scope multicast [a] Responders MUST listen on UDP port 5355 on the link-scope multicast
address(es) defined in Section 2, and on UDP and TCP port 5355 on address(es) defined in Section 2, and on TCP port 5355 on the
the unicast address(es) that could be set as the source address(es) unicast address(es) that could be set as the source address(es)
when the responder responds to the LLMNR query. when the responder responds to the LLMNR query.
[b] Responders MUST direct responses to the port from which the query [b] Responders MUST direct responses to the port from which the query
was sent. When queries are received via TCP this is an inherent was sent. When queries are received via TCP this is an inherent
part of the transport protocol. For queries received by UDP the part of the transport protocol. For queries received by UDP the
responder MUST take note of the source port and use that as the responder MUST take note of the source port and use that as the
destination port in the response. Responses MUST always be sent destination port in the response. Responses MUST always be sent
from the port to which they were directed. from the port to which they were directed.
[c] Responders MUST respond to LLMNR queries for names and addresses [c] Responders MUST respond to LLMNR queries for names and addresses
skipping to change at page 12, line 46 skipping to change at page 11, line 50
within the "in-addr.arpa" or "ip6.arpa" zones. within the "in-addr.arpa" or "ip6.arpa" zones.
Unicast LLMNR queries MUST be done using TCP and the responses MUST Unicast LLMNR queries MUST be done using TCP and the responses MUST
be sent using the same TCP connection as the query. Senders MUST be sent using the same TCP connection as the query. Senders MUST
support sending TCP queries, and responders MUST support listening support sending TCP queries, and responders MUST support listening
for TCP queries. If the sender of a TCP query receives a response to for TCP queries. If the sender of a TCP query receives a response to
that query not using TCP, the response MUST be silently discarded. that query not using TCP, the response MUST be silently discarded.
Unicast UDP queries MUST be silently discarded. Unicast UDP queries MUST be silently discarded.
If TCP connection setup cannot be completed in order to send a A unicast PTR RR query for an off-link address will not elicit a
unicast TCP query, this is treated as a response that no records of response, but instead an ICMP TTL or Hop Limit exceeded message will
the specified type and class exist for the specified name (it is be received. An implementation receiving an ICMP message in response
treated the same as a response with RCODE=0 and an empty answer to a TCP connection setup attempt can return immediately, treating
section). this as a response that no such name exists (RCODE=3 is returned).
An implementation that cannot process ICMP messages MAY send
multicast UDP queries for PTR RRs. Since TCP implementations will
not retransmit prior to RTOmin, a considerable period will elapse
before TCP retransmits multiple times, resulting in a long timeout
for TCP PTR RR queries sent to an off-link destination.
2.5. "Off link" Detection 2.5. "Off link" Detection
A sender MUST select a source address for LLMNR queries that is A sender MUST select a source address for LLMNR queries that is
assigned on the interface on which the query is sent. The assigned on the interface on which the query is sent. The
destination address of an LLMNR query MUST be a link-scope multicast destination address of an LLMNR query MUST be a link-scope multicast
address or a unicast address. address or a unicast address.
A responder MUST select a source address for responses that is A responder MUST select a source address for responses that is
assigned on the interface on which the query was received. The assigned on the interface on which the query was received. The
skipping to change at page 13, line 33 skipping to change at page 12, line 41
field in the IPv6 header and the TTL field in the IPv4 header of the field in the IPv6 header and the TTL field in the IPv4 header of the
response to one (1). The responder SHOULD set the TTL or Hop Limit response to one (1). The responder SHOULD set the TTL or Hop Limit
settings on the TCP listen socket to one (1) so that SYN-ACK packets settings on the TCP listen socket to one (1) so that SYN-ACK packets
will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
prevents an incoming connection from off-link since the sender will prevents an incoming connection from off-link since the sender will
not receive a SYN-ACK from the responder. not receive a SYN-ACK from the responder.
For UDP queries and responses, the Hop Limit field in the IPv6 header For UDP queries and responses, the Hop Limit field in the IPv6 header
and the TTL field in the IPV4 header MAY be set to any value. and the TTL field in the IPV4 header MAY be set to any value.
However, it is RECOMMENDED that the value 255 be used for However, it is RECOMMENDED that the value 255 be used for
compatibility with Apple Bonjour [Bonjour]. compatibility with early implementations of [RFC3927].
Implementation note: Implementation note:
In the sockets API for IPv4 [POSIX], the IP_TTL and In the sockets API for IPv4 [POSIX], the IP_TTL and
IP_MULTICAST_TTL socket options are used to set the TTL of IP_MULTICAST_TTL socket options are used to set the TTL of
outgoing unicast and multicast packets. The IP_RECVTTL socket outgoing unicast and multicast packets. The IP_RECVTTL socket
option is available on some platforms to retrieve the IPv4 TTL of option is available on some platforms to retrieve the IPv4 TTL of
received packets with recvmsg(). [RFC2292] specifies similar received packets with recvmsg(). [RFC2292] specifies similar
options for setting and retrieving the IPv6 Hop Limit. options for setting and retrieving the IPv6 Hop Limit.
skipping to change at page 14, line 37 skipping to change at page 13, line 46
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. An LLMNR sender SHOULD either when to retransmit an LLMNR query. An LLMNR sender SHOULD either
estimate the LLMNR_TIMEOUT for each interface, or set a reasonably estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
high initial timeout. Suggested constants are described in Section high initial timeout. Suggested constants are described in Section
7. 7.
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.
while increasing the value of LLMNR_TIMEOUT exponentially. An LLMNR An LLMNR query SHOULD NOT be sent more than three times.
query SHOULD NOT be sent more than three times.
Where LLMNR queries are sent using TCP, retransmission is handled by Where LLMNR queries are sent using TCP, retransmission is handled by
the transport layer. Queries with the 'C' bit set MUST be sent using the transport layer. Queries with the 'C' bit set MUST be sent using
multicast UDP and MUST NOT be retransmitted. 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.
However, if the first response has the 'C' bit set, then the sender However, if the first response has the 'C' bit set, then the sender
SHOULD wait for LLMNR_TIMEOUT in order to collect all possible SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect
responses. When multiple valid answers are received, they may first all possible responses. When multiple valid answers are received,
be concatenated, and then treated in the same manner that multiple they may first be concatenated, and then treated in the same manner
RRs received from the same DNS server would. A unicast query sender that multiple RRs received from the same DNS server would. A unicast
considers the query answered after the first response is received, so query sender considers the query answered after the first response is
that it only waits for LLMNR_TIMEOUT if no response has been
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 and LLMNR_TIMEOUT estimation, 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
skipping to change at page 16, line 25 skipping to change at page 15, line 33
notifications are advisory, responders SHOULD log information from notifications are advisory, responders SHOULD log information from
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
as a replacement for DNS. By default, an LLMNR sender SHOULD send
LLMNR queries only for single-label names. In order to reduce
unnecessary DNS queries, stub resolvers supporting both DNS and LLMNR
SHOULD avoid sending DNS queries for single-label names. An LLMNR
sender SHOULD NOT be enabled to send a query for any name, except
where security mechanisms (described in Section 5.3) can be utilized.
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 is only used as a name resolution mechanism of last
resort, and queries SHOULD NOT be sent unless one of the following
conditions are met:
[1] No manual or automatic DNS configuration has been performed.
If DNS server address(es) have been configured, a
host SHOULD attempt to reach DNS servers over all protocols
on which DNS server address(es) are configured, prior to sending
LLMNR queries. For dual stack hosts configured with DNS server
address(es) for one protocol but not another, this implies 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
have failed after exhausting the searchlist. This can occur
because DNS servers did not respond, or because they
responded to DNS queries with RCODE=3 (Authoritative Name
Error) or RCODE=0, and an empty answer section. Where a
single resolver call generates DNS queries for A and AAAA RRs,
an implementation MAY choose not to send LLMNR queries if any
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.
Since LLMNR is a secondary name resolution mechanism, its usage is in Since LLMNR is a secondary name resolution mechanism, its usage is in
part determined by the behavior of DNS implementations. This part determined by the behavior of DNS implementations. In general,
document does not specify any changes to DNS resolver behavior, such
as searchlist processing or retransmission/failover policy. However,
robust DNS resolver implementations are more likely to avoid robust DNS resolver implementations are more likely to avoid
unnecessary LLMNR queries. unnecessary LLMNR queries.
As noted in [DNSPerf], even when DNS servers are configured, a As noted in [DNSPerf], even when DNS servers are configured, a
significant fraction of DNS queries do not receive a response, or significant fraction of DNS queries do not receive a response, or
result in negative responses due to missing inverse mappings or NS result in negative responses due to missing inverse mappings or NS
records that point to nonexistent or inappropriate hosts. This has records that point to nonexistent or inappropriate hosts. This has
the potential to result in a large number of unnecessary LLMNR the potential to result in a large number of unnecessary LLMNR
queries. queries.
[RFC1536] describes common DNS implementation errors and fixes. If [RFC1536] describes common DNS implementation errors and fixes. If
the proposed fixes are implemented, unnecessary LLMNR queries will be the proposed fixes are implemented, unnecessary LLMNR queries will be
reduced substantially, and so implementation of [RFC1536] is reduced substantially, and so implementation of [RFC1536] is
recommended. recommended.
For example, [RFC1536] Section 1 describes issues with retransmission For example, [RFC1536] Section 1 describes issues with retransmission
and recommends implementation of a retransmission policy based on and recommends implementation of a retransmission policy based on
round trip estimates, with exponential backoff. [RFC1536] Section 4 round trip estimates, with exponential back-off. [RFC1536] Section 4
describes issues with failover, and recommends that resolvers try describes issues with failover, and recommends that resolvers try
another server when they don't receive a response to a query. These another server when they don't receive a response to a query. These
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.
3.1. LLMNR Configuration 3.1. LLMNR Configuration
LLMNR usage MAY be configured manually or automatically on a per
interface basis. By default, LLMNR responders SHOULD be enabled on
all interfaces, at all times. Enabling LLMNR for use in situations
where a DNS server has been configured will result in a change in
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.
Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
possible for a dual stack host to be configured with the address of a possible for a dual stack host to be configured with the address of a
DNS server over IPv4, while remaining unconfigured with a DNS server DNS server over IPv4, while remaining unconfigured with a DNS server
suitable for use over IPv6. suitable for use over IPv6.
In these situations, a dual stack host will send AAAA queries to the In these situations, a dual stack host will send AAAA queries to the
configured DNS server over IPv4. However, an IPv6-only host configured DNS server over IPv4. However, an IPv6-only host
unconfigured with a DNS server suitable for use over IPv6 will be unconfigured with a DNS server suitable for use over IPv6 will be
unable to resolve names using DNS. Automatic IPv6 DNS configuration unable to resolve names using DNS. Automatic IPv6 DNS configuration
mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
skipping to change at page 24, line 22 skipping to change at page 24, line 22
making it possible for an on-link attacker to spoof LLMNR 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. 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 This vulnerability can be reduced by limiting use of LLMNR to
in Section 2, is the best protection against these attacks. If LLMNR resolution of single-label names as described in Section 3, or by
is given higher priority than DNS among the enabled name resolution implementation of authentication (see Section 5.3).
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 is only used as a name resolution mechanism of last resort.
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. Where a pre-arranged security configuration is possible,
mechanisms to LLMNR. the following security mechanisms may be used:
LLMNR does not support "delegated trust" (CD or AD bits). As a
result, unless LLMNR senders are DNSSEC aware, it is not feasible to
use DNSSEC [RFC4033] with LLMNR.
If authentication is desired, and a pre-arranged security
configuration is possible, then the following security mechanisms may
be used:
[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0) [a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
[RFC2931] security mechanisms. "DNS Name Service based on Secure [RFC2931] security mechanisms. "DNS Name Service based on Secure
Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
the use of TSIG to secure LLMNR responses, based on group keys. the use of TSIG to secure LLMNR, based on group keys. While group
keys can be used to demonstrate membership in a group, they do not
protect against forgery by an attacker that is a member of the
group.
[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. As with TSIG, this does not
protect against forgery by an attacker with access to the group
pre-shared key.
Where these mechanisms cannot be supported, responses to LLMNR [c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to
queries may be unauthenticated. support DNSSEC, LLMNR implementations MAY be configured with trust
anchors, or they MAY make use of keys obtained from DNS queries.
Since LLMNR does not support "delegated trust" (CD or AD bits),
LLMNR implementations cannot make use of DNSSEC unless they are
DNSSEC aware. Unlike approaches [a] or [b], DNSSEC permits a
responder to demonstrate ownership of a name, not just membership
within a trusted group. As a result, it enables 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.
6. IANA Considerations 6. IANA Considerations
This specification creates one new name space: the reserved bits in
the LLMNR header. These are allocated by IETF Consensus, in
accordance with BCP 26 [RFC2434].
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
and the reserved bits in the LLMNR header. The reserved bits in the
LLMNR header are allocated by IETF Consensus, in accordance with BCP
26 [RFC2434].
In order to to avoid creating any new administrative procedures,
administration of the LLMNR namespace will piggyback on the
administration of the DNS namespace.
The rights to use a fully qualified domain name (FQDN) within LLMNR
are obtained coincident with acquiring the rights to use that name
within DNS. Those wishing to use a FQDN within LLMNR should first
acquire the rights to use the corresponding FQDN within DNS. Using a
FQDN within LLMNR without ownership of the corresponding name in DNS
creates the possibility of conflict and therefore is discouraged.
LLMNR responders that have not obtained the rights to use of an FQDN
may self-allocate a name within the single-label name space, first
defined in [RFC1001]. Since single-label names are not unique, no
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)
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1001] Auerbach, K. and A. Aggarwal, "Protocol Standard for a NetBIOS
Service on a TCP/UDP Transport: Concepts and Methods", RFC
1001, March 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987. Specification", RFC 1035, November 1987.
[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)",
skipping to change at page 26, line 33 skipping to change at page 27, line 7
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC "Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000. 2845, May 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s)", RFC 2931, September 2000. (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 [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.
[IEEE-802.11i] [IEEE-802.11i]
 End of changes. 31 change blocks. 
136 lines changed or deleted 154 lines changed or added

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