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

[Stuart Cheshire <[e-mail]>]

>Stuart,
>
>do you have a published specification of Apple's mDNS that you can point 
>people at, so that people can understand what functionality mDNS has that 
>LLMNR does not?

Certainly.

The framework document, describing what we need and why we need it, is:

 Requirements for a Protocol to Replace AppleTalk NBP
 <http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-nbp-04.txt>
 (32 pages)


The two specification documents that, when used together, meet those 
requirements are:

 Multicast DNS
 
<http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-multicastdns-05.
txt>
 (45 pages)

 DNS-Based Service Discovery
 <http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-dns-sd-03.txt>
 (32 pages)


Although the documents are complementary, we made an effort to keep a 
clean separation between the encoding of service discovery using DNS 
records (DNS-SD), and the transport of those records using multicast 
(mDNS). This makes it possible and fruitful to use one without the other, 
for example, wide-area DNS-SD service discovery performed via standard 
unicast DNS queries:

 <http://www.dns-sd.org/ClientSetup.html>
 <http://www.dns-sd.org/ServerSetup.html>

Although the documents are separate, much of what's in mDNS is there to 
make DNS-SD work better. Some examples:

* Because a given device may advertise many services, or be looking for 
many services, we allow several questions to be packed into a single 
query packet for efficiency. Semantically, a single query packet 
containing multiple questions is treated by receivers as exactly the same 
as multiple packets containing one question each. The only difference is 
that it's more efficient on the wire. (In addition to saving header 
overhead, where the queries are similar, DNS name compression can come 
into play.)

* Because of packet loss, a question may need to be retransmitted more 
than once. Because of the nature of service discovery, a single question 
may elicit a hundred responses, not just one. How do we reconcile these 
two aspects? Every time we retransmit a query, we don't want to get 
bombed with the same hundred responses. In fact, if the flood of packets 
caused some slow device's response to get lost the first time, it's 
likely to get lost in each subsequent flood of packets too. The solution 
we worked out for this is to use the answer section of the query to list 
the already-known answers. This suppresses redundant responses from the 
hundred devices we've already heard from, and gives the slow one a chance 
to be heard.

One property that a lot of these extensions have in common is that they 
can be safely omitted if all you want to do is look up host names. A 
client doesn't have to put anything in the answer section of a query, if 
the implementer chooses not to. A responder doesn't have to consult the 
answer section of a query, if the implementer chooses not to. This might 
mean lost opportunities to suppress unnecessary responses, but you could 
argue that for simple host name lookup you can live without that. It's 
very easy to make a simplified compatible subset of mDNS.

Putting service discovery requirements aside for a moment, the other big 
difference between mDNS and LLMNR is that mDNS facilitates local-scoped 
names, analogous to RFC 1918 addresses. LLMNR lets you look up a host 
name without a DNS server, but it pre-supposes that you HAVE a globally 
unique fully-qualified host name in the first place. In contrast, mDNS 
says you can call your television "tv.local" if you want, and you don't 
need to pay anyone for that name, or ask permission, or know how to 
register it in some global database, but at the same time the name has 
only local significance so don't expect it to be usable worldwide.

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.

Stuart Cheshire <[e-mail]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


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