draft-ietf-dnsext-mdns-39.txt   draft-ietf-dnsext-mdns-40.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-39.txt> Microsoft <draft-ietf-dnsext-mdns-40.txt> Microsoft
19 March 2005 25 May 2005
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 September 22, 2005. This Internet-Draft will expire on November 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2005. All rights reserved. Copyright (C) The Internet Society 2005.
Abstract Abstract
Today, with the rise of home networking, there are an increasing Today, with the rise of home networking, there are an increasing
number of ad-hoc networks operating without a Domain Name System number of ad-hoc networks operating without a Domain Name System
(DNS) server. The goal of Link-Local Multicast Name Resolution (DNS) server. The goal of Link-Local Multicast Name Resolution
(LLMNR) is to enable name resolution in scenarios in which (LLMNR) is to enable name resolution in scenarios in which
conventional DNS name resolution is not possible. LLMNR supports all conventional DNS name resolution is not possible. LLMNR supports all
current and future DNS formats, types and classes, while operating on current and future DNS formats, types and classes, while operating on
a separate port from DNS, and with a distinct resolver cache. Since a separate port from DNS, and with a distinct resolver cache. Since
LLMNR only operates on the local link, it cannot be considered a LLMNR only operates on the local link, it cannot be considered a
substitute for DNS. substitute for DNS.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements .................................... 3 1.1 Requirements .................................... 3
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 .............................. 9
2.4 Unicast queries ................................. 12 2.4 Unicast Queries ................................. 11
2.5 Off-link detection .............................. 12 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 .... 15
3. Usage model ........................................... 15 3. Usage model ........................................... 15
3.1 LLMNR configuration ............................. 16 3.1 LLMNR Configuration ............................. 16
4. Conflict Resolution ................................... 18 4. Conflict Resolution ................................... 17
4.1 Uniqueness Verification ......................... 18 4.1 Uniqueness Verification ......................... 18
4.2 Ongoing Conflict Detection ...................... 19 4.2 Conflict Detection and Defense .................. 19
4.3 Considerations for multiple interfaces .......... 20 4.3 Considerations for Multiple Interfaces .......... 20
4.4 API issues ...................................... 21 4.4 API issues ...................................... 21
5. Security considerations ............................... 22 5. Security Considerations ............................... 21
5.1 Scope restriction ............................... 22 5.1 Scope Restriction ............................... 22
5.2 Usage restriction ............................... 23 5.2 Usage Restriction ............................... 23
5.3 Cache and port separation ....................... 24 5.3 Cache and Port Separation ....................... 23
5.4 Authentication .................................. 24 5.4 Authentication .................................. 24
6. IANA considerations ................................... 24 6. IANA considerations ................................... 24
7. Constants ............................................. 25 7. Constants ............................................. 24
8. References ............................................ 25 8. References ............................................ 24
8.1 Normative References ............................ 25 8.1 Normative References ............................ 24
8.2 Informative References .......................... 26 8.2 Informative References .......................... 25
Acknowledgments .............................................. 27 Acknowledgments .............................................. 26
Authors' Addresses ........................................... 27 Authors' Addresses ........................................... 27
Intellectual Property Statement .............................. 28 Intellectual Property Statement .............................. 27
Disclaimer of Validity ....................................... 28 Disclaimer of Validity ....................................... 28
Copyright Statement .......................................... 28 Copyright Statement .......................................... 28
1. Introduction 1. Introduction
This document discusses Link Local Multicast Name Resolution (LLMNR), This document discusses Link Local Multicast Name Resolution (LLMNR),
which utilizes the DNS packet format and supports all current and which utilizes the DNS packet format and supports all current and
future DNS formats, types and classes. LLMNR operates on a separate future DNS formats, types and classes. LLMNR operates on a separate
port from the Domain Name System (DNS), with a distinct resolver port from the Domain Name System (DNS), with a distinct resolver
cache. cache.
skipping to change at page 4, line 23 skipping to change at page 4, line 23
Responses with RCODE set to zero are referred to in this document Responses with RCODE set to zero are referred to in this document
as "positively resolved". 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 sent over the link. that address received on that link.
Responder Responder
A host that listens to LLMNR queries, and responds to those for A host that listens to LLMNR queries, and responds to those for
which it is authoritative. which it is authoritative.
Sender Sender
A host that sends an LLMNR query. A host that sends an LLMNR query.
UNIQUE UNIQUE
There are some scenarios when multiple responders may respond to a There are some scenarios when multiple responders may respond to
query. There are other scenarios when only one responder may the same query. There are other scenarios when only one responder
respond to a query. A responder considers a name to be UNIQUE if may respond to a query. Resource records for which only a single
multiple responses are not expected in response to a query for a responder is anticipated are referred to as UNIQUE. Resource
name, regardless of the type and class. record uniqueness is configured on the responder, and therefore
uniqueness verification 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 is a peer-to-peer name resolution protocol that is not intended
as a replacement for DNS. LLMNR queries are sent to and received on as a replacement for DNS. LLMNR queries are sent to and received on
port 5355. IPv4 administratively scoped multicast usage is specified port 5355. IPv4 administratively scoped multicast usage is specified
in "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link- in "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-
scope multicast address a given responder listens to, and to which a scope multicast address a given responder listens to, and to which a
sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast
address a given responder listens to, and to which a sender sends all address a given responder listens to, and to which a sender sends all
queries, is FF02:0:0:0:0:0:1:3. 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 to verify the uniqueness of names as described in Section 4. sender to verify the uniqueness of names as described in Section 4.
This document does not specify how names are chosen or configured. This document does not specify how names are chosen or configured.
This may occur via any mechanism, including DHCPv4 [RFC2131] or This may occur via any mechanism, including DHCPv4 [RFC2131] or
DHCPv6 [RFC3315]. DHCPv6 [RFC3315].
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 over all protocols that the host supports, at all all interfaces, at all times. Enabling LLMNR for use in situations
times. Enabling LLMNR for use in situations where a DNS server has where a DNS server has been configured will result in a change in
been configured will result in a change in default behavior without a default behavior without a simultaneous update to configuration
simultaneous update to configuration information. Where this is information. Where this is considered undesirable, LLMNR SHOULD NOT
considered undesirable, LLMNR SHOULD NOT be enabled by default, so be enabled by default, so that hosts will neither listen on the link-
that hosts will neither listen on the link-scope multicast address, scope multicast address, nor will they send queries to that address.
nor will they send queries to that address.
An LLMNR sender may send a request for any name. However, by An LLMNR sender may send a request for any name. However, by
default, LLMNR requests SHOULD be sent only when one of the following default, LLMNR requests SHOULD be sent only when one of the following
conditions are met: conditions are met:
[1] No manual or automatic DNS configuration has been [1] No manual or automatic DNS configuration has been
performed. If DNS server address(es) have been performed. If DNS server address(es) have been
configured, then LLMNR SHOULD NOT be used as the configured, then LLMNR SHOULD NOT be used as the
primary name resolution mechanism, although it MAY primary name resolution mechanism, although it MAY
be used as a secondary name resolution mechanism. be used as a secondary name resolution mechanism.
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] DNS servers do not respond. [2] DNS servers do not respond. For a dual stack
host, the host SHOULD attempt to reach
DNS servers over all protocols on which
DNS server address(es) are configured, prior
to use of LLMNR.
[3] DNS servers respond to a DNS query with RCODE=3 [3] DNS servers respond to a DNS query with RCODE=3
(Authoritative Name Error) or RCODE=0, and an empty (Authoritative Name Error) or RCODE=0, and an empty
answer section. answer section.
A typical sequence of events for LLMNR usage is as follows: A typical sequence of events for LLMNR usage is as follows:
[a] DNS servers are not configured or do not respond to a [a] DNS servers are not configured or do not respond to a
DNS query, or respond with RCODE=3, or RCODE=0 and an DNS query, or respond with RCODE=3, or RCODE=0 and an
empty answer section. empty answer section.
skipping to change at page 6, line 10 skipping to change at page 6, line 18
[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 Further details of sender and responder behavior are provided in the
sections that follow. sections that follow.
2.1. LLMNR packet format 2.1. LLMNR Packet Format
LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4
for both queries and responses. LLMNR implementations SHOULD send 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 8192 octets. MTU or 8192 octets.
2.1.1. LLMNR header format 2.1.1. LLMNR Header Format
LLMNR queries and responses utilize the DNS header format defined in LLMNR queries and responses utilize the DNS header format defined in
[RFC1035] with exceptions noted below: [RFC1035] with exceptions noted below:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID | | ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE | |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE |
skipping to change at page 7, line 16 skipping to change at page 7, line 27
A four bit field that specifies the kind of query in this message. A four bit field that specifies the kind of query in this message.
This value is set by the originator of a query and copied into the This value is set by the originator of a query and copied into the
response. This specification defines the behavior of standard response. This specification defines the behavior of standard
queries and responses (opcode value of zero). Future queries and responses (opcode value of zero). Future
specifications may define the use of other opcodes with LLMNR. specifications may define the use of other opcodes with LLMNR.
LLMNR senders and responders MUST support standard queries (opcode LLMNR senders and responders MUST support standard queries (opcode
value of zero). LLMNR queries with unsupported OPCODE values MUST value of zero). LLMNR queries with unsupported OPCODE values MUST
be silently discarded by responders. be silently discarded by responders.
C Conflict. When set within a request, the 'C'onflict bit indicates C Conflict. When set within a request, the 'C'onflict bit indicates
that a sender has received multiple LLMNR responses to this query that a sender has received multiple LLMNR responses to this query.
with the 'T' bit clear. In an LLMNR response, the 'C' bit is clear In an LLMNR response, if one or more resource records in the answer
if the responder considers the name in the query to be UNIQUE; section is UNIQUE, then the 'C' bit is clear, otherwise it is set.
otherwise the 'C' bit is set. LLMNR senders do not retransmit LLMNR senders do not retransmit queries with the 'C' bit set.
queries with the 'C' bit set. When receiving an LLMNR query with Responders MUST NOT respond to LLMNR queries with the 'C' bit set,
the 'C' bit set, an LLMNR responder MUST NOT respond, but will but may start the uniqueness verification process, as described in
attempt to verify the conflict, as described in Section 4.2. 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 discard the response and resend the LLMNR
query over TCP using the unicast address of the responder as the query over TCP using the unicast address of the responder as the
destination address. See [RFC2181] and Section 2.4 of this destination address. See [RFC2181] and Section 2.4 of this
specification for further discussion of the TC bit. 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 sender receiving a response with the the uniqueness of one or more of the resource record(s) in the
'T' bit set MUST silently discard the response unless it is answer section. A responder MUST ignore the 'T' bit in a query, if
received in response to a uniqueness query. A responder MUST set. When a response with the 'T' bit set is received in response
ignore the 'T' bit in a query, if set. When a response with the to a uniqueness query, a conflict has been detected and a responder
'T' bit set is received in response to a uniqueness query, a MUST resolve the conflict as described in Section 4.1.
conflict has been detected and a responder MUST resolve the
conflict. Use of the 'T' bit is described in more detail in
Sections 4.1 and 4.2.
Z Reserved for future use. Implementations of this specification Z Reserved for future use. Implementations of this specification
MUST set these bits to zero in both queries and responses. If MUST set these bits to zero in both queries and responses. If
these bits are set in a LLMNR query or response, implementations of these bits are set in a LLMNR query or response, implementations of
this specification MUST ignore them. Since reserved bits could this specification MUST ignore them. Since reserved bits could
conceivably be used for different purposes than in DNS, conceivably be used for different purposes than in DNS,
implementors are advised not to enable processing of these bits in implementors are advised not to enable processing of these bits in
an LLMNR implementation starting from a DNS code base. an LLMNR implementation starting from a DNS code base.
RCODE RCODE
skipping to change at page 9, line 5 skipping to change at page 9, line 10
NSCOUNT NSCOUNT
An unsigned 16 bit integer specifying the number of name server An unsigned 16 bit integer specifying the number of name server
resource records in the authority records section. Authority resource records in the authority records section. Authority
record section processing is described in Section 2.9. record section processing is described in Section 2.9.
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, 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 Sections 2 and 3 describe the circumstances in which LLMNR queries
may be sent. 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 or in the event no positive non-null responses exist for
the transmitted query. If no positive response is received to a the transmitted query. If no positive response is received, a
query other than a uniqueness query, a resolver treats it as a resolver treats it as a response that no records of the specified
response that no records of the specified type and class exist for type and class exist for the specified name (it is treated the same
the specified name (it is treated the same as a response with RCODE=0 as a response with RCODE=0 and an empty answer section).
and an empty answer section).
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.
The sender MUST anticipate receiving multiple replies to the same The sender MUST anticipate receiving multiple replies to the same
LLMNR query, in the event that several LLMNR responders receive the LLMNR query, in the event that several LLMNR enabled computers
query and respond with valid answers. When multiple valid answers receive the query and respond with valid answers. When multiple
with the 'T' bit clear are received in response to a query they are valid answers are received, they may first be concatenated, and then
treated as follows: treated in the same manner that multiple RRs received from the same
DNS server would.
[1] If the responses have the 'C' bit set, the responses are
concatenated and then treated in the same manner that multiple RRs
received from the same DNS server would.
[2] If one or more of the responses have the 'C' bit clear, a conflict
has been detected. The responses are concatenated, but are not
cached. A query for the same name, type and class is sent, with
the 'C' bit set. Conflict detection and resolution is described in
more detail in Section 4.2.
2.3. Responder behavior 2.3. Responder Behavior
An LLMNR response MUST be sent to the sender via unicast. An LLMNR response MUST be sent to the sender via unicast.
Upon configuring an IP address, responders typically will synthesize Upon configuring an IP address, responders typically will synthesize
corresponding A, AAAA and PTR RRs so as to be able to respond to corresponding A, AAAA and PTR RRs so as to be able to respond to
LLMNR queries for these RRs. An SOA RR is synthesized only when a LLMNR queries for these RRs. An SOA RR is synthesized only when a
responder has another RR as well; the SOA RR MUST NOT be the only RR responder has another RR as well; the SOA RR MUST NOT be the only RR
that a responder has. However, in general whether RRs are manually that a responder has. However, in general whether RRs are manually
or automatically created is an implementation decision. or automatically created is an implementation decision.
skipping to change at page 11, line 42 skipping to change at page 11, line 35
name "child.foo.example.com." unless the host is configured with name "child.foo.example.com." unless the host is configured with
multiple names, including "foo.example.com." and multiple names, including "foo.example.com." and
"child.foo.example.com.". As a result, "foo.example.com." cannot "child.foo.example.com.". As a result, "foo.example.com." cannot
reply to an LLMNR query for "child.foo.example.com." with RCODE=3 reply to an LLMNR query for "child.foo.example.com." with RCODE=3
(authoritative name error). The purpose of limiting the name (authoritative name error). The purpose of limiting the name
authority scope of a responder is to prevent complications that could authority scope of a responder is to prevent complications that could
be caused by coexistence of two or more hosts with the names be caused by coexistence of two or more hosts with the names
representing child and parent (or grandparent) nodes in the DNS tree, representing child and parent (or grandparent) nodes in the DNS tree,
for example, "foo.example.com." and "child.foo.example.com.". for example, "foo.example.com." and "child.foo.example.com.".
In this example (unless this limitation is introduced) an LLMNR query Without the restriction on authority an LLMNR query for an A resource
for an A resource record for the name "child.foo.example.com." would record for the name "child.foo.example.com." would result in two
result in two authoritative responses: RCODE=3 (authoritative name authoritative responses: RCODE=3 (authoritative name error) received
error) received from "foo.example.com.", and a requested A record - from "foo.example.com.", and a requested A record - from
from "child.foo.example.com.". To prevent this ambiguity, LLMNR "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled
enabled hosts could perform a dynamic update of the parent (or hosts could perform a dynamic update of the parent (or grandparent)
grandparent) zone with a delegation to a child zone. In this example zone with a delegation to a child zone; for example a host
a host "child.foo.example.com." would send a dynamic update for the "child.foo.example.com." could send a dynamic update for the NS and
NS and glue A record to "foo.example.com.", but this approach glue A record to "foo.example.com.". However, this approach
significantly complicates implementation of LLMNR and would not be significantly complicates implementation of LLMNR and would not be
acceptable for lightweight hosts. acceptable for lightweight hosts.
2.4. Unicast queries and responses 2.4. Unicast Queries and Responses
Unicast queries SHOULD be sent when: Unicast queries SHOULD be sent when:
[a] A sender repeats a query after it received a response [a] A sender repeats a query after it received a response
with the TC bit set to the previous LLMNR multicast query, or with the TC bit set to the previous LLMNR multicast query, or
[b] The sender queries for a PTR RR of a fully formed IP address [b] The sender queries for a PTR RR of a fully formed IP address
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.
skipping to change at page 12, line 29 skipping to change at page 12, line 21
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 If TCP connection setup cannot be completed in order to send a
unicast TCP query, this is treated as a response that no records of unicast TCP query, this is treated as a response that no records of
the specified type and class exist for the specified name (it is the specified type and class exist for the specified name (it is
treated the same as a response with RCODE=0 and an empty answer treated the same as a response with RCODE=0 and an empty answer
section). section).
2.5. "Off link" detection 2.5. "Off link" Detection
For IPv4, an "on link" address is defined as a link-local address For IPv4, an "on link" address is defined as a link-local address
[IPv4Link] or an address whose prefix belongs to a subnet on the [IPv4Link] or an address whose prefix belongs to a subnet on the
local link. For IPv6 [RFC2460] an "on link" address is either a local link. For IPv6 [RFC2460] an "on link" address is either a
link-local address, defined in [RFC2373], or one belonging to a link-local address, defined in [RFC2373], or one belonging to a
prefix that a Router Advertisement indicates is on-link [RFC2461]. prefix that a Router Advertisement indicates is on-link [RFC2461].
A sender MUST select a source address for LLMNR queries that is "on A sender MUST select a source address for LLMNR queries that is "on
link". The destination address of an LLMNR query MUST be a link- link". The destination address of an LLMNR query MUST be a link-
scope multicast address or an "on link" unicast address. scope multicast address or an "on link" unicast address.
skipping to change at page 13, line 13 skipping to change at page 13, line 6
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 Rendezvous. compatibility with Apple Bonjour [Bonjour].
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.
2.6. Responder responsibilities 2.6. Responder Responsibilities
It is the responsibility of the responder to ensure that RRs returned It is the responsibility of the responder to ensure that RRs returned
in LLMNR responses MUST only include values that are valid on the in LLMNR responses MUST only include values that are valid on the
local interface, such as IPv4 or IPv6 addresses valid on the local local interface, such as IPv4 or IPv6 addresses valid on the local
link or names defended using the mechanism described in Section 4. link or names defended using the mechanism described in Section 4.
In particular: In particular:
[a] If a link-scope IPv6 address is returned in a AAAA RR, [a] If a link-scope IPv6 address is returned in a AAAA RR,
that address MUST be valid on the local link over which that address MUST be valid on the local link over which
LLMNR is used. LLMNR is used.
[b] If an IPv4 address is returned, it MUST be reachable [b] If an IPv4 address is returned, it MUST be reachable
through the link over which LLMNR is used. through the link over which LLMNR is used.
[c] If a name is returned (for example in a CNAME, MX [c] If a name is returned (for example in a CNAME, MX
or SRV RR), the name MUST be resolvable on the local or SRV RR), the name MUST be resolvable on the local
link over which LLMNR is used. link over which LLMNR is used.
[d] When LLMNR is implemented on a dual stack host, LLMNR SHOULD
be supported on both IPv4 and IPv6. An implementation only
supporting LLMNR over IPv6 SHOULD NOT return IPv4 addresses;
an implementation only supporting LLMNR over IPv4 SHOULD NOT
return IPv6 addresses.
Where multiple addresses represent valid responses to a query, the Where multiple addresses represent valid responses to a query, the
order in which the addresses are returned is as follows: order in which the addresses are returned is as follows:
[e] If the source address of the query is a link-scope address, [d] If the source address of the query is a link-scope address,
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.
[f] 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 and how long to collect responses when to retransmit an LLMNR query and how long to collect responses
to an LLMNR query. to an LLMNR query.
If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
then a sender SHOULD repeat the transmission of the query in order to then a sender SHOULD repeat the transmission of the query in order to
assure that it was received by a host capable of responding to it. assure that it was received by a host capable of responding to it.
Retransmission of UDP queries SHOULD NOT be attempted more than 3 Retransmission of UDP queries SHOULD NOT be attempted more than 3
times. Where LLMNR queries are sent using TCP, retransmission is times. Where LLMNR queries are sent using TCP, retransmission is
skipping to change at page 15, line 15 skipping to change at page 15, line 5
2.8. DNS TTL 2.8. DNS TTL
The responder should insert a pre-configured TTL value in the records The responder should insert a pre-configured TTL value in the records
returned in an LLMNR response. A default value of 30 seconds is returned in an LLMNR response. A default value of 30 seconds is
RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
networks), the TTL value may need to be reduced. networks), the TTL value may need to be reduced.
Due to the TTL minimalization necessary when caching an RRset, all Due to the TTL minimalization necessary when caching an RRset, all
TTLs in an RRset MUST be set to the same value. TTLs in an RRset MUST be set to the same value.
2.9. Use of the authority and additional sections 2.9. Use of the Authority and Additional Sections
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
skipping to change at page 15, line 46 skipping to change at page 15, line 36
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
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
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. This
document does not specify any changes to DNS resolver behavior, such document does not specify any changes to DNS resolver behavior, such
as searchlist processing or retransmission/failover policy. However, 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
skipping to change at page 16, line 33 skipping to change at page 16, line 23
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
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
skipping to change at page 18, line 10 skipping to change at page 17, line 48
continuing to use LLMNR even once the outage is repaired. Since continuing to use LLMNR even once the outage is repaired. Since
LLMNR only enables linklocal name resolution, this represents a LLMNR only enables linklocal name resolution, this represents a
degradation in capabilities. As a result, hosts without a configured degradation in capabilities. As a result, hosts without a configured
DNS server may wish to periodically attempt to obtain DNS DNS server may wish to periodically attempt to obtain DNS
configuration if permitted by the configuration mechanism in use. In configuration if permitted by the configuration mechanism in use. In
the absence of other guidance, a default retry interval of one (1) the absence of other guidance, a default retry interval of one (1)
minute is RECOMMENDED. minute is RECOMMENDED.
4. Conflict Resolution 4. Conflict Resolution
A responder considers a name to be UNIQUE if multiple responses are The uniqueness of a resource record MAY depend on the nature of the
not expected in response to a query for that name, regardless of the name in the query and type of the query. For example, multiple hosts
type and class. By default, a responder SHOULD be configured to may respond to a query for an A or AAAA type record for a cluster
behave as though its names are UNIQUE on each interface on which name (assigned to multiple hosts in the cluster). By default, a
LLMNR is enabled. responder SHOULD be configured to behave as though all RRs are UNIQUE
on each interface on which LLMNR is enabled.
When responding to a query for a UNIQUE name, the 'C' bit is clear in
the response. Where the name in the query is not UNIQUE, an LLMNR
responder sets the 'C' bit in the response. For example, where
multiple responders may respond to a query for an A or AAAA type
record for a cluster name (assigned to multiple hosts in the
cluster), the 'C' bit is set in the response, regardless of the type
and class of the query.
To detect duplicate use of a name, an administrator can use a name To detect duplicate use of a name, an administrator can use a name
resolution utility which employs LLMNR and lists both responses and resolution utility which employs LLMNR and lists both responses and
responders. This would allow an administrator to diagnose behavior responders. This would allow an administrator to diagnose behavior
and potentially to intervene and reconfigure LLMNR responders who and potentially to intervene and reconfigure LLMNR responders who
should not be configured to respond to the same name. should not be configured to respond to the same name.
4.1. Uniqueness Verification 4.1. Uniqueness Verification
Before responding with the 'T' bit clear to a query for a UNIQUE Prior to including a UNIQUE resource record in a response with the
name, a responder MUST verify that there is no other host within the 'T' bit clear, for each UNIQUE resource record in a given interface's
scope of LLMNR query propagation using the same name on that configuration, the host MUST verify that there is no other host
interface. within the scope of LLMNR query propagation that can return a
resource record for the same name, type and class on that interface.
Prior to verifying uniqueness of a name, a responder MUST set the 'T' Once a responder has verified the uniqueness of a UNIQUE resource
bit in responses to queries for that name. Once a responder has record, if it receives an LLMNR query for that resource record, with
verified the uniqueness of a name, if it receives an LLMNR query for the 'C' bit clear, it MUST respond, with the 'T' bit clear. Prior to
that name with the 'C' bit clear, it MUST respond, with the 'T' and verifying uniqueness, a responder MUST set the 'T' bit in responses.
'C' bits clear.
Uniqueness verification is carried out when the host: Uniqueness verification is carried out when the host:
- starts up or is rebooted - starts up or is rebooted
- wakes from sleep (if the network interface was inactive - wakes from sleep (if the network interface was inactive
during sleep) during sleep)
- is configured to respond to LLMNR queries on an interface - is configured to respond to LLMNR queries on an interface
enabled for transmission and reception of IP traffic enabled for transmission and reception of IP traffic
- is configured to respond to LLMNR queries using additional - is configured to respond to LLMNR queries using additional
UNIQUE resource records UNIQUE resource records
- verifies the acquisition of a new IP address and configuration - verifies the acquisition of a new IP address and configuration
on an interface on an interface
To verify uniqueness of a name, a responder MUST send an LLMNR query To verify uniqueness, a responder MUST send an LLMNR query with the
for the name with the 'C' bit clear over all protocols on which it 'C' bit clear, over all protocols on which it responds to LLMNR
responds to LLMNR queries (IPv4 and/or IPv6). Any query type will queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify
do, including '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 with the 'T' bit specified in Section 2.7. If a response is received with the 'T' bit
clear, the responder MUST NOT use the name in response to LLMNR clear, the responder MUST NOT use the name in response to LLMNR
queries received over any protocol (IPv4 or IPv6). If a response is queries received over any protocol (IPv4 or IPv6). If a response is
received with the 'T' bit set, the responder MUST check if the source received with the 'T' bit set, the responder MUST check if the source
IP address in the response, interpreted as an unsigned integer, is IP address in the response, interpreted as an unsigned integer, is
less than the source IP address in the query. If so, the responder less than the source IP address in the query. If so, the responder
MUST NOT use the name in response to LLMNR queries received over any MUST NOT use the name in response to LLMNR queries received over any
protocol (IPv4 or IPv6). For the purpose of uniqueness verification, protocol (IPv4 or IPv6). For the purpose of uniqueness verification,
the contents of the answer section in a response is irrelevant. the contents of the answer section in a response is irrelevant.
Periodically carrying out uniqueness verification in an attempt to Periodically carrying out uniqueness verification in an attempt to
detect name conflicts is not necessary, wastes network bandwidth, and detect name conflicts is not necessary, wastes network bandwidth, and
may actually be detrimental. For example, if network links are may actually be detrimental. For example, if network links are
joined only briefly, and are separated again before any new joined only briefly, and are separated again before any new
communication is initiated, temporary conflicts are benign and no communication is initiated, temporary conflicts are benign and no
forced reconfiguration is required. LLMNR responders SHOULD NOT forced reconfiguration is required. LLMNR responders SHOULD NOT
periodically attempt uniqueness verification. periodically attempt uniqueness verification.
4.2. Ongoing Conflict Detection 4.2. Conflict Detection and Defense
Hosts on disjoint network links may configure the same name for use Hosts on disjoint network links may configure the same name for use
with LLMNR. If these separate network links are later joined or with LLMNR. If these separate network links are later joined or
bridged together, then there may be multiple hosts which are now on bridged together, then there may be multiple hosts which are now on
the same link, trying to use the same name. the same link, trying to use the same name.
In order to enable ongoing detection of name conflicts, when an LLMNR In order to enable ongoing detection of name conflicts, when an LLMNR
sender receives multiple LLMNR responses to a query, the sender sender receives multiple LLMNR responses to a query, it MUST check if
behaves as follows: the 'C' bit is clear in any of the responses. If so, the sender
SHOULD send another query for the same name, type and class, this
[1] Responses with the 'T' bit set MUST be silently discarded. time with the 'C' bit set, with the potentially conflicting resource
records included in the additional section.
[2] If multiple responses remain, the sender MUST check if the 'C' bit
is clear in any of the remaining responses. If so, a potential
conflict has been detected; the sender SHOULD send another query
for the same name, type and class, this time with the 'C' bit set.
The potentially conflicting resource records are included in the
additional section.
Responders receiving a query with the 'C' bit set behave as follows:
[3] 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.
[4] A responder receiving a query for a non-UNIQUE name with the 'C' If the query is for UNIQUE resource record(s), then the responder
bit set silently discards the query. A responder receiving a query MUST send its own query for the same name, type and class, with the
for a UNIQUE name with the 'C' bit set MUST send its own query for 'C' bit clear. If a response is received, then a conflict has been
the same name, type and class, with the 'C' bit clear. If a detected.
response is received with the 'T' bit clear, then a conflict has
been detected.
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 name in response to LLMNR queries received immediately stop using the conflicting name in response to LLMNR
over any supported protocol, if the source IP address in the queries received over any supported protocol, if the source IP
response, interpreted as an unsigned integer, is less than the source address in the response, interpreted as an unsigned integer, is less
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
disruptive, this is not required, and a responder may have been disruptive, this is not required, and a responder may have been
configured to respond to multiple names so that alternative names may configured to respond to multiple names so that alternative names may
already be available. already be available.
4.3. Considerations for Multiple Interfaces 4.3. Considerations for Multiple Interfaces
A multi-homed host may elect to configure LLMNR on only one of its A multi-homed host may elect to configure LLMNR on only one of its
skipping to change at page 21, line 46 skipping to change at page 21, line 21
Figure 3. Multiple paths to same host Figure 3. Multiple paths to same host
This illustrates that the proposed name conflict resolution mechanism This illustrates that the proposed name conflict resolution mechanism
does not support detection or resolution of conflicts between hosts does not support detection or resolution of conflicts between hosts
on different links. This problem can also occur with unicast DNS on different links. This problem can also occur with unicast DNS
when a multi-homed host is connected to two different networks with when a multi-homed host is connected to two different networks with
separated name spaces. It is not the intent of this document to separated name spaces. It is not the intent of this document to
address the issue of uniqueness of names within DNS. address the issue of uniqueness of names within DNS.
4.4. API issues 4.4. API Issues
[RFC2553] provides an API which can partially solve the name [RFC2553] provides an API which can partially solve the name
ambiguity problem for applications written to use this API, since the ambiguity problem for applications written to use this API, since the
sockaddr_in6 structure exposes the scope within which each scoped sockaddr_in6 structure exposes the scope within which each scoped
address exists, and this structure can be used for both IPv4 (using address exists, and this structure can be used for both IPv4 (using
v4-mapped IPv6 addresses) and IPv6 addresses. v4-mapped IPv6 addresses) and IPv6 addresses.
Following the example in Figure 2, an application on 'myhost' issues Following the example in Figure 2, an application on 'myhost' issues
the request getaddrinfo("A", ...) with ai_family=AF_INET6 and the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
skipping to change at page 22, line 39 skipping to change at page 22, line 13
In order to address the security vulnerabilities, the following In order to address the security vulnerabilities, the following
mechanisms are contemplated: mechanisms are contemplated:
[1] Scope restrictions. [1] Scope restrictions.
[2] Usage restrictions. [2] Usage restrictions.
[3] Cache and port separation. [3] Cache and port separation.
[4] Authentication. [4] Authentication.
These techniques are described in the following sections. These techniques are described in the following sections.
5.1. Scope restriction 5.1. Scope Restriction
With LLMNR it is possible that hosts will allocate conflicting names With LLMNR it is possible that hosts will allocate conflicting names
for a period of time, or that attackers will attempt to deny service for a period of time, or that attackers will attempt to deny service
to other hosts by allocating the same name. Such attacks also allow to other hosts by allocating the same name. Such attacks also allow
hosts to receive packets destined for other hosts. hosts to receive packets destined for other hosts.
Since LLMNR is typically deployed in situations where no trust model Since LLMNR is typically deployed in situations where no trust model
can be assumed, it is likely that LLMNR queries and responses will be can be assumed, it is likely that LLMNR queries and responses will be
unauthenticated. In the absence of authentication, LLMNR reduces the unauthenticated. In the absence of authentication, LLMNR reduces the
exposure to such threats by utilizing UDP queries sent to a link- exposure to such threats by utilizing UDP queries sent to a link-
skipping to change at page 23, line 36 skipping to change at page 23, line 10
queries for which they are authoritative, and LLMNR does not provide queries for which they are authoritative, and LLMNR does not provide
wildcard query support, it is believed that this threat is minimal. wildcard query support, it is believed that this threat is minimal.
There also are scenarios such as public "hotspots" where attackers There also are scenarios such as public "hotspots" where attackers
can be present on the same link. These threats are most serious in can be present on the same link. These threats are most serious in
wireless networks such as 802.11, since attackers on a wired network wireless networks such as 802.11, since attackers on a wired network
will require physical access to the home network, while wireless will require physical access to the home network, while wireless
attackers may reside outside the home. Link-layer security can be of attackers may reside outside the home. Link-layer security can be of
assistance against these threats if it is available. assistance against these threats if it is available.
5.2. Usage restriction 5.2. Usage Restriction
As noted in Sections 2 and 3, LLMNR is intended for usage in a As noted in Sections 2 and 3, LLMNR is intended for usage in a
limited set of scenarios. limited set of scenarios.
If an LLMNR query is sent whenever a DNS server does not respond in a If an LLMNR query is sent whenever a DNS server does not respond in a
timely way, then an attacker can poison the LLMNR cache by responding timely way, then an attacker can poison the LLMNR cache by responding
to the query with incorrect information. To some extent, these to the query with incorrect information. To some extent, these
vulnerabilities exist today, since DNS response spoofing tools are vulnerabilities exist today, since DNS response spoofing tools are
available that can allow an attacker to respond to a query more available that can allow an attacker to respond to a query more
quickly than a distant DNS server. quickly than a distant DNS server.
skipping to change at page 24, line 15 skipping to change at page 23, line 38
The vulnerability is more serious if LLMNR is given higher priority The vulnerability is more serious if LLMNR is given higher priority
than DNS among the enabled name resolution mechanisms. In such a than DNS among the enabled name resolution mechanisms. In such a
configuration, a denial of service attack on the DNS server would not configuration, a denial of service attack on the DNS server would not
be necessary in order to poison the LLMNR cache, since LLMNR queries be necessary in order to poison the LLMNR cache, since LLMNR queries
would be sent even when the DNS server is available. In addition, would be sent even when the DNS server is available. In addition,
the LLMNR cache, once poisoned, would take precedence over the DNS the LLMNR cache, once poisoned, would take precedence over the DNS
cache, eliminating the benefits of cache separation. As a result, cache, eliminating the benefits of cache separation. As a result,
LLMNR is only used as a name resolution mechanism of last resort. LLMNR is only used as a name resolution mechanism of last resort.
5.3. Cache and port separation 5.3. Cache and Port Separation
In order to prevent responses to LLMNR queries from polluting the DNS In order to prevent responses to LLMNR queries from polluting the DNS
cache, LLMNR implementations MUST use a distinct, isolated cache for cache, LLMNR implementations MUST use a distinct, isolated cache for
LLMNR on each interface. The use of separate caches is most effective LLMNR on each interface. The use of separate caches is most effective
when LLMNR is used as a name resolution mechanism of last resort, when LLMNR is used as a name resolution mechanism of last resort,
since this minimizes the opportunities for poisoning the LLMNR cache, since this minimizes the opportunities for poisoning the LLMNR cache,
and decreases reliance on it. and decreases reliance on it.
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.
skipping to change at page 26, line 44 skipping to change at page 26, line 20
[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC [RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
2937, September 2000. 2937, September 2000.
[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for [RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration [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
(work in progress), draft-cheshire-dnsext-multicastdns-04.txt,
February 2004.
[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of [DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
Caching", IEEE/ACM Transactions on Networking, Volume 10, Caching", IEEE/ACM Transactions on Networking, Volume 10,
Number 5, pp. 589, October 2002. Number 5, pp. 589, October 2002.
[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local [DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
unicast addresses to communicate with recursive DNS servers", unicast addresses to communicate with recursive DNS servers",
Internet draft (work in progress), draft-ietf-ipv6-dns- Internet draft (work in progress), draft-ietf-ipv6-dns-
discovery-07.txt, October 2002. discovery-07.txt, October 2002.
[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- [POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
skipping to change at page 28, line 11 skipping to change at page 27, line 39
Levon Esibov Levon Esibov
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: levone@microsoft.com EMail: levone@microsoft.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Open Issues Open Issues
Open issues with this specification are tracked on the following web Open issues with this specification are tracked on the following web
site: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html site:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
 End of changes. 

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