draft-ietf-dnsext-mdns-17.txt   draft-ietf-dnsext-mdns-18.txt 
DNSEXT Working Group Levon Esibov DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler Category: Standards Track Dave Thaler
<draft-ietf-dnsext-mdns-17.txt> Microsoft <draft-ietf-dnsext-mdns-18.txt> Microsoft
16 April 2003 1 May 2003
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 Sender behavior ................................. 5 2.1 Sender behavior ................................. 5
2.2 Responder behavior .............................. 5 2.2 Responder behavior .............................. 5
2.3 Unicast queries ................................. 6 2.3 Unicast queries ................................. 6
2.4 Addressing ...................................... 7 2.4 Addressing ...................................... 7
2.5 Off-link detection .............................. 7 2.5 Off-link detection .............................. 7
2.6 Retransmissions ................................. 8 2.6 Retransmissions ................................. 8
2.7 DNS TTL ......................................... 8 2.7 DNS TTL ......................................... 9
3. Usage model ........................................... 8 3. Usage model ........................................... 9
3.1 Unqualified names ............................... 9 3.1 Unqualified names ............................... 10
3.2 LLMNR configuration ............................. 10 3.2 LLMNR configuration ............................. 10
4. Conflict resolution ................................... 11 4. Conflict resolution ................................... 11
4.1 Considerations for multiple interfaces .......... 12 4.1 Considerations for multiple interfaces .......... 13
4.2 API issues ...................................... 14 4.2 API issues ...................................... 14
5. Security considerations ............................... 14 5. Security considerations ............................... 15
5.1 Scope restriction ............................... 14 5.1 Scope restriction ............................... 15
5.2 Usage restriction ............................... 15 5.2 Usage restriction ............................... 16
5.3 Cache and port separation ....................... 16 5.3 Cache and port separation ....................... 16
5.4 Authentication .................................. 16 5.4 Authentication .................................. 17
6. IANA considerations ................................... 16 6. IANA considerations ................................... 17
7. Normative References .................................. 16 7. Normative References .................................. 17
8. Informative References ................................ 17 8. Informative References ................................ 18
Acknowledgments .............................................. 18 Acknowledgments .............................................. 19
Authors' Addresses ........................................... 18 Authors' Addresses ........................................... 19
Intellectual Property Statement .............................. 19 Intellectual Property Statement .............................. 20
Full Copyright Statement ..................................... 19 Full Copyright Statement ..................................... 20
1. Introduction 1. Introduction
This document discusses Link Local Multicast Name Resolution (LLMNR), This document discusses Link Local Multicast Name Resolution (LLMNR),
which operates on a separate port from DNS, with a distinct resolver which operates on a separate port from DNS, with a distinct resolver
cache, but does not change the format of DNS packets. LLMNR supports cache, but does not change the format of DNS packets. LLMNR supports
all current and future DNS formats, types and classes. However, since all current and future DNS formats, types and classes. However, 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.
The goal of LLMNR is to enable name resolution in scenarios in which The goal of LLMNR is to enable name resolution in scenarios in which
conventional DNS name resolution is not possible. These include conventional DNS name resolution is not possible. These include
scenarios in which hosts are not configured with the address of a DNS scenarios in which hosts are not configured with the address of a DNS
server, where configured DNS servers do not reply to a query, or where server, where configured DNS servers do not reply to a query, or where
they respond with errors, as described in Section 3. they respond with errors, as described in Section 3.
LLMNR queries are sent to and received on port TBD using a link-scope LLMNR queries are sent to and received on port TBD. Link-scope
multicast address as specified in "Administratively Scoped IP Multicast" multicast addresses are used to prevent propagation of LLMNR traffic
[RFC2365] for IPv4. The LLMNR link-scope multicast address to be used across routers, potentially flooding the network; for details, see
for IPv4 is 224.0.0.251. For IPv6, the LLMNR link-scope multicast Section 2.4. LLMNR queries can also be sent to a unicast address, as
address is TBD. Link-scope multicast addresses are used to prevent described in Section 2.3.
propagation of LLMNR traffic across routers, potentially flooding the
network; for details, see Section 2.4. In circumstances described in
Section 2.3, LLMNR queries can also be sent to a unicast address.
Propagation of LLMNR packets on the local link is considered sufficient Propagation of LLMNR packets on the local link is considered sufficient
to enable name resolution in small networks. The assumption is that if to enable name resolution in small networks. The assumption is that if
a network has a home gateway, then the network either has a DNS server a network has a home gateway, then the network either has a DNS server
or the home gateway can function as a DNS proxy. By implementing or the home gateway can function as a DNS proxy. By implementing
Dynamic Host Configuration Service for IPv4 (DHCPv4) as well as a DNS Dynamic Host Configuration Service for IPv4 (DHCPv4) as well as a DNS
proxy and dynamic DNS, home gateways can provide name resolution for the proxy and dynamic DNS, home gateways can provide name resolution for the
names of hosts over IPv4 on the local network. names of hosts over IPv4 on the local network.
For small IPv6 networks, equivalent functionality can be provided by a For small IPv6 networks, equivalent functionality can be provided by a
skipping to change at page 4, line 39 skipping to change at page 4, line 34
host may be configured as a sender, but not a responder host may be configured as a sender, but not a responder
or as a responder, but not a sender. or as a responder, but not a sender.
Routable address Routable address
An address other than a linklocal address. This includes An address other than a linklocal address. This includes
site local and globally routable addresses, as well as site local and globally routable addresses, as well as
private addresses. private addresses.
2. Name resolution using LLMNR 2. Name resolution using LLMNR
The sequence of events for LLMNR usage is as follows: A typical sequence of events for LLMNR usage is as follows:
[1] If a sender needs to resolve a query for a name "host.example.com", [1] A sender needs to resolve a query for a name "host.example.com",
then it sends an LLMNR query to the link-scope multicast address. so it sends an LLMNR query to the link-scope multicast address.
[2] A responder responds to this query only if it is authoritative [2] A responder responds to this query only if it is authoritative
for the domain name "host.example.com". The responder sends for the domain name "host.example.com". The responder sends
a response to the sender via unicast over UDP. a response to the sender via unicast over UDP.
[3] Upon the reception of the response, the sender verifies that the [3] Upon the reception of the response, the sender performs the checks
packet originated on-link (see Section 2.5 for details). If these described in Section 2.5. If these conditions are met, then the
conditions are met, then the sender uses and caches the returned sender uses and caches the returned response. If not, then the
response. If not, then the sender ignores the response and continues sender ignores the response and continues waiting for the response.
waiting for the response.
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. Sender behavior 2.1. Sender behavior
A sender sends an LLMNR query for any legal type of resource record A sender sends an LLMNR query for any legal resource record type (e.g.
(e.g. A, PTR, etc.) to the link-scope multicast address. An LLMNR A/AAAA, SRV, PTR, etc.) to the link-scope multicast address. As
sender MAY send requests for any name. described in Section 2.3, a sender may also send a unicast query. An
LLMNR sender MAY send a request for any name.
Under conditions described in Section 2.3, a sender may also send a The RD (Recursion Desired) bit MUST NOT be set in a query. If a
unicast query. The RD (Recursion Desired) bit MUST NOT be set. If a
responder receives a query with the header containing RD set bit, the responder receives a query with the header containing RD set bit, the
responder MUST ignore the RD bit. responder MUST ignore the RD bit.
The sender MUST anticipate receiving no replies to some LLMNR queries, The sender MUST anticipate receiving no replies to some LLMNR queries,
in the event that no responders are available within the linklocal in the event that no responders are available within the link-scope or
multicast scope, or in the event no positive non-null responses exist in the event no positive non-null responses exist for the transmitted
for the transmitted query. If no positive response is received, a query. If no positive response is received, a resolver treats it as a
resolver treats it as a response that no records of the specified type response that no records of the specified type and class exist for the
and class exist for the specified name (it is treated the same as a specified name (it is treated the same as a response with RCODE=0 and an
response with RCODE=0 and an empty answer section). empty answer section).
2.2. Responder behavior 2.2. Responder behavior
A responder listens on port TBD on the link-scope multicast address(es) A responder MUST listen on UDP port TBD on the link-scope multicast
and on the unicast address(es) that could be set as the source address(es) and on UDP and TCP port TBD on the unicast address(es) that
address(es) when the responder responds to the LLMNR query. The host could be set as the source address(es) when the responder responds to
configured as a responder MUST act as a sender to verify the uniqueness the LLMNR query. A host configured as a responder MUST act as a sender
of names as described in Section 4. to verify the uniqueness of names as described in Section 4.
Responders MUST NOT respond to LLMNR queries for names they are not Responders MUST NOT respond to LLMNR queries for names they are not
authoritative for. Responders SHOULD respond to LLMNR queries for names authoritative for. Responders SHOULD respond to LLMNR queries for names
and addresses they are authoritative for. This applies to both forward and addresses they are authoritative for. This applies to both forward
and reverse lookups. and reverse lookups.
As an example, a computer "host.example.com." configured to respond to As an example, a computer "host.example.com." configured to respond to
the LLMNR queries is authoritative for the name "host.example.com.". On LLMNR queries is authoritative for the name "host.example.com.". On
receiving an LLMNR A/AAAA resource record query for the name receiving an LLMNR A/AAAA resource record query for the name
"host.example.com." the host authoritatively responds with A/AAAA "host.example.com." the host authoritatively responds with A/AAAA
record(s) that contain IP address(es) in the RDATA of the resource record(s) that contain IP address(es) in the RDATA of the resource
record. record.
If a responder is authoritative for a name, it MAY respond with RCODE=0 If a responder is authoritative for a name, it MAY respond with RCODE=0
and an empty answer section, if the type of query does not match a RR and an empty answer section, if the type of query does not match a RR
owned by the responder. For example, if the host has a AAAA RR, but no owned by the responder. For example, if the host has a AAAA RR, but no
A RR, and an A RR query is received, the host would respond with RCODE=0 A RR, and an A RR query is received, the host would respond with RCODE=0
and an empty answer section. and an empty answer section.
skipping to change at page 6, line 27 skipping to change at page 6, line 24
name "child.host.example.com." unless the host is configured with name "child.host.example.com." unless the host is configured with
multiple names, including "host.example.com." and multiple names, including "host.example.com." and
"child.host.example.com.". As a result, "host" cannot reply to a query "child.host.example.com.". As a result, "host" cannot reply to a query
for "child" with NXDOMAIN. The purpose of limiting the name authority for "child" with NXDOMAIN. The purpose of limiting the name authority
scope of a responder is to prevent complications that could be caused by scope of a responder is to prevent complications that could be caused by
coexistence of two or more hosts with the names representing child and coexistence of two or more hosts with the names representing child and
parent (or grandparent) nodes in the DNS tree, for example, parent (or grandparent) nodes in the DNS tree, for example,
"host.example.com." and "child.host.example.com.". "host.example.com." and "child.host.example.com.".
In this example (unless this limitation is introduced) an LLMNR query In this example (unless this limitation is introduced) an LLMNR query
for an A record for the name "child.host.example.com." would result in for an A resource record for the name "child.host.example.com." would
two authoritative responses: a name error received from result in two authoritative responses: a name error received from
"host.example.com.", and a requested A record - from "host.example.com.", and a requested A record - from
"child.host.example.com.". To prevent this ambiguity, LLMNR enabled "child.host.example.com.". To prevent this ambiguity, LLMNR enabled
hosts could perform a dynamic update of the parent (or grandparent) zone hosts could perform a dynamic update of the parent (or grandparent) zone
with a delegation to a child zone. In this example a host with a delegation to a child zone. In this example a host
"child.host.example.com." would send a dynamic update for the NS and "child.host.example.com." would send a dynamic update for the NS and
glue A record to "host.example.com.", but this approach significantly glue A record to "host.example.com.", but this approach significantly
complicates implementation of LLMNR and would not be acceptable for complicates implementation of LLMNR and would not be acceptable for
lightweight hosts. lightweight hosts.
A response to a LLMNR query is composed in exactly the same manner as a A response to a LLMNR query is composed in exactly the same manner as a
response to the unicast DNS query as specified in [RFC1035]. Responders response to the unicast DNS query as specified in [RFC1035]. Responders
MUST NOT respond using cached data, and the AA (Authoritative Answer) MUST NOT respond using cached data, and the AA (Authoritative Answer)
bit MUST be set. The response is sent to the sender via unicast. A bit MUST be set. The response is sent to the sender via unicast. A
response to an LLMNR query MUST have RCODE set to zero. Responses with response to an LLMNR query MUST have RCODE set to zero. Responses with
RCODE set to zero are referred to in this document as "positively RCODE set to zero are referred to in this document as "positively
resolved". LLMNR responders may respond only to queries which they can resolved". LLMNR responders may respond only to queries which they can
resolve positively. resolve positively.
2.3. Unicast queries 2.3. Unicast queries and responses
A sender MUST NOT send a unicast LLMNR query except 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
to the previous LLMNR query with the TC bit set, or with the TC bit set to the previous LLMNR multicast query, or
b. The sender's LLMNR cache contains an NS resource record that b. The sender's LLMNR cache contains an NS resource record that
enables the sender to send a query directly to the hosts enables the sender to send a query directly to the hosts
authoritative for the name in the query. authoritative for the name in the query, or
c. The sender queries for a PTR RR.
If a TC (truncation) bit is set in the response, then the sender MAY use If a TC (truncation) bit is set in the response, then the sender MAY use
the response if it contains all necessary information, or the sender MAY the response if it contains all necessary information, or the sender MAY
discard the response and resend the query over TCP or using EDNS0 with discard the response and resend the query over TCP using the unicast
larger window using the unicast address of the responder. The RA address of the responder. The RA (Recursion Available) bit in the
(Recursion Available) bit in the header of the response MUST NOT be set. header of the response MUST NOT be set. If the RA bit is set in the
If the RA bit is set in the response header, the sender MUST ignore it. response header, the sender MUST ignore the RA bit.
Unicast LLMNR queries SHOULD be sent using TCP. Responses to TCP
unicast LLMNR queries MUST be sent using TCP, using the same connection
as the query. If the sender of a TCP query receives a response not
using TCP, the response MUST be silently discarded. Unicast UDP queries
MAY be responded to with an empty answer section and the TC bit set, so
as to require the sender to resend the query using TCP. Senders MUST
support sending TCP queries, and Responders MUST support listening for
TCP queries. The Responder SHOULD set the TTL or Hop Limit 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 prevents an incoming
connection from off-link since the Sender will not receive a SYN-ACK
from the Responder.
If an ICMP "Time Exceeded" message is received in response to a unicast
UDP query, or 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 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
section). The UDP sender receiving an ICMP "Time Exceeded" message
SHOULD verify that the ICMP error payload contains a valid LLMNR query
packet, which matches a query that is currently in progress, so as to
guard against a potential Denial of Service (DoS) attack. If a match
cannot be made, then the sender relies on the retransmission and timeout
behavior described in Section 2.6.
2.4. Addressing 2.4. Addressing
The IPv4 link-scope multicast address a given responder listens to, and IPv4 administratively scoped multicast usage is specified in
to which a sender sends all queries, is 224.0.0.251. The IPv6 link- "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope
scope multicast address a given responder listens to, and to which a multicast address a given responder listens to, and to which a sender
sender sends all queries, is TBD. sends queries, is 224.0.0.251. The IPv6 link-scope multicast address a
given responder listens to, and to which a sender sends all queries, is
TBD.
2.5. Off-link detection 2.5. Off-link detection
The source address of LLMNR queries and responses MUST be "on link". The source address of LLMNR queries and responses MUST be "on link".
The destination address of an LLMNR query MUST be a link-scope multicast The destination address of an LLMNR query MUST be a link-scope multicast
address or an "on link" unicast address; the destination address of an address or an "on link" unicast address; the destination address of an
LLMNR response MUST be an "on link" unicast address. For IPv4, an "on LLMNR response MUST be an "on link" unicast address. On receiving an
link" address is defined as a link-local address or an address whose LLMNR query, the responder MUST check whether it was sent to the LLMNR
prefix belongs to a subnet on the local link; for IPv6 [RFC2460] an "on multicast address; if it was sent to another multicast address, then the
link" address is either a link-local address, defined in [RFC2373], or query MUST be silently discarded.
an address whose prefix belongs to a subnet on the local link. A sender
SHOULD prefer RRs including reachable addresses where RRs involving both
reachable and unreachable addresses are returned in response to a query.
In composing an LLMNR response, the responder MUST set the Hop Limit For IPv4, an "on link" address is defined as a link-local address or an
field in the IPv6 header and the TTL field in IPv4 header of the LLMNR address whose prefix belongs to a subnet on the local link; for IPv6
response to 255. The sender MUST verify that the Hop Limit field in [RFC2460] an "on link" address is either a link-local address, defined
IPv6 header and TTL field in IPv4 header of each response to the LLMNR in [RFC2373], or an address whose prefix belongs to a subnet on the
query is set to 255. If it is not, then sender MUST ignore the local link. A sender SHOULD prefer RRs including reachable addresses
response. where RRs involving both reachable and unreachable addresses are
returned in response to a query.
Since routers decrement the Hop Limit on all packets they forward, In composing LLMNR queries, the sender MUST set the Hop Limit field in
received packets containing a Hop Limit of 255 must have originated from the IPv6 header and the TTL field in IPv4 header of the response to one
a neighbor. (1). Even when LLMNR queries are sent to a link-scope multicast
address, it is possible that some routers may not properly implement
link-scope multicast, or that link-scope multicast addresses may leak
into the multicast routing system. Therefore setting the IPv6 Hop Limit
or IPv4 TTL field to one provides an additional precaution against
leakage of LLMNR queries.
In composing a response to an LLMNR query, the responder MUST set the
Hop Limit field in the IPv6 header and the TTL field in IPv4 header of
the response to one (1). This is done so as to prevent the use of LLMNR
for denial of service attacks across the Internet.
Implementation note: Implementation note:
In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket
options are used to set the TTL of outgoing unicast and multicast options are used to set the TTL of outgoing unicast and multicast
packets. The IP_RECVTTL socket option is available on some platforms packets. The IP_RECVTTL socket option is available on some platforms
to retrieve the IPv4 TTL of received packets with recvmsg(). to retrieve the IPv4 TTL of received packets with recvmsg().
[RFC2292] specifies similar options for setting and retrieving the [RFC2292] specifies similar options for setting and retrieving the
IPv6 Hop Limit. IPv6 Hop Limit.
2.6. Retransmissions 2.6. Retransmissions
In order to avoid synchronization, LLMNR queries and responses are In order to avoid synchronization, LLMNR queries and responses are
delayed by a time uniformly distributed between 0 and 200 ms. delayed by a time uniformly distributed between 0 and 200 ms.
If the LLMNR query is not resolved within the timeout interval If an LLMNR query sent over UDP is not resolved within the timeout
(LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of
order to assure themselves that the query has been received by a host
capable of responding to the query. Since a sender cannot know the query in order to assure that it was received by a host capable of
beforehand whether it will receive no response, one response, or more responding to it. Since a multicast query sender cannot know beforehand
than one response to a query, it SHOULD wait for LLMNR_TIMEOUT in order whether it will receive no response, one response, or more than one
to collect all possible responses, rather than considering the query response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all
answered after the first response is received. possible responses, rather than considering the multicast query answered
after the first response is received. A unicast query sender considers
the query answered after the first response is received, so that it only
waits for LLMNR_TIMEOUT if no response has been received.
LLMNR implementations SHOULD dynamically estimate the timeout value LLMNR implementations SHOULD dynamically estimate the timeout value
(LLMNR_TIMEOUT) on a per-interface basis, using the algorithms described (LLMNR_TIMEOUT) based on the last response received, on a per-interface
in [RFC2988], with a minimum timeout value of 300 ms. Retransmission basis, using the algorithms described in [RFC2988], with a minimum
SHOULD NOT be attempted more than 3 times. timeout value of 300 ms. Retransmission of UDP queries SHOULD NOT be
attempted more than 3 times. Where LLMNR queries are sent using TCP,
retransmission is handled by the transport layer.
2.7. DNS TTL 2.7. DNS TTL
The responder should use a pre-configured TTL value in the records The responder should use a pre-configured TTL value in the records
returned in the LLMNR query response. Due to the TTL minimalization returned in the LLMNR query response. Due to the TTL minimalization
necessary when caching an RRset, all TTLs in an RRset MUST be set to the necessary when caching an RRset, all TTLs in an RRset MUST be set to the
same value. In the additional and authority section of the response the same value. In the additional and authority section of the response the
responder includes the same records as a DNS server would insert in the responder includes the same records as a DNS server would insert in the
response to the unicast DNS query. response to the unicast DNS query.
skipping to change at page 9, line 18 skipping to change at page 10, line 12
SHOULD send LLMNR queries only for names that are either SHOULD send LLMNR queries only for names that are either
unqualified or exist within the default domain. Where no unqualified or exist within the default domain. Where no
DNS server is configured, an LLMNR query MAY be sent for DNS server is configured, an LLMNR query MAY be sent for
any name. any name.
[3] A responder with both link-local and routable addresses [3] A responder with both link-local and routable addresses
MUST respond to LLMNR queries for A/AAAA RRs only with MUST respond to LLMNR queries for A/AAAA RRs only with
routable address(es). This encourages use of routable routable address(es). This encourages use of routable
address(es) for establishment of new connections. address(es) for establishment of new connections.
[4] A sender SHOULD only send LLMNR queries for PTR RRs [4] A sender SHOULD send LLMNR queries for PTR RRs
that represent addresses reachable on the link via unicast, as specified in Section 2.3.
over which LLMNR is used.
RRs returned in LLMNR responses MUST only include values that are valid RRs returned in LLMNR responses MUST only include values that are valid
on the local interface, such as IPv4 or IPv6 addresses valid on the on the local interface, such as IPv4 or IPv6 addresses valid on the
local link or names defended using the mechanism described in Section 4. local link or names defended using the mechanism described in Section 4.
In particular: In particular:
[1] If a link-scope IPv6 address is returned in a AAAA RR, that [1] If a link-scope IPv6 address is returned in a AAAA RR, that
address MUST be valid on the local link over which LLMNR is address MUST be valid on the local link over which LLMNR is
used. used.
skipping to change at page 15, line 5 skipping to change at page 15, line 47
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 for With LLMNR it is possible that hosts will allocate conflicting names for
a period of time, or that attackers will attempt to deny service to a period of time, or that attackers will attempt to deny service to
other hosts by allocating the same name. Such attacks also allow hosts other hosts by allocating the same name. Such attacks also allow hosts
to receive packets destined for other hosts. to receive packets destined for other hosts.
In the absence of authentication, LLMNR reduces the exposure to such Since LLMNR is typically deployed in situations where no trust model can
threats by ignoring LLMNR query response packets received from off-link be assumed, it is likely that LLMNR queries and responses will be
senders. While ignoring packets received from off-link senders reduces unauthenticated. In the absence of authentication, LLMNR reduces the
the level of vulnerability, it does not eliminate it. There are exposure to such threats by utilizing queries sent to a link-scope
scenarios such as public "hotspots" where attackers can be present on multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6)
the same link. These threats are most serious in wireless networks such fields to one (1) on both queries and responses.
as 802.11, since attackers on a wired network will require physical
access to the home network, while wireless attackers may reside outside While this limits the ability of off-link attackers to spoof LLMNR
the home. Link-layer security can be of assistance against these queries and responses, it does not eliminate it. For example, it is
threats if it is available. possible for an attacker to spoof a response to a frequent query (such
as an A/AAAA query for a popular Internet host), and using a TTL or Hop
Limit field larger than one (1), for the forged response to reach the
LLMNR sender. There also are scenarios such as public "hotspots" where
attackers 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 will require physical access to the
home network, while wireless attackers may reside outside the home.
Link-layer security can be of assistance against these threats if it is
available.
5.2. Usage restriction 5.2. Usage restriction
As noted in Section 3, LLMNR is intended for usage in a limited set of As noted in Section 3, LLMNR is intended for usage in a limited set of
scenarios. scenarios.
If an interface has been configured via any automatic configuration If an interface has been configured via any automatic configuration
mechanism which is able to supply DNS configuration information, then mechanism which is able to supply DNS configuration information, then
LLMNR SHOULD NOT be used as the primary name resolution mechanism on LLMNR SHOULD NOT be used as the primary name resolution mechanism on
that interface, although it MAY be used as a name resolution mechanism that interface, although it MAY be used as a name resolution mechanism
skipping to change at page 20, line 14 skipping to change at page 21, line 14
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: site:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
Expiration Date Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-17.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-18.txt>, and expires
November 22, 2003. November 22, 2003.
 End of changes. 

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