Subject: Proposed Resolution to LLMNR Issue 21: PTR queries

From: Bernard Aboba <[email-masked]>
Date: Mon, 31 Mar 2003 21:33:15 -0800 (PST)

Given the discussion at IETF 56 and the currently proposed resolutions to
Issue 28 and 29, I would like to propose that sending of LLMNR queries for
PTR RRs that represent "off link" addresses should be discouraged. The
proposed resolution is given below. Comments?

Issue 21: PTR queries
Submitter: Markku Savela
Submitter email address: [email-masked]
Date first submitted: November 4, 2002
Reference: <[email-masked]>
Document: LLMNR-12
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
I assume that if you end up doing a address (fe80::1) to name query
for IPv6, you end up sending a query to IPv6 multicast address
generated from the hash of

"1.0.0. ... 0.0.8.e.f.ip6.int"

and because the hash is taken from the first label, this will be MD5
from "1"? (basically only 16 different hashes are possible).

IPv4 side you have for example "1.2.254.169.in-addr.arpa".

Am I right assuming the "resolvers" on nodes have to deal also with
these for link local name resolution?

[BA] Yes, it is expected that senders will send PTR
queries, and that receivers will respond to them.
However, it probably doesn't make sense to send a
PTR query for an address that isn't on the local
link. Here's the proposed resolution:

Add the following text to Section 3:

"[3] A sender SHOULD only send LLMNR queries for PTR RRs that
are known to be "on link" as defined in Section 2.5."

[Erik Guttman and Erik Nordmark]:

The problem is that in practice a host may not know the
prefixes in use on a particular link. So this restriction
can't work in practice.

[Comment from Mark T. Hollinger <[email-masked]>]:

I think we are being too hasty to throw out this restriction. As I
metioned in my recent Namedroppers post, supporting your original proposal
for issue #3, I would like the fallback to LLMNR not to occur at all for
apparantly non-local prefixes.

If there is a prefix on your link that you don't know about via your
routing table, then I don't think LLMNR needs to handle inverse queries
for that zone. The target user for LLMNR probably won't have multiple
unadvertised global prefixes in the first place. Anybody sophisticated
enough to set that up will already have the address of a DNS server
configured.

Also, if you don't know about the other guy's prefix, he may not know
about yours either, in which case he'll get your multicast request but try
to send a unicast response via the router, which may decrement the TTL
when forwarding it back onto the same link. I'm not sure LLMNR will work
in this case (due to the TTL 255 check), but even if it works, I think a
configuration where hosts have to communicate (even only initially) via a
router is out-of-scope for LLMNR. Let traditional DNS handle that case; we
don't need LLMNR there.

[BA]
Back of the envelope calculations seem to indicate to me that
bogus PTR queries can be a significant problem in some cases. Measurements
show that a significant fraction of DNS queries are not answered, and this
is particularly true with PTR queries. So we can have a substantial amount
of bogus LLMNR PTR query traffic. I am particularly worried about wireless
networks with lots of people like at IETF 56. 5 queries a second from
3000 people would end up eating up a significant fraction of the total
bandwidth of an 802.11 network, particularly if there are lots of folks
who have to step down to lower rates (1,2,5 Mbps). So there is some reason
for concern.

In the discussion at IETF 56, there was concern that it might not be
possible for a host to know all the networks it was connected to. The
question then arises as to whether it is ok not to send a PTR query for
addresses on networks the host doesn't know about. It was pointed out that
if the host doesn't have a route for that address, then it will route the
packet to the gateway, which might not have a route for it either.

In view of the proposed resolution to Issue 28 and 29, it would
appear that it makes little sense to send queries for PTR RRs
that aren't "on link".

--
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: Mika Liljeberg <[email-masked]>
Date: 02 Apr 2003 00:06:04 +0300

Hi,

> proposed resolution is given below. Comments?

I have no objection to "should be discouraged". However, it should be
realized that on many operating systems this restriction may be very
difficult to implement in practise. Offhand I can't think of an easy way
for an application to check whether a particular address is "on link".

	MikaL

--

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 1 Apr 2003 16:24:51 -0800 (PST)

> for an application to check whether a particular address is "on link".

In practice, I think an on-link address is one which corresponds to
link-scope address or an address corresponding to a prefix in the routing
table mapped to an interface.

---

From: Mika Liljeberg <[email-masked]>
Date: 02 Apr 2003 07:55:12 +0300

> table mapped to an interface.

My point is that the latter case is hard for an application to check,
unless the kernel provides a syscall for it. Or is LLMNR supposed to
read the routing information from the kernel and replicate the next hop
selection code in user space?

	MikaL

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Apr 2003 21:05:13 -0800 (PST)

> selection code in user space?

In practice, I don't think this needs to be required; the issue is about
the networks directly reachable from interfaces receiving or sending
queries, not about replicating next hop selection code.

Perhaps looking at some examples may help make sense of this. Let us
assume that Myhost is attached to two networks, A and B, and that it is
talking to host [1] on net A and host [2] on net B.

net B ----------  ---------- net A
       |      |    |     |
      [2]    [myhost]   [1]

Host [1] sends an LLMNR A/AAAA RR query for "myhost". Should myhost
respond with A/AAAA RRs for addresses on net B? This would be bad
if host [1] only has a LL address, since it would not be able to
reach net B. So I think it makes sense for myhost to only respond
with addresses on the interface from which the query came.

So far so good. However, the question is "what if myhost does the wrong
thing?" This is harder because host [1] may not have network B in its
routing table. It therefore will not know how to reach network B. Since
the point of LLMNR is to allow link-local name resolution, if host [1]
doesn't know how to reach net B on the local link then RRs containing that
address are not useful.

Perhaps the right thing to do here is to say that "addresses that are
reachable on the local link are preferred" by host [1]. That way, if
myhost only returned an address on network B, host [1] can try to connect
to that, possibly without success. But since there is no choice, what harm
can it do?

Another question is what happens if myhost attempts to connect to host
[1], using a source address on net B. In this case host [1] may attempt to
send a PTR RR query using LLMNR, for the address on net B. In this case,
myhost might respond to the query with the name myhost which is valid
on the interface. No harm is done. However, one might argue that
host [1] should not send such a query, and that if received,
myhost should not respond to it.

---

From: Mika Liljeberg <[email-masked]>
Date: 03 Apr 2003 10:17:38 +0300

Bernard,

> queries, not about replicating next hop selection code.

It's true that the route search is constrained to a single interface but
this does not essentially simplify the next hop selection algorithm. A
full route search is still required to do on-link determination (unless
you make some severe assumptions about the kind of routes that can lead
to a specific physical interface).

> Perhaps looking at some examples may help make sense of this.

Ok. I think your example addresses a different case from the one
discussed in issue 21 (PTR queries), but let's look at the example
first.

>  Let us

Right. Issue 29 clarifies this. I agree with the proposed resolution.

> thing?"

I don't think the multihomed and broken [myhost] is a very common case
but otherwise I agree with what you say:

>  This is harder because host [1] may not have network B in its

Agreed. To weed out the unusable address, the LLMNR resolver on [1]
should somehow check whether there is a route to it. On many operating
systems you can do this by attempting to connect a UDP socket to the
destination address. If there is no route, the connect() syscall will
fail.

Note that having a route to a destination is not the same thing as
knowing that the destination is on-link.

> reachable on the local link are preferred" by host [1].

The LLMNR resolver doesn't *know* which addresses are on-link, so it
can't prefer them.

>  That way, if

By host [1] do you mean the LLMNR responder of host [1] or the
applicaiton running on host [1]?

The LLMNR resolver can, on many operating systems, check the existence
of a route (e.g. by doing a UDP connect() to the address). However, what
it *cannot* do (as far as I can see), is check whether the destination
address is on-link.

In IPv6 the DNS resolver is already required to prefer reachable
addresses as part of default address selection [RFC3484].

> [1], using a source address on net B.

The only way this can happen is if a) [myhost] is badly broken, or b)
[myhost] uses the Weak ES model [RFC1122] and the addresses in question
are not link-locals. [zeroconf] forbids Weak ES model for link-locals.

>  In this case host [1] may attempt to

The more realistic example, the one which I thought was being dicussed
in the context of issue 21, is the following:

Internet ----------  ---------- net A
          |      |    |     |
         [2]    [router]   [1]

Host [2] is not in the global DNS. It connects to host [1], which tries
to make a PTR query to DNS with the address of [2]. [1] receives no
response from DNS (whatever the reason) and falls back on LLMNR. LLMNR
naturally fails as well.

As you say, no harm is done, but it would nice to skip the unnecessary
LLMNR query. I agree with the intent. I just don't see a good way to
actually implement it.

	MikaL

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Apr 2003 23:22:42 -0800 (PST)

> The LLMNR resolver doesn't *know* which addresses are on-link, so it

Can it prefer responses that correspond to addresses it has routes for?

> application running on host [1]?

I mean the LLMNR responder.

> it *cannot* do (as far as I can see), is check whether the destination

I think this may be good enough. If a response doesn't have a
corresponding route then it can be ignored.

> addresses as part of default address selection [RFC3484].

That seems like a reasonable guideline to adopt here, too.

> LLMNR query. I agree with the intent. I just don't see a good way to

Yes. By your logic host [1] will have a route to [2] and so will send the
LLMNR query, even though it cannot succeed. My concern is that this will
happen very frequently and will needlessly consume bandwidth; on a
wireless network like IETF's this could have a significant (negative)
effect.

Perhaps the right thing is not to allow PTR RR queries in LLMNR at all?
Couldn't ICMP node information queries be a more appropriate substitute?