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

[Brian E Carpenter <[e-mail]>]

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 can easily configure my Windows box to default to *.local.
But why would I want to?

    Brian

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
> 


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