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

[Peter Dambier <[e-mail]>]

Brian E Carpenter wrote:
> Peter,
> 
> I'm afraid I don't understand. As far as I can understand,
> mDNS uses the .local pseudo-domain and LLMNR does not.
> So how can LLMNR be blamed for bogus queries for *.local?

I cannot garantie it was LLMNR. I was told these are windows boxes
using the default enabled LLMNR and it defaults to ".local". I know
that newer windows boxes do have LLMNR but it is not normally used.
Nevertheless it comes up.

MAC systems with mDNS may use ".local" too but they never ask for
".local" via DNS. They stay with mDNS on the direct link.

It was only windows boxes who complained when we returned 127.0.0.1
for *.local

> 
> I can easily configure my Windows box to default to *.local.
> But why would I want to?
> 
>    Brian

The problem is that windows users plug their box in and cry if it does
not work. They dont know how to configure or why.

Well, if you do not use ".local" on your box why not try ".com" ?
It might be fun. :)

> 
> Peter Dambier wrote:
> 
>> 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