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