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

[Iljitsch van Beijnum <[e-mail]>]

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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf