draft-ietf-dnsext-mdns-12.txt   draft-ietf-dnsext-mdns-13.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-12.txt> Microsoft <draft-ietf-dnsext-mdns-13.txt> Microsoft
21 August 2002 4 November 2002
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 10 skipping to change at page 2, line 10
name resolution in such environments, Link-Local Multicast Name name resolution in such environments, Link-Local Multicast Name
Resolution (LLMNR) is proposed. LLMNR supports all current and future Resolution (LLMNR) is proposed. LLMNR supports all current and future
DNS formats, types and classes, while operating on a separate port from DNS formats, types and classes, while operating on a separate port from
DNS, and with a distinct resolver cache. DNS, and with a distinct resolver cache.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements .................................... 3 1.1 Requirements .................................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
2. Name resolution using LLMNR ........................... 3 2. Name resolution using LLMNR ........................... 4
2.1 Sender behavior ................................. 4 2.1 Sender behavior ................................. 4
2.2 Responder behavior .............................. 5 2.2 Responder behavior .............................. 5
2.3 Addressing ...................................... 6 2.3 Addressing ...................................... 7
2.4 TTL ............................................. 7 2.4 TTL ............................................. 7
2.5 No/multiple responses ........................... 7 2.5 No/multiple responses ........................... 7
3. Usage model ........................................... 8 3. Usage model ........................................... 8
3.1 LLMNR configuration ............................. 8 3.1 LLMNR configuration ............................. 9
4. Sequence of events .................................... 10 4. Sequence of events .................................... 10
5. Conflict resolution ................................... 10 5. Conflict resolution ................................... 10
5.1 Considerations for multiple interfaces .......... 12 5.1 Considerations for multiple interfaces .......... 12
5.2 API issues ...................................... 14 5.2 API issues ...................................... 14
6. Security considerations ............................... 14 6. Security considerations ............................... 14
6.1 Scope restriction ............................... 15 6.1 Scope restriction ............................... 14
6.2 Usage restriction ............................... 15 6.2 Usage restriction ............................... 15
6.3 Cache and port separation ....................... 16 6.3 Cache and port separation ....................... 16
6.4 Authentication .................................. 16 6.4 Authentication .................................. 16
7. IANA considerations ................................... 16 7. IANA considerations ................................... 16
8. Normative References .................................. 17 8. Normative References .................................. 16
9. Informative References ................................ 17 9. Informative References ................................ 17
Acknowledgments .............................................. 18 Acknowledgments .............................................. 18
Authors' Addresses ........................................... 18 Authors' Addresses ........................................... 18
Intellectual Property Statement .............................. 19 Intellectual Property Statement .............................. 19
Full Copyright Statement ..................................... 19 Full Copyright Statement ..................................... 19
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 all cache, but does not change the format of DNS packets. LLMNR supports all
current and future DNS formats, types and classes. current and future DNS formats, types and classes.
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. server, where configured DNS servers do not reply to a query, or where
they respond with RCODE set to NXRRSET.
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 for IPv4, while remaining unconfigured with a DNS server DNS server over IPv4, while remaining unconfigured with a DNS server
suitable for use with IPv6. Since automatic IPv6 DNS configuration suitable for use over IPv6. In these situations, a dual stack host will
mechanisms such as [DHCPv6DNS] and [DNSDisc] are not yet widely send AAAA queries to the configured DNS server over IPv4. However, an
deployed, such "partially configuration" may be common in the short IPv6-only host will not be able to resolve names.
term. However, in the long term, IPv6 DNS configuration will become more
common so that LLMNR will typically be restricted to adhoc networks in Since automatic IPv6 DNS configuration mechanisms such as [DHCPv6DNS]
which neither IPv4 nor IPv6 DNS servers are configured. and [DNSDisc] are not yet widely deployed, and not all DNS servers
support IPv6, "partial configuration" may be common in the short term,
and LLMNR may prove useful in enabling linklocal name resolution over
IPv6. However, in the long term, IPv6 DNS configuration, and DNS support
over IPv6 will become more common so that LLMNR usage will typically be
restricted to adhoc networks in which neither IPv4 nor IPv6 DNS servers
are configured, situations in which DNS servers do not respond to
queries, or where they respond with RCODE set to NXRRSET.
Service discovery in general, as well as discovery of DNS servers using Service discovery in general, as well as discovery of DNS servers using
LLMNR in particular is outside of the scope of this document, as is name LLMNR in particular is outside of the scope of this document, as is name
resolution over non-multicast capable media. resolution over non-multicast capable media.
1.1. Requirements 1.1. Requirements
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC2119]. described in [RFC2119].
1.2. Terminology 1.2. Terminology
Responder A host that listens to (but not necessarily responds to) Responder A host that listens to LLMNR queries, and responds to
a LLMNR query is called "responder". those for which it is authoritative is called
"responder".
Sender A host that sends an LLMNR query. The same host may be Sender A host that sends an LLMNR query. Typically a host is
configured as a "sender", but not a "responder" and vice configured as both a sender and a responder, but a host
versa, i.e. as a "responder", but not a "sender". may be configured as a "sender", but not a "responder" or
a "responder" but not a "sender".
2. Name resolution using LLMNR 2. Name resolution using LLMNR
While operating on a different port with a distinct resolver cache, While operating on a different port with a distinct resolver cache,
LLMNR makes no change to the current format of DNS packets. LLMNR makes no change to the current format of DNS packets.
LLMNR queries are sent to and received on port 5353 using a LINKLOCAL LLMNR queries are sent to and received on port TBD using a LINKLOCAL
address as specified in "Administratively Scoped IP Multicast" [RFC2365] address as specified in "Administratively Scoped IP Multicast" [RFC2365]
for IPv4 and the "solicited name" LINKLOCAL multicast addresses for for IPv4 and the "solicited name" LINKLOCAL multicast addresses for
IPv6, and using a unicast addresses in a few scenarios described below IPv6, and using a unicast addresses in a few scenarios described below
in Section 3. The LLMNR LINKLOCAL address to be used for IPv4 is in Section 3. The LLMNR LINKLOCAL address to be used for IPv4 is
224.0.0.251. LINKLOCAL addresses are used to prevent propagation of 224.0.0.251. LINKLOCAL addresses are used to prevent propagation of
LLMNR traffic across routers, potentially flooding the network. LLMNR traffic across routers, potentially flooding the network.
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 a 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 or 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 DHCPv4 as the home gateway can function as a DNS proxy. By implementing DHCPv4 as
skipping to change at page 4, line 16 skipping to change at page 4, line 25
IPv6, and using a unicast addresses in a few scenarios described below IPv6, and using a unicast addresses in a few scenarios described below
in Section 3. The LLMNR LINKLOCAL address to be used for IPv4 is in Section 3. The LLMNR LINKLOCAL address to be used for IPv4 is
224.0.0.251. LINKLOCAL addresses are used to prevent propagation of 224.0.0.251. LINKLOCAL addresses are used to prevent propagation of
LLMNR traffic across routers, potentially flooding the network. LLMNR traffic across routers, potentially flooding the network.
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 a 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 or 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 DHCPv4 as the home gateway can function as a DNS proxy. By implementing DHCPv4 as
well as a DNS proxy and dynamic DNS, home gateways can provide name well as a DNS proxy and dynamic DNS, home gateways can provide name
resolution for the names of IPv4 hosts on the local network. resolution for the 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
home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as
well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name
resolution for the names of IPv6 hosts on the local network. resolution for the names of hosts over IPv6 on the local network.
This should be adequate as long as home gateways implementing DNS This should be adequate as long as home gateways implementing DNS
configuration also support dynamic DNS in some form. If the home configuration also support dynamic DNS in some form.
gateway only supports DNS discovery [DNSDisc] but not DHCPv6 DNS
configuration [DHCPv6DNS] or dynamic client update, then resolution of
the names of IPv6 hosts on the local link will not be possible. Since
IPv6 DNS discovery will configure the DNS server address, LLMNR will not
be enabled by default. Yet without gateway support for client dynamic
update or DHCPv6, dynamic DNS will not be enabled.
In the future, LLMNR may be defined to support greater than LINKLOCAL In the future, LLMNR may be defined to support greater than LINKLOCAL
multicast scope. This would occur if LLMNR deployment is successful, multicast scope. This would occur if LLMNR deployment is successful,
the assumption that LLMNR is not needed on multiple links proves the assumption that LLMNR is not needed on multiple links proves
incorrect, and multicast routing becomes ubiquitous. For example, it is incorrect, and multicast routing becomes ubiquitous. For example, it is
not clear that this assumption will be valid in large adhoc networking not clear that this assumption will be valid in large adhoc networking
scenarios. scenarios.
Once we have experience in LLMNR deployment in terms of administrative Once we have experience in LLMNR deployment in terms of administrative
issues, usability and impact on the network it will be possible issues, usability and impact on the network it will be possible
skipping to change at page 5, line 23 skipping to change at page 5, line 27
multicast address". (Note: this procedure is intended to be the same as multicast address". (Note: this procedure is intended to be the same as
that specified in section 3 of "IPv6 Node Information Queries" that specified in section 3 of "IPv6 Node Information Queries"
[NodeInfo]). A responder that listens for queries for multiple names [NodeInfo]). A responder that listens for queries for multiple names
will necessarily listen to multiple of these solicited name multicast will necessarily listen to multiple of these solicited name multicast
addresses. addresses.
If the LLMNR query is not resolved during a limited amount of time If the LLMNR query is not resolved during a limited amount of time
(LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in
order to assure themselves that the query has been received by a host order to assure themselves that the query has been received by a host
capable of responding to the query. The default value for LLMNR_TIMEOUT capable of responding to the query. The default value for LLMNR_TIMEOUT
is 1 second. is 1 second. Since a sender cannot know beforehand whether it will
receive no response, one response, or more than one response to a query,
it SHOULD wait for LLMNR_TIMEOUT in order to collect all possible
responses, rather than considering the query answered after the first
response is received.
Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be
repeated more often than once per second to reduce unnecessary network repeated more often than once per second to reduce unnecessary network
traffic. The delay between attempts should be randomized so as to avoid traffic. The delay between attempts should be randomized so as to avoid
synchronization effects. synchronization effects.
2.2. Responder behavior 2.2. Responder behavior
A responder listens on port 5353 on the LINKLOCAL address and on the A responder listens on port TBD on the LINKLOCAL address and on the
unicast address(es) that could be set as the source address(es) when the unicast address(es) that could be set as the source address(es) when the
responder responds to the LLMNR query. The host configured as a responder responds to the LLMNR query. The host configured as a
"responder" MUST act as a sender by using LLMNR dynamic update requests "responder" MUST act as a sender by using LLMNR dynamic update requests
to verify the uniqueness of names as described in Section 5. to verify the uniqueness of names as described in Section 5.
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.
skipping to change at page 7, line 38 skipping to change at page 7, line 47
2.5. No/multiple responses 2.5. No/multiple responses
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 linklocal
multicast scope, or in the event that no positive non-null responses multicast scope, or in the event that no positive non-null responses
exist for the transmitted query. If no positive response is received, a exist for the transmitted query. If no positive response is received, a
resolver treats it as a response that no records of the specified type resolver treats it as a response that no records of the specified type
and class for the specified name exist (NXRRSET). and class for the specified name exist (NXRRSET).
Since the responder MUST NOT respond to queries for names it is not While the responder MUST NOT respond to queries for names it is not
authoritative for, a responder MUST NOT respond to an A, A6 or AAAA RR authoritative for, a responder MAY respond to a query for the name it is
query with an NXRRSET. However, if the host has a AAAA RR, but no MX RR, authoritative for, even if the type of query does not match a RR owned
and an MX RR query is received, the host would respond as follows: by the responder, with RCODE set to NXRRSET. For example, if the host
has a AAAA RR, but no A RR, and an A RR query is received, the host
RCODE: NOERROR would respond with an RCODE set to NXRRSET.
Answer: <empty>
Authority: SOA for zone.
Additional: Empty.
The sender MUST anticipate receiving multiple replies to the same LLMNR The sender MUST anticipate receiving multiple replies to the same LLMNR
query, in the event that several LLMNR enabled computers receive the query, in the event that several LLMNR enabled computers receive the
query and respond with valid answers. When this occurs, the responses query and respond with valid answers. When this occurs, the responses
MAY first be concatenated, and then treated in the same manner that MAY first be concatenated, and then treated in the same manner that
multiple RRs received from the same DNS server would, ordinarily. multiple RRs received from the same DNS server would, ordinarily.
However, after receiving an initial response, the sender is not required
to wait for LLMNR_TIMEOUT for additional responses.
3. Usage model 3. Usage model
The same host may be configured as a "sender", but not a "responder" and A host may be configured as a "sender", but not a "responder" or as a
vice versa (as a "responder", but not "sender"). However, a host "responder", but not a "sender". However, a host configured as a
configured as a "responder" MUST at least use a "sender's" capability to "responder" MUST at least use a "sender's" capability to send LLMNR
send LLMNR dynamic update requests to verify the uniqueness of the dynamic update requests to verify the uniqueness of the names, as
names, as described in Section 5. An LLMNR "sender" MAY multicast described in Section 5. An LLMNR "sender" MAY multicast requests for any
requests for any name. If that name is not qualified and does not end in name. If that name is not qualified and does not end in a trailing dot,
a trailing dot, for the purposes of LLMNR, the implicit search order is for the purposes of LLMNR, the implicit search order is as follows:
as follows:
[1] Request the name with the current domain appended. [1] Request the name with the current domain appended.
[2] Request just the name. [2] Request just the name.
This is the behavior suggested by [RFC1536]. LLMNR uses this technique This is the behavior suggested by [RFC1536]. LLMNR uses this technique
to resolve unqualified host names. The same host MAY use LLMNR queries to resolve unqualified host names. The same host MAY use LLMNR queries
for the resolution of unqualified host names, and conventional DNS for the resolution of unqualified host names, and conventional DNS
queries for resolution of other DNS names. queries for resolution of other DNS names.
If a DNS server is running on a host that supports LLMNR, the DNS server If a DNS server is running on a host that supports LLMNR, the DNS server
skipping to change at page 8, line 49 skipping to change at page 8, line 51
authoritative for the name in the query. authoritative for the name in the query.
A responder with a name "host.example.com." configured to respond to the A responder with a name "host.example.com." configured to respond to the
LLMNR queries is authoritative for the name "host.example.com.". For LLMNR queries is authoritative for the name "host.example.com.". For
example, when a responder with the name "host.example.com." receives an example, when a responder with the name "host.example.com." receives an
A type LLMNR query for the name "host.example.com." it authoritatively A type LLMNR query for the name "host.example.com." it authoritatively
responds to the query. responds to the query.
3.1. LLMNR configuration 3.1. LLMNR configuration
LLMNR usage can be configured manually or automatically. On interfaces LLMNR usage MAY be configured manually or automatically on a per
where no manual or automatic DNS configuration has been performed for a interface basis. By default, LLMNR responders SHOULD be enabled on all
given protocol (IPv4 or IPv6), LLMNR SHOULD be enabled for that
protocol.
For IPv6, the stateless DNS discovery mechanisms described in "IPv6 interfaces, at all times. By default, LLMNR requests SHOULD be sent
Stateless DNS Discovery" [DNSDisc] or "Using DHCPv6 for DNS only when no manual or automatic DNS configuration has been performed,
Configuration in Hosts" [DHCPv6DNS] can be used to discover whether when DNS servers do not respond, or when they respond to a query with an
LLMNR should be enabled or disabled on a per-interface basis. RCODE set to NXRRSET.
Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
configure LLMNR on an interface. The LLMNR Enable Option, described in configure LLMNR on an interface. The LLMNR Enable Option, described in
[LLMNREnable], can be used to explicitly enable or disable use of LLMNR [LLMNREnable], can be used to explicitly enable or disable use of LLMNR
on an interface. The LLMNR Enable Option does not determine whether or on an interface. The LLMNR Enable Option does not determine whether or
in which order DNS itself is used for name resolution. The order in in which order DNS itself is used for name resolution. The order in
which various name resolution mechanisms should be used can be specified which various name resolution mechanisms should be used can be specified
using the Name Service Search Option for DHCP, [RFC2937]. using the Name Service Search Option for DHCP, [RFC2937].
Note that it is possible for LLMNR to be enabled for use with IPv6 at A home gateway may implement a DNS proxy and DHCPv4, but not DHCPv6 for
the same time it is disabled for IPv4, and vice versa. For example, a DNS configuration [DHCPv6DNS]. In such a circumstance, IPv6-only hosts
home gateway may implement a DNS proxy and DHCPv4, but not DHCPv6 for will not be configured with a DNS server. Where the DNS proxy does not
DNS configuration [DHCPv6DNS] or stateless DNS discovery [DNSDisc]. In support dynamic client update over IPv6 or DHCPv6-based dynamic update
such a circumstance, IPv6 hosts will not be configured with a DNS of the DNS proxy, the home gateway will not be able to dynamically
server. Where DHCPv6 is not supported, the DNS proxy within the home register the names of IPv6 hosts. As a result, the DNS proxy will
gateway will not be able to dynamically register names learned via respond to AAAA RR queries sent over IPv4 or IPv6 with an RCODE of
DHCPv6. As a result, unless the DNS proxy supports client dynamic NXRRSET. This prevents hosts from resolving the names of IPv6-only
update, it will not be able to respond to AAAA RR queries for local hosts on the local link. In this situation, LLMNR over IPv6 can be used
names sent over IPv4 or IPv6, preventing IPv6 hosts from resolving the for resolution of dynamic names.
names of other IPv6 hosts on the local link. In this situation, LLMNR
enables resolution of dynamic names, and it will be enabled for use with
IPv6, even though it is disabled for use with IPv4.
3.1.1. Consistency of configuration 3.1.1. Consistency of configuration
It is possible that DNS servers and/or DNS configuration mechanisms will It is possible that DNS servers and/or DNS configuration mechanisms will
go in and out of service. In these circumstances, it is possible for go in and out of service. In these circumstances, it is possible for
hosts within an administrative domain to be inconsistent in their DNS hosts within an administrative domain to be inconsistent in their DNS
configuration. configuration.
For example, where DHCP is used for configuring DNS servers, one or more For example, where DHCP is used for configuring DNS servers, one or more
DHCP servers can go down. As a result, hosts configured prior to the DHCP servers can go down. As a result, hosts configured prior to the
outage will be configured with a DNS server, while hosts configured outage will be configured with a DNS server, while hosts configured
after the outage will use LLMNR. When the DHCP server comes back online, after the outage will not.
it is desirable that unconfigured hosts obtain their configuration from
it.
Alternatively, it is possible for the DNS configuration mechanism to Alternatively, it is possible for the DNS configuration mechanism to
continue functioning while the configured DNS servers fail. In this continue functioning while configured DNS servers fail.
circumstance, it may be desirable for administrators to be able to
reconfigure hosts to utilize alternative DNS servers.
In order to minimize inconsistencies, the following practices are In order to minimize inconsistencies, the following practices are
recommended: recommended:
Periodic retry Periodic retry
Unless unconfigured hosts periodically retry configuration, an Unless unconfigured hosts periodically retry configuration, an
outage in the DNS configuration mechanism will result in hosts outage in the DNS configuration mechanism will result in hosts
continuing to use LLMNR even once the outage is repaired. Since continuing to prefer LLMNR even once the outage is repaired. Since
LLMNR only enables linklocal name resolution, this represents an LLMNR only enables linklocal name resolution, this represents an
unnecessary degradation in capabilities. As a result, it is unnecessary degradation in capabilities. As a result, it is
recommended that hosts without a configured DNS server periodically recommended that hosts without a configured DNS server periodically
attempt to obtain DNS configuration. The recommended default retry attempt to obtain DNS configuration. A default retry interval of
interval is 30 seconds. two (2) minutes is recommended.
DNS failover DNS failover
For security reasons, by default LLMNR is not enabled for the By default, LLMNR queries are not sent unless DNS is not
resolution of FQDNs where a DNS server has been configured. This configured, configured DNS servers have not responded, or respond
implies that where a DNS server has been configured, LLMNR will not with an RCODE of NXRRSET. However, where all configured DNS
be used by default for resolution of FQDNs, even in the event that servers fail, LLMNR queries will be sent.
all configured DNS servers fail. In this circumstance, it may
desirable for hosts to retry DNS configuration, so as to discover
alternative DNS servers, if they are available. If the
configuration mechanism does not respond, hosts MAY enable LLMNR.
However, if the configuration mechanism merely configures non-
functioning DNS servers, this is not sufficient reason to enable
default LLMNR usage, without an explicit indication that LLMNR
usage is desired.
4. Sequence of events 4. Sequence of events
The sequence of events for LLMNR usage is as follows: The 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. If a sender needs to resolve a query for a name "host.example.com",
then it sends a LLMNR query to the LINKLOCAL multicast address. then it sends a LLMNR query to the LINKLOCAL 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
skipping to change at page 11, line 4 skipping to change at page 10, line 38
verifies compliance with the addressing requirements for IPv4, verifies compliance with the addressing requirements for IPv4,
described in [IPV4Link], and IPv6, described in [RFC2373]. If these described in [IPV4Link], and IPv6, described in [RFC2373]. If these
conditions are met, then the sender uses and caches the returned conditions are met, then the sender uses and caches the returned
response. If not, then the sender ignores the response and continues response. If not, then the sender ignores the response and continues
waiting for the response. waiting for the response.
5. Conflict resolution 5. Conflict resolution
There are some scenarios when multiple responders MAY respond to the There are some scenarios when multiple responders MAY respond to the
same query. There are other scenarios when only one responder may same query. There are other scenarios when only one responder may
respond to a query. Resource records for which the latter queries are respond to a query. Resource records for which the latter queries are
submitted are referred as UNIQUE throughout this document. The submitted are referred as UNIQUE throughout this document. The
uniqueness of a resource record depends on a nature of the name in the uniqueness of a resource record depends on a nature of the name in the
query and type of the query. For example it is expected that: query and type of the query. For example it is expected that:
- multiple hosts may respond to a query for a SRV type record - multiple hosts may respond to a query for an SRV type record
- multiple hosts may respond to a query for an A type record for a - multiple hosts may respond to a query for an A or AAAA type record for a
cluster name (assigned to multiple hosts in the cluster) cluster name (assigned to multiple hosts in the cluster)
- only a single host may respond to a query for an A type record for - only a single host may respond to a query for an A or AAAA type record for
a hostname. a hostname.
Every responder that responds to a LLMNR query and/or dynamic update Every responder that responds to a LLMNR query and/or dynamic update
request AND includes a UNIQUE record in the response: request AND includes a UNIQUE record in the response:
1. MUST verify that there is no other host within the scope of the 1. MUST verify that there is no other host within the scope of the
LLMNR query propagation that can return a resource record LLMNR query propagation that can return a resource record
for the same name, type and class. for the same name, type and class.
2. MUST NOT include a UNIQUE resource record in the 2. MUST NOT include a UNIQUE resource record in the
response without having verified its uniqueness. response without having verified its uniqueness.
Where a host is configured to respond to LLMNR queries on more than one Where a host is configured to respond to LLMNR queries on more than one
interface, the host MUST verify resource record uniqueness on each interface, each interface should have its own independent LLMNR cache.
interface for each UNIQUE resource record that could be used on that For each UNIQUE resource record in a given interface's cache, the host
interface. To accomplish this, the host MUST send a dynamic LLMNR update MUST verify resource record uniqueness on that interface. To accomplish
request for each new UNIQUE resource record. Format of the dynamic LLMNR this, the host MUST send a dynamic LLMNR update request for each new
update request is identical to the format of the dynamic DNS update UNIQUE resource record. Format of the dynamic LLMNR update request is
request specified in [RFC2136]. Uniqueness verification is carried out identical to the format of the dynamic DNS update request specified in
when the host: [RFC2136]. Uniqueness verification is carried out when the host:
- starts up or - starts up or
- is configured to respond to the LLMNR queries on some interface or - is configured to respond to the LLMNR queries on some interface or
- is configured to respond to the LLMNR queries using additional - is configured to respond to the LLMNR queries using additional
UNIQUE resource records. UNIQUE resource records.
Below we describe the data to be specified in the dynamic update Below we describe the data to be specified in the dynamic update
request: request:
Header section Header section
skipping to change at page 14, line 45 skipping to change at page 14, line 21
multiple addrinfo structures, each with an associated sockaddr_in6 multiple addrinfo structures, each with an associated sockaddr_in6
structure. This list will thus contain the IPv4 and IPv6 addresses of structure. This list will thus contain the IPv4 and IPv6 addresses of
both hosts responding to the name 'A'. Link-local addresses will have a both hosts responding to the name 'A'. Link-local addresses will have a
sin6_scope_id value that disambiguates which interface is used to reach sin6_scope_id value that disambiguates which interface is used to reach
the address. Of course, to the application, Figures 2 and 3 are still the address. Of course, to the application, Figures 2 and 3 are still
indistinguishable, but this API allows the application to communicate indistinguishable, but this API allows the application to communicate
successfully with any address in the list. successfully with any address in the list.
6. Security Considerations 6. Security Considerations
LLMNR is by nature a peer to peer name resolution protocol, for use in LLMNR is by nature a peer to peer name resolution protocol. It is
situations when a DNS server is not configured. It is therefore therefore inherently more vulnerable than DNS, since existing DNS
inherently more vulnerable than DNS, since existing DNS security security mechanisms are difficult to apply to LLMNR and an attacker only
mechanisms are difficult to apply to LLMNR and an attacker only needs to needs to be misconfigured to answer an LLMNR query with incorrect
be misconfigured to answer an LLMNR query with incorrect information. information.
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.
skipping to change at page 15, line 42 skipping to change at page 15, line 19
scenarios such as public "hotspots" where attackers can be present on scenarios such as public "hotspots" where attackers can be present on
the same link. These threats are most serious in wireless networks such the same link. These threats are most serious in wireless networks such
as 802.11, since attackers on a wired network will require physical as 802.11, since attackers on a wired network will require physical
access to the home network, while wireless attackers may reside outside access to the home network, while wireless attackers may reside outside
the home. Link-layer security can be of assistance against these the home. Link-layer security can be of assistance against these
threats if it is available. threats if it is available.
6.2. Usage restriction 6.2. Usage restriction
As noted in Section 3.1, LLMNR is intended for usage in scenarios where As noted in Section 3.1, LLMNR is intended for usage in scenarios where
a DNS server is not configured. If an interface has been configured for a DNS server is not configured, DNS servers do not respond to queries or
a given protocol via any automatic configuration mechanism which is able respond with RCODE set to NXRRSET. If an interface has been configured
to supply DNS configuration information, then LLMNR SHOULD NOT be used via any automatic configuration mechanism which is able to supply DNS
on that interface for that protocol unless it has been explicitly configuration information, then LLMNR MUST NOT be used as the primary
enabled, whether via that mechanism or any other. This ensures that name resolution mechanism on that interface, although it MAY be used as
upgraded hosts do not change their default behavior, without requiring a secondary mechanism when DNS servers do not respond to queries, or
the source of the configuration information to be simultaneously respond with RCODE set to NXRRSET.
updated. This implies that on the interface, the host will neither
listen on the LINKLOCAL multicast address, nor will it send queries to
that address.
Violation of this guideline can significantly increases security Note: enabling LLMNR for use in situations where a DNS server has been
vulnerabilities. For example, if an LLMNR query were to be sent configured will result in upgraded hosts changing their default behavior
whenever a DNS server did not respond in a timely way, then an attacker without a simultaneous update to configuration information. Where this
could execute a denial of service attack on the DNS server(s) and then is considered undesirable, LLMNR SHOULD NOT be enabled by default, so
poison the LLMNR cache by responding to the resulting LLMNR queries with that hosts will neither listen on the LINKLOCAL multicast address, nor
incorrect information. will it send queries to that address.
The vulnerability would be even greater if LLMNR is given higher Use of LLMNR as a secondary name resolution mechanism increases security
priority than DNS among the enabled name resolution mechanisms. In such vulnerabilities. For example, if an LLMNR query is sent whenever a DNS
a configuration, a denial of service attack on the DNS server would not server does not respond in a timely way, then an attacker can execute a
be necessary in order to poison the LLMNR cache, since LLMNR queries denial of service attack on the DNS server(s) and then poison the LLMNR
would be sent even when the DNS server is available. In addition, the cache by responding to the resulting LLMNR queries with incorrect
LLMNR cache, once poisoned, would take precedence over the DNS cache, information.
eliminating the benefits of cache separation.
As a result, LLMNR is best thought of as a name resolution mechanism of The vulnerability is more serious if LLMNR is given higher priority than
last resort, useful only in situations where a DNS server is not DNS among the enabled name resolution mechanisms. In such a
configured. Where resilience against DNS server failure is desired, configuration, a denial of service attack on the DNS server would not be
configuration of additional DNS servers or DNS server clustering is necessary in order to poison the LLMNR cache, since LLMNR queries would
recommended; LLMNR is not an appropriate "failsafe" mechanism. be sent even when the DNS server is available. In addition, the LLMNR
cache, once poisoned, would take precedence over the DNS cache,
eliminating the benefits of cache separation. As a result, LLMNR is best
thought of as a secondary name resolution mechanism.
6.3. Cache and port separation 6.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. The use of separate caches is most effective when LLMNR is used LLMNR on each interface. The use of separate caches is most effective
as a name resolution mechanism of last resort, since the this minimizes when LLMNR is used as a name resolution mechanism of last resort, since
the opportunities for poisoning the LLMNR cache, and decreases reliance the this minimizes the opportunities for poisoning the LLMNR cache, and
on it. decreases reliance on it.
LLMNR operates on a separate port (5353) from DNS, reducing the LLMNR operates on a separate port from DNS, reducing the likelihood that
likelihood that a DNS server will unintentionally respond to an LLMNR a DNS server will unintentionally respond to an LLMNR query.
query.
6.4. Authentication 6.4. Authentication
LLMNR does not require use of DNSSEC, and as a result, responses to LLMNR does not require use of DNSSEC, and as a result, responses to
LLMNR queries MAY NOT be authenticated. If authentication is desired, LLMNR queries MAY NOT be authenticated. If authentication is desired,
and a pre-arranged security configuration is possible, then IPsec ESP and a pre-arranged security configuration is possible, then IPsec ESP
with a null-transform MAY be used to authenticate LLMNR responses. In a with a null-transform MAY be used to authenticate LLMNR responses. In a
small network without a certificate authority, this can be most easily small network without a certificate authority, this can be most easily
accomplished through configuration of a group pre-shared key for trusted accomplished through configuration of a group pre-shared key for trusted
hosts. hosts.
7. IANA Considerations 7. IANA Considerations
This specification does not create any new name spaces for IANA This specification does not create any new name spaces for IANA
administration. Since it uses a port (5353) and link scope multicast administration. LLMNR requires allocation of a port. LLMNR utilizes a
link scope multicast IPv4 address (224.0.0.251) that has been previously
IPv4 address (224.0.0.251) previously allocated for use with LLMNR, no allocated to LLMNR by IANA.
additional IANA allocations are required.
8. Normative References 8. Normative References
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987. Specification", RFC 1035, November 1987.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 18, line 34 skipping to change at page 18, line 13
lookups-08.txt, July 2001. lookups-08.txt, July 2001.
Acknowledgments Acknowledgments
This work builds upon original work done on multicast DNS by Bill This work builds upon original work done on multicast DNS by Bill
Manning and Bill Woodcock. Bill Manning's work was funded under DARPA Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
grant #F30602-99-1-0523. The authors gratefully acknowledge their grant #F30602-99-1-0523. The authors gratefully acknowledge their
contribution to the current specification. Constructive input has also contribution to the current specification. Constructive input has also
been received from Mark Andrews, Stuart Cheshire, Robert Elz, Rob been received from Mark Andrews, Stuart Cheshire, Robert Elz, Rob
Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Hattig, Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Hattig,
Thomas Narten, Erik Nordmark, Sander Van-Valkenburg, Tomohide Nagashima Thomas Narten, Erik Nordmark, Sander Van-Valkenburg, Tomohide Nagashima,
and Brian Zill. Brian Zill, Keith Moore and Markku Savela.
Authors' Addresses Authors' Addresses
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
skipping to change at page 20, line 4 skipping to change at page 19, line 43
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into Standards process must be followed, or as required to translate it into
languages other than English. The limited permissions granted above are languages other than English. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE IMPLIED, 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."
Expiration Date Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-12.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-13.txt>, and expires May
February 22, 2003. 22, 2003.
 End of changes. 

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