>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@xxxxxxxxx> * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf