Ian Jackson wrote:
Brian E Carpenter writes ("Re: Last Call: 'Linklocal Multicast Name
Resolution (LLMNR)' to Proposed Standard"):
Ian Jackson wrote:
Sorry to be pejorative, but as a DNS implementor[1] I'm amazed to find
senior IETF/IESG people seriously contemplating the kind of namespace
confusion which is fundamental in the LLMNR protocol design.
Can you spell that out please? Since it uses a different port number,
where does the confusion occur?
The confusion occurs on the root servers.
I dont really know if it was some LLMNR enabled windows machine, but
they definitely asked DNS first and on port 53. If we supply a dummy
zone like we do for localhost then those boxes do break.
What does the port number have to do with it ? That's an
implementation detail (from the point of view of this complaint; many
other complaints might well be about these kind of details).
The LLMNR model supposes that when an application asks for data of a
certain type associated with a certain name (ie, when the application
thinks it's asking for a DNS query) answers may come from either the
real DNS system or, even if the real DNS is authoritative for the
relevant name but denies that it exists, from LLMNR.
You name it: The implementation asks DNS for garbadge.local and if we
say 127.0.0.1 then windows breaks.
If we dont supply the krutch then 25% of our root server traffic is
for .local because they repeat their question again and again on all
13 if the root servers.
See draft-ietf-dnsext-mdns-42 s2 bullet point [2].
It is not true that separating LLMNR out on a different port, and
introducing other incompatibilities, prevents confusion between LLMNR
and the real DNS. Applications will still see a bizarre mix of real
and LLMNR data.
On the other hand, mDNS has a much better scheme: the mDNS
specification defines the tree under `.local' for mDNS use. Names in
.local are looked up with mDNS and names elsewhere via the real DNS.
This means that applications always either see the data intended for
them, or (transient) failure if the relevant mechanism isn't
available.
Stuart Cheshire makes IMO a very cogent argument in
<200508251931.j7PJV7aR006028 at relay4.apple.com>, where he says:
] What's weird about LLMNR is that it blurs what's global and what's
local.
] With LLMNR you can call your television "tv.ietf.org" if you want,
and as
] long as the IETF's name server returns NXDOMAIN (which it does today)
] then a LLMNR-compliant host will fail over to local multicast and
resolve
] that name to your television's address. This sends a very strange
message
] to end users -- it suggests they can use any name they want in any
domain
] they want without having to communicate with any registry. It also
means
] that every failed DNS query will result in a LLMNR multicast on the
local
] network, and (worse) every intentional LLMNR query needs to be
preceded
] by a failed DNS query to some unsuspecting DNS server somewhere.
] ] mDNS says that "local" is a free-for-all playground where anyone
can use
] any name and no one has any more right to a particular name than
anyone
] else. LLMNR didn't want to do that, but what they've effectively
ended up
] doing instead is saying that the root of the DNS namespace (and
] everything below it) is a free-for-all playground where anyone can use
] any name they want.
In addition, mDNS's limitation to `.local' means that deliberate
additional incompatibilities to avoid cache pollution in the real DNS
is not necessary; since mDNS is only used for names in `.local',
normal precuations against unsolicited DNS replies will prevent the
main DNS namespace being polluted with mDNS data.
If we are to so strongly fear pollution, mDNS's wide deployment ought
to provide some evidence for this from operational experience ! Where
is that evidence ?
mDNS is mostly free of bugs. The dont ask DNS for garbage.local . That is
why we dont see them.
Regards,
Peter Dambier
