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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1-sep-2005, at 13:34, Keith Moore wrote:

No. Or at least, the point of having something like a link-local name resolution protocol is that you can use the same interfaces to look up the local names when using the link-local protocol, as you do when looking up real DNS names when using the real DNS protocol. That way all the existing applications work and don't need to be changed.

False.  That way, you break various kinds of applications because you
violate assumptions that those applications quite reasonably made about
the APIs and services they were using, and you flood the DNS with
useless queries.  This is the same kind of problem that resulted from
introduction of NAT.

I find this a very curious position. Basically you're saying that the namespace for local lookups and global lookups must be so separate, that they can't even use the same code paths. I really don't see that having a clear separation between the two that is PART of the combined namespace (i.e., one or more global TLDs, one (or more?) local TLDs) would be insufficient here.

Otherwise you would be suggesting building an entirely new protocol and application stack, with changes to every application to support the link-local scheme, which is obviously out of the question.

Actually, it's the only approach that makes any sense. The idea that you can substitute a name service that works differently from what applications expect, without breaking some of those applications, is extremely naive.

Which reasonable expectation are you talking about?

I'm opposed to the concept of confusing resolution of local names
with resolution of DNS names.

[...]

I favor adoption of LLMNR because in a world of disconnected and intermittently connected networks there's a need for applications to still be able to work - and being able to "work" includes being able to lookup the same DNS names that the applications would normally use in a connected network.

I don't understand how you can be in favor of LLMNR while at the same time being opposed to confusion between local and global ("DNS") names. In theory, I suppose it's possible that the information available over LLMNR and the information available from the DNS are 100% consistent. In practice, this is of course completely impossible, and unless my memory is going faster than I thought, the draft doesn't even address this issue. So effectively, there will be a local namespace available over LLMNR and a global one available from the DNS, with an overlap somewhere betwee 0 and 1. An application then has no way to know which namespace provided a certain result.

I favor discouraging use of mDNS

Let's be clear that this is a completely separate issue from whether the LLMNR protocol is the right answer to the right question.

because I believe it harms interoperability of Internet applications and operation of the DNS.

How, exactly?

I would like to see a solution for the lookup of local names that did not have these characteristics. If that solution can be derived from the mDNS protocol, that's fine with me, but it shouldn't overload the DNS lookup APIs nor should it borrow the DNS name syntax.

That seems unnecessarily conservative. Even if you find the "separate TLD" solution unacceptable, local names can still be put in a DNS class of their own. Classes were invented for exactly this reason, if memory serves.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]