Subject: Proposed Resolution to LLMNR Issue #3

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Mar 2003 09:39:31 -0800 (PST)

Issue 3: Use of LLMNR?
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: March 7, 2003
Reference:
Document: LLMNR-13
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
It seems unwise to send an LLMNR query for any name and RR if the DNS
server does not respond or
responds with NXRRSET.

In practice, no response or NXRRSET will occur quite often, even if the
DNS server is functioning.
This is was shown by Jung, et al. "DNS Performance and Effectiveness
of Caching", IEEE/ACM Transactions on Networking, October 2002, Volume 10,
Number 5, pp. 589-603.

For example, in the study 23 percent of all client lookups were not
answered in an MIT data set
collected in December 2000. 13 percent of lookups result in an answer that
indicates an error.
Most of these errors indicate that the desired name does not exist
(NXDOMAIN). Inverse lookups
often cause errors, as do NS records that point to nonexistent servers.

As a result, it seems unwise to fallback to an LLMNR query for
any query, just because the DNS server doesn't answer, or answers
with NXRRSET. My proposal is not to fallback to LLMNR in the following
cases:

a. A PTR RR query for an address that does not exist on the local link
(either a LL address
or a routable address on the local link). In this case, the query won't be
resolved via LLMNR
so there is no point in sending it. So PTR RR queries should only be sent
when the address is a local prefix.

b. Any RR query for a name that has a "." and is not in the default
domain. In this case
we aren't talking about a local machine name, or even a hostname that is
reasonably familiar.
It could be a name of an arbitrary host on the Internet. We don't want to
send LLMNR queries
for those names, since LLMNR Responses are so easily spoofed. So only
fallback to LLMNR
if the name has no "." or is in the default domain.

Change Section 3 to the following:

"3. Usage model

LLMNR is a peer-to-peer name resolution protocol that is not intended as
a replacement for DNS. By default, LLMNR requests SHOULD be sent only
when no manual or automatic DNS configuration has been performed, when
DNS servers do not respond, or when they respond to a query with an
RCODE set to NXRRSET.

As noted in [DNSPerf], even when DNS servers are configured, a
significant fraction of DNS queries do not receive a response, or result
in a negative responses due to missing inverse mappings or NS records
that point to nonexistent or inappropriate hosts. Given this, support
for LLMNR as a secondary name resolution mechanism has the potential to
result in a large number of inappropriate queries without the following
additional restrictions:

[1] Prior to falling back to LLMNR, a DNS query SHOULD be
retransmitted at least once. As noted in [DNSPerf] additional
retransmissions do not significantly increase the probability
of receiving a response.

[2] A sender SHOULD send LLMNR queries only for names that are
either unqualified or exist within the default domain.

[3] A sender SHOULD NOT send LLMNR queries for PTR RRs that
correspond to addresses known not to exist on the local link.
Since legitimate responses to LLMNR queries can only come from
hosts on the local link, an LLMNR query for an address not
on the local link cannot elicit a legitimate response.

[4] A responder with both linklocal and routable addresses
SHOULD respond only to LLMNR queries for A/AAAA RRs for
the routable address. This encourages use of the routable
address for establishment of new connections."

--
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: "M. T. Hollinger" <[email-masked]>
Date: Tue, 18 Mar 2003 13:35:52 -0500

> My proposal is not to fallback to LLMNR in the following
> cases:
>

I support this proposal.

Although it is true (as was just mentioned at the San Francisco meeting)
that there may be multiple subnets or IPv6 prefixes on the same link, some
of which are unknown to the host whose PTR query to any DNS servers has just
failed or timed out, an LLMNR query for an apparantly non-local address will
almost always fail.

Let's not clutter the wire with such queries.  The case of multiple
configured prefixes on a link without a DNS server is unusual to begin with.
Having some of those prefixes absent from a host's routing table yet still
reachable is even more unusual.  One could argue as to whether such an IPv6
configuration, where only the router knows what prefixes are local and can
forward local packets back onto the same link, is properly in scope for
LLMNR.  (If the responder doesn't know that the querying host's prefix is
on-link either, will the response still have TTL 255 by the time the router
forwards it back onto the same link?)

For security and operational reasons, it's nice to prevent LLMNR from
flooding large, managed networks with queries every time the local DNS
server becomes unreachable.  If we can protect against such flooding,
without keeping the dentist's office scenario from working well, we should
do so.  I don't think my dentist has multiple unadvertised global prefixes
on his router, and if he does, he probably has a DNS server configured too.

             - Mark