Re: LLMNR Issue 58: DNS server usage of LLMNR

[Bernard Aboba <aboba@internaut.com>]

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

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.


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