Subject: Another shot at LLMNR Issue 38: DNS Proxy Undefined

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 May 2003 11:48:54 -0700 (PDT)

A little background on why IMO some additional text is required. The issue
is that there are a number of potential IPv6 DNS configuration mechanisms,
and not all of them guarantee availability of local name resolution. For
example, if an anycast DNS server address is configured, but there is no
DNS server listening on that address, then LLMNR queries will be
restricted (only unqualified names or names in the default domain), even
though this situation is not very different from the case in which no DNS
server is configured.

However if DHCPv6 is used to configure the DNS server, then it is more
likely that the DNS server actually exists.

Also, on a home network it is most likely that dynamic DNS will be
supported via DHCP/DDNS update, not client update.  This would imply a
need for DHCPv6 support.

In Section 1, Change text to:

"Propagation of LLMNR packets on the local link is considered sufficient
to enable name resolution in small networks. The assumption is that if
a network has a home gateway, then the network has DNS and DHCP servers.
If a DHCPv4 server is available, as well as a DNS server authoritative
for the A RRs of local hosts which also supports dynamic DNS, it is
possible to support resolution of local host names over IPv4 without
LLMNR.

For small IPv6 networks, if a DHCPv6 server is available, as well as a
DNS server authoritative for the AAAA RRs of local hosts which also
supports dynamic DNS, it is possible to support resolution of local host
names over IPv6 as well as IPv4 without LLMNR."
In Section 3.2, change text to:

"LLMNR usage MAY be configured manually or automatically on a per
interface basis. By default, LLMNR responders SHOULD be enabled on all
interfaces, at all times.

Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
possible for a dual stack host to be configured with the address of a
DNS server over IPv4, while remaining unconfigured with a DNS server
suitable for use over IPv6. In these situations, a dual stack host will
send AAAA queries to the configured DNS server over IPv4.

However, an IPv6-only host unconfigured with a DNS server suitable for
use over IPv6 will be unable to resolve names using DNS. Automatic IPv6
DNS configuration mechanisms (such as [DHCPv6DNS] and [DNSDisc]) are not
yet widely deployed, and not all DNS servers support IPv6. Therefore
lack of IPv6 DNS configuration may be a common problem in the short
term, and LLMNR may prove useful in enabling linklocal name resolution
over IPv6.

For example, a DHCPv4 server may be available but not a DHCPv6 server
[DHCPv6DNS]. As a result, IPv6-only hosts would not be configured with a
DNS server. Where a DNS server is configured, but there is either no
DNS server authoritative for the names of hosts on the local network or
the authoritative DNS server does not support dynamic client update over
IPv6 or DHCPv6-based dynamic update, then hosts on the home network will
not be able to dynamically register or resolve the names of local IPv6
hosts. For example, if the configured DNS server responds to AAAA RR
queries sent over IPv4 or IPv6 with an authoritative name error
(RCODE=3), then it will not be possible to resolve the names of
IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for
local name resolution.

Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
configure LLMNR on an interface. The LLMNR Enable Option, described in
[LLMNREnable], can be used to explicitly enable or disable use of LLMNR
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
which various name resolution mechanisms should be used can be specified
using the Name Service Search Option for DHCP [RFC2937]."

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>