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 <cheshire(_at_)apple(_dot_)com>
* Wizard Without Portfolio, Apple Computer, Inc.
* www.stuartcheshire.org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf