Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR) ' to Proposed Standard

[Ned Freed <[e-mail]>]

> On 8/30/2005 2:18 PM, Stuart Cheshire wrote:

> > Well, in case 1 (mDNS), no, because it won't return a useful result, so
> > why keep doing it?
> >
> > In case 3 (conventional DNS), no, because it won't return a useful
> > result, so why keep doing it?
> >
> > In case 2 (LLMNR) the answer is yes, all the time, if you chose to call
> > your printer "isoc.frog", which LLMNR allows and encourages.

> What part of the specification requires LLMNR names to be processed
> through Internet DNS?

Section 2 states:

  An LLMNR sender may send a request for any name.  However, by
  default, LLMNR requests SHOULD be sent only when one of the following
  conditions are met:

  [1] No manual or automatic DNS configuration has been performed.
      If DNS server address(es) have been configured, then LLMNR
      SHOULD NOT be used as the primary name resolution mechanism,
      although it MAY be used as a secondary name resolution
      mechanism.  For dual stack hosts configured with DNS server
      address(es) for one protocol but not another, this implies
      that DNS queries SHOULD be sent over the protocol configured
      with a DNS server, prior to sending LLMNR queries.

  [2] All attempts to resolve the name via DNS on all interfaces
      have failed after exhausting the searchlist.  This can occur
      because DNS servers did not respond, or because they
      responded to DNS queries with RCODE=3 (Authoritative Name
      Error) or RCODE=0, and an empty answer section.  A dual
      stack host SHOULD attempt to reach DNS servers over all
      protocols on which DNS server address(es) are configured,
      prior to use of LLMNR.

In other words, if I have a name to resolve and I have both LLMNR and DNS
access, I'm supposed to try DNS first, and if that fails, then LLMNR.

> There are lots of similar-looking naming services out there (DNS, NIS,
> NetBIOS, AppleTalk, ...), and there is a significant amount of experience
> in keeping the names and resolution paths separate.

My experience has been that people generally do a lousy job of keeping
these things separate.

> Just because an LLMNR
> name "looks like" a DNS name doesn't make it one (just as an AppleTalk
> name that "looks like" a DNS name doesn't make it one).

THat would be true if LLMNR was indeed designed to offer a disjoint service.
But it isn't. Rather, it appears to be designed to be able to offer both a
disjoint service as well as a sort of backup service to DNS. And that's the
source of the trouble.

Another way of fixing the overlapping namespace problem would be to  require
LLMNR to be truly disjoint from the DNS: Remove all this stuff about using the
DNS as the primary service when available. However, my guess is that such a
service would not be terribly interesting, and that much of the supposed value
opf LLMNR comes from its lashup to the DNS.

				Ned

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf