Christian Huitema writes ("RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard"):
> A key technical difference between LLMNR and the initial MDNS proposal
> is precisely that LLMNR has no concept of a ".local" top level domain.
While that is true, the next statement:
> Usage of LLMNR does not promote queries to this zone.
is not. LLMNR _requires_ the use of names which do not resolve in the
global DNS, and does a global DNS query for each lookup. Although
LLMNR doesn't suggest the use of `.local', given that many people
don't have a suitable domain to use, they'll use `.local' or something
else.
> This is indeed a key difference between LLMNR and MDNS. MDNS assumes
> that there is a special zone for local names, which would be linked to
> the topology. LLMNR assumes that names are independent of the topology,
> that a host called "foo.example.net" retains the same name as it move to
> different locations. There were ample debates of this point in the
> working group, and the decisions to "not creating special names" and
> "not linking names to topology" do reflect WG consensus.
Even if that is so, this posistion doesn't seem to reflect IETF
consensus.
It is nonsense to say that a `link-local multicast name resolution
protocol' provides DNS data which is not linked to the topology !
To say that the _names_ are not linked to the topology is to miss the
point and thus to mislead.
Given that the _answers_ depend on the topology, wouldn't it be a good
idea to be able to indicate that this topology-dependent behaviour is
- or is not - desired ?
LLMNR only provides that switch - turning on and off topology-
dependent behaviour - on a per-host basis. mDNS provides it on a
per-lookup basis in a nice easy-to-configure way: specify names in
.local and get topology-dependent answers; specify other names and get
consistent answers.
Ian.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf