Subject: RE: Proposed Resolution to LLMNR Issue 21: PTR queries

From: <[email-masked]>
Date: Thu, 3 Apr 2003 11:58:17 +0300

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Bernard,

> From: ext Bernard Aboba [mailto:[email-masked]]

> > Note that having a route to a destination is not the same thing as
> > knowing that the destination is on-link.
> >
> > > Perhaps the right thing to do here is to say that 
> "addresses that are
> > > 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.
> 
> Can it prefer responses that correspond to addresses it has 
> routes for?

Yes, that would be my proposal.

> > By host [1] do you mean the LLMNR responder of host [1] or the
> > application running on host [1]?
> 
> I mean the LLMNR responder.
> 
> > 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.
> 
> I think this may be good enough. If a response doesn't have a
> corresponding route then it can be ignored.

Agreed.

> > In IPv6 the DNS resolver is already required to prefer reachable
> > addresses as part of default address selection [RFC3484].
> 
> That seems like a reasonable guideline to adopt here, too.
> 
> > 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.
> 
> 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.

Well, in general one should be able to rely on one's local recursive DNS server to return an error when it times out on a query. Especially in IETF meetings. :)

> Perhaps the right thing is not to allow PTR RR queries in 
> LLMNR at all?

Unfortunately this would break a number of applications that do reverse queries. I'd rather err on the side that doesn't break applications even if there is a small performance impact: if in doubt, do the PTR query. I.e., the LLMNR resolver should do the query if the host has a route for the address in question.

> Couldn't ICMP node information queries be a more appropriate 
> substitute?

Err, I'm not exactly sure how node information queries relate to LLMNR. As far as I'm concerned, it is a completely separate name/address resolution protocol which may or may not be used by IPv6 nodes in the future. I don't think it's wise to create a dependency between the LLMNR specification and node information queries. (And it won't solve the issue of PTR queries for IPv4 addresses).

	MikaL

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