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