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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf