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

[Ian Jackson <[e-mail]>]

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?

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.

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 ?

Ian.

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