Subject: Re: LLMNR Issue 58: DNS server usage of LLMNR

From: Masataka Ohta <[email-masked]>
Date: Sun, 21 Dec 2003 17:28:09 +0900

Christian;

>>DNS servers are prohibited from responding to LLMNR queries except
> 
> with
> 
>>RRs they own. However, DNS servers are not prohibited from sending
>>LLMNR queries in order to resolve DNS queries. This seems like a very
> 
> bad
> 
>>idea.
>>
>>Add the following sentence to Section 2.2:
>>
>>"DNS servers also MUST NOT send LLMNR queries in order to resolve DNS
>>queries."
> 
> 
> I am not sure this is such a "very bad idea". Take the example of an
> IPv6 home network. The ISP explicitly delegates an IPv6 prefix to the
> home router. The router advertises this prefix. Hosts configure
> addresses from this prefix. Since there is explicit prefix delegation to
> the router, we may expect the router to also receive delegation of the
> reverse lookup tree.

Wrong.

We expect that there are multiple nameservers of a zone at
multiple locations.

We may expect that a router of a link corresponding to a PTR
act as the primary nameserver of a zone containg the PTR.
However, in this case, DHCP is the way for the router
maintain information of the reverse zone.

LLMNR MUST NOT be queried from DNS servers.

> This is just one scenario. I am convinced there may be others.

Your senario merely is an example that stateless autoconfiguration
and LLMNR is useless to the Internet. Unlike stateless
autoconfiguration, however, LLMNR may be useful to an isolated
IP network with a single link (with no routers).

							Masataka Ohta

--
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/>

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 21 Dec 2003 08:05:29 -0800 (PST)

> reverse lookup tree. In these conditions, it makes a lot of sense to use
> LLMNR to fulfill a DNS PTR request. If you look at it, the chain of
> trust is exactly the same as what we have today in IPv4, when a router
> fulfills a PTR request using whatever name the host asserted in a DHCP
> request.

The drafts currently discusses two scenarios:

a. Today with IPv4, home gateways typically act as both a DHCPv4 server
and DNS server, supporting dynamic DNS (via DHCP).  This allows them to answer
both A and PTR queries for the names of hosts on the local network.  Such
routers typically answer AAAA queries for local hosts they don't know with
RCODE=3 or, for hosts they do know, but for which there is no AAAA RR, with
RCODE=0 and no RRs.  This causes the querying host to send an LLMNR query
for the AAAA RR or corresponding PTR.

b. If the router supports IPv6, as well as acting as a DNS server, and
supports DHCPv6Lite, then it would also be able to support dynamic DNS
(via DHCPv6lite) and could answer AAAA and PTR queries without need of LLMNR.

Given that both a) and b) scenarios already work, I'm looking to come up
with a scenario in which DNS server usage of LLMNR queries helps.

One possible scenario would be where only some of the local IPv6 hosts are
LLMNR capable and support DHCPv6lite.  Hosts that do not support DHCPv6lite
might not be able to register their AAAA and corresponding PTR RRs with
the DNS server authoritative for the names of local hosts (e.g. the router).
Other hosts might support DHCPv6 lite, but might not be able to act as
either an LLMNR sender or responder.

In such a situation, an LLMNR-incapable host might send a DNS query for a
AAAA or PTR RR of a host that didn't support DHCPv6lite, but could act as
an LLMNR responder.  The DNS server would respond with RCODE=3, at which
point the querier would have no recourse, since it doesn't support LLMNR.
However, if the DNS server sent an LLMNR query for the name, it would get
an answer which it could relay back to the querier.

Is this a likely scenario? It seems quite likely to me that we will have
hosts that support DHCPv6lite but not LLMNR, but I'm not sure about hosts
that support LLMNR but not DHCPv6lite.  You need to posit both types of
hosts for scenario c) to apply.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 22 Dec 2003 05:23:24 +0900

Bernard Aboba;

> an answer which it could relay back to the querier.

Your hidden assumption is that all the related hosts are on a
single link or that all the hosts on a link belong to a local
forward domain served by nameservers, all of which is on the
link.

Otherwise, we have no idea on where to ask the forward query,
even if you say LLMNR.

Given so much confusion on usefulness of LLMNR and an attempt
to mandate LLMNR for IP over BT, I'd like to suggest to
abandone LLMNR entirely, or, at least, add explicite explanation
stating its narrow scope, such as:

	LLMNR is expected to be useful for nodes on an isolated
	IP network with a single link, but not beyond that. LLMNR 
	MUST NOT be used by nodes connected to the Internet nor
	an isolated IP network with multiple links.

							Masataka Ohta

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 21 Dec 2003 13:49:22 -0800 (PST)

> 	an isolated IP network with multiple links.

Since LLMNR queries and responses are sent on the local link with TTL=1,
they will not propagate beyond the local link.  Therefore I would agree
that Link Local Name Resolution Protocol (LLMNR) should be restricted to
link local usage.

However, I do not think that the rest of this recommendation can be put
into practice.

Whether the network is "isolated" or "connected to the Internet" is
very hard to determine.  A host may be able to reach some Internet
prefixes, and not be able to reach others.  Similarly, the radius of the
network may also be hard to determine.

Furthermore, I would argue that the disction between "isolated" and
"connected" networks is not really relevant to deciding whether to use a
secondary name resolution protocol.  Issues that are relevant are:

a.  whether the primary protocol (DNS) can provide an answer or not.
b.  whether the rules governing usage of the secondary protocol are
    conservative enough to avoid unnecessary use of a secondary protocol
    when the primary protocol could be used successfully.

LLMNR use is restricted to situations in which DNS servers are not
configured, where DNS servers do not respond or where
DNS responds with RCODE=3 or RCODE=0 and no RRs.

However, the host is not obliged to dig deeper to  understand *why* these
situations occur, because there may be no easy way for a host to determine
*why* a DNS server did not respond to a query, or *why* the host was not
configured with a DNS server.

The only real issue is whether, based on these criteria, it is appropriate
for a host to conclude that it is unlikely to successfully resolve the
name using the primary name resolution protocol (DNS).

Whether that conclusion is justified depends in part on resolver behavior.
Hosts implementing RFC 1536 are advised to support DNS resolver failover,
to measure DNS RTTs, and to avoid unnecessary RCODE=3 errors.  All of
these fixes make it more likely that a DNS server, if available, will
respond to the query so that LLMNR is not needed.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 22 Dec 2003 06:51:31 +0900

Bernard Aboba;

> network may also be hard to determine.

It is trivially easy for an administrator of the network.

> DNS responds with RCODE=3 or RCODE=0 and no RRs.

The problem is that, LLMNR is still not useful unless the network
is an isolated single link that LLMNR should never be attempted
otherwise.

> situations occur,

Agreed, but it is not my point.

Given the difficulty you mentioned, I think it is also necessary
to request that LLMNR functionality is, by default, turned off.

						Masataka Ohta