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

[Keith Moore <moore at cs.utk.edu>]

> > The whole idea that local names should look like DNS names and be 
> > queried through the same APIs and user interfaces seems, well, 
> > wrong (or dubious at best), and needs serious study for the 
> > implications of applications using those APIs and the impact of 
> > such names on DNS, no?
>
>
> 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.

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

> So what you're saying is that you're opposed to whole concept of 
> link-local name resolution.

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

> And that therefore you favour LLMNR because it doesn't (in your view)
>  provide it !

LLMNR isn't a competitor to mDNS.  They attempt to address different 
problems.

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 favor discouraging use of mDNS because I believe it harms 
interoperability of Internet applications and operation of the DNS.  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.

> Of course you are wrong on this last point - LLMNR will be deployed
> behind the same APIs currently used to do real DNS lookups.

LLMNR doesn't provide lookups for "local names" - it provides a local
service that can be used to query for attributes of DNS names.


> > IMO, local names and a lookup service for local names would be 
> > extremely useful, but neither the names nor the query interface 
> > should look much like DNS - the names should look different because
> >  otherwise there's too much potential for confusion with DNS names,
> >  and the query service should look different because local name 
> > lookup service probably can't make the same kinds of consistency or
> >  stability assurances that DNS does.
>
>
> To say that, is to say that work on LLMNR should never have been 
> started.  There is no demand for a local name resolution protocol 
> which doesn't present a DNS API to applications.

You appear to be confusing "a protocol for resolving names locally" with 
"a protocol for resolving local names".  They don't have to be the same 
thing.

> You may well say that the whole concept of local name resolution, if
>  it must be presented to applications behind a DNS API, is a bad idea
>  and I have some sympathy with that view - but that's no argument for
>  LLMNR against mDNS !
>
> Stuart seems to be claiming that the people who first told him to 
> take is mDNS away from the IETF, and LLMNR's authors, have that view 
> - and that LLMNR is the result of those people producing a protocol 
> which is intended to look enough like mDNS to fool people but is 
> deliberately _not_ intended to do any of the things that mDNS is good
>  for !

LLMNR _looks like_ mDNS because both were intended for looking up names 
on a disconnected network, and because both were based on DNS.  That 
doesn't mean LLMNR _is trying to solve the same problem_ as mDNS.

Keith


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf