draft-ietf-dnsext-mdns-11.txt   draft-ietf-dnsext-mdns-12.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-11.txt> Microsoft <draft-ietf-dnsext-mdns-12.txt> Microsoft
20 July 2002 21 August 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 18 skipping to change at page 2, line 18
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 ........................... 3
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 ...................................... 6
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 ............................. 8
4. Sequence of events .................................... 9 4. Sequence of events .................................... 10
5. Conflict resolution ................................... 10 5. Conflict resolution ................................... 10
5.1 Considerations for multiple interfaces .......... 11 5.1 Considerations for multiple interfaces .......... 12
5.2 API issues ...................................... 13 5.2 API issues ...................................... 14
6. Security considerations ............................... 13 6. Security considerations ............................... 14
6.1 Scope restriction ............................... 14 6.1 Scope restriction ............................... 15
6.2 Usage restriction ............................... 14 6.2 Usage restriction ............................... 15
6.3 Cache and port separation ....................... 15 6.3 Cache and port separation ....................... 16
6.4 Authentication .................................. 15 6.4 Authentication .................................. 16
7. IANA considerations ................................... 15 7. IANA considerations ................................... 16
8. Normative References .................................. 16 8. Normative References .................................. 17
9. Informative References ................................ 16 9. Informative References ................................ 17
Acknowledgments .............................................. 17 Acknowledgments .............................................. 18
Authors' Addresses ........................................... 17 Authors' Addresses ........................................... 18
Intellectual Property Statement .............................. 18 Intellectual Property Statement .............................. 19
Full Copyright Statement ..................................... 18 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
skipping to change at page 7, line 40 skipping to change at page 7, line 40
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 Since 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 MUST NOT respond to an A, A6 or AAAA RR
query with an NXRRSET. However, for other queries, such a response is query with an NXRRSET. However, if the host has a AAAA RR, but no MX RR,
possible; for example, if the host has a AAAA RR, but no MX RR, and an and an MX RR query is received, the host would respond as follows:
MX RR query is received.
RCODE: NOERROR
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 However, after receiving an initial response, the sender is not required
to wait for LLMNR_TIMEOUT for additional responses. 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 The same host may be configured as a "sender", but not a "responder" and
vice versa (as a "responder", but not "sender"). However, a host vice versa (as a "responder", but not "sender"). However, a host
configured as a "responder" MUST at least use a "sender's" capability to configured as a "responder" MUST at least use a "sender's" capability to
send LLMNR dynamic update requests to verify the uniqueness of the send LLMNR dynamic update requests to verify the uniqueness of the
names, as described in Section 5. An LLMNR "sender" MAY multicast names, as described in Section 5. An LLMNR "sender" MAY multicast
skipping to change at page 9, line 21 skipping to change at page 9, line 23
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 Note that it is possible for LLMNR to be enabled for use with IPv6 at
the same time it is disabled for IPv4, and vice versa. For example, a the same time it is disabled for IPv4, and vice versa. For example, a
home gateway may implement a DNS proxy and DHCPv4, but not DHCPv6 for home gateway may implement a DNS proxy and DHCPv4, but not DHCPv6 for
DNS configuration [DHCPv6DNS] or stateless DNS discovery [DNSDisc]. In DNS configuration [DHCPv6DNS] or stateless DNS discovery [DNSDisc]. In
such a circumstance, IPv6 hosts will not be configured with a DNS such a circumstance, IPv6 hosts will not be configured with a DNS
server. Where DHCPv6 is not supported, it will not be possible for the server. Where DHCPv6 is not supported, the DNS proxy within the home
DNS proxy within the home gateway to dynamically register names learned gateway will not be able to dynamically register names learned via
via DHCPv6. As a result, unless the DNS proxy supports client update, it DHCPv6. As a result, unless the DNS proxy supports client dynamic
will not be able to respond to AAAA RR queries for local names sent over update, it will not be able to respond to AAAA RR queries for local
IPv4 or IPv6, preventing IPv6 hosts from resolving the names of other names sent over IPv4 or IPv6, preventing IPv6 hosts from resolving the
IPv6 hosts on the local link. In this situation, LLMNR enables names of other IPv6 hosts on the local link. In this situation, LLMNR
resolution of dynamic names, and it will be enabled for use with IPv6, enables resolution of dynamic names, and it will be enabled for use with
even though it is disabled for use with IPv4. IPv6, even though it is disabled for use with IPv4.
3.1.1. Consistency of configuration
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
hosts within an administrative domain to be inconsistent in their DNS
configuration.
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
outage will be configured with a DNS server, while hosts configured
after the outage will use LLMNR. When the DHCP server comes back online,
it is desirable that unconfigured hosts obtain their configuration from
it.
Alternatively, it is possible for the DNS configuration mechanism to
continue functioning while the configured DNS servers fail. In this
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
recommended:
Periodic retry
Unless unconfigured hosts periodically retry configuration, an
outage in the DNS configuration mechanism will result in hosts
continuing to use LLMNR even once the outage is repaired. Since
LLMNR only enables linklocal name resolution, this represents an
unnecessary degradation in capabilities. As a result, it is
recommended that hosts without a configured DNS server periodically
attempt to obtain DNS configuration. The recommended default retry
interval is 30 seconds.
DNS failover
For security reasons, by default LLMNR is not enabled for the
resolution of FQDNs where a DNS server has been configured. This
implies that where a DNS server has been configured, LLMNR will not
be used by default for resolution of FQDNs, even in the event that
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 20, line 7 skipping to change at page 20, line 14
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-11.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-12.txt>, and expires
February 22, 2003. February 22, 2003.
 End of changes. 

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