Margaret Wasserman writes ("Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard"):
> The .local doesn't come from either mDNS or LLMNR... The user types
> it and/or an application includes it in the domain name look-up. So,
> if the user tries to look up "twiki.local", what happens? As I
> understand it, one of three things will happen:
>
> (1) If the system implements mDNS, the .local domain is treated
> specially, so this just goes out as a link-local request.
This is fine and as intended, of course.
> (2) If the system implements LLMNR, there will first be a global DNS
> lookup for "twiki.local", which will fail. Then, a link-local name
> request will be tried.
This is not fine, as Peter Dambier's experience shows. Firstly, it
generates unwanted queries up towards the DNS root (apparently in
large numbers, too!). Secondly, if measures are taken to get rid of
that unwanted root server traffic, by having (for example) an ISP's
caching DNS proxies return 127.0.0.1 or some other answer that the
querier will accept, the querier breaks.
Why does the querier break ? Well precisely because of the namespace
confusion I was just talking about. The querier assumes - without any
kind of justification - that queries for .local (or whatever other
domain the LLMNR administrator has chosen) will always be happily
answered with NXDOMAIN by the `real' DNS as seen from the end system.
> But, given that choices (2) and (3) involve the same interaction with
> the DNS, I'm not sure how one can argue that LLMNR makes things any
> worse than things would be without it. Perhaps you could argue that
> mDNS makes things better, but that is only true for this one
> non-existent TLD -- all three systems would generate a bogus global
> DNS query if I did a DNS lookup for "isoc.frog".
LLMNR _insists_ on you picking _some_ part of the DNS space and then
abusing it this way.
Think broader than just the exact effect of the resolution protocol.
With any kind of resolution protocol - even with normal DNS - there
are decisions to be made about which names to configure in hosts.
Those names will then be used for DNS (or DNS-like) lookups.
It is true that all of these systems - full DNS, mDNS and LLMNR - will
generate bogus DNS queries if systems are configured with bogus names.
Part of the mDNS protocol is the expectation that you will configure
your hosts to expect certain services to be provided at names in
`.local'. If mDNS were an IETF protocol then the RFC would come with
an IANA action to allocate mDNS the `.local' TLD - and, de facto, the
deployment of mDNS has meant that any other use of `.local' is now
difficult or impossible. You may argue that this was wrong, but the
mDNS authors did try to get their very sensible protocol put through
the IETF process and were told where to go. That's a failure of the
whole IETF, not just of the mDNS authors.
But only LLMNR _encourages_ (maybe even requires) you to configure
your systems with bogus names ! LLMNR hosts will _always_ generate
bogus DNS queries for these nonexistent names, and they will always
break if and when the real DNS suddenly provides data for those names
(either because the relevant nameserver operators are fed up of the
query traffic, or because in their wisdom - the namespace belongs to
them after all - they've decided to publish some data they themselves
want to use).
The bogosity of the names in LLMNR is quite different from the problem
(if there is a problem) with mDNS. With mDNS the functionality - or
the brokenness, if you prefer to look at it like that - is confined to
.local. It neither affects mDNS hosts' view of `normal' internet DNS
names, nor generates queries to normal internet DNS servers.
Ian.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf