Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier <[e-mail]>]

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
> <[e-mail]>, 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

-- 
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
[phone] (Telekom)
[phone] (O2 Genion)
[phone] (VoIP: sipgate.de)
[phone] (VoIP: freeworldialup.com)
mail: [e-mail]
http://iason.site.voila.fr
http://www.kokoom.com/iason


_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf