> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf