Subject: Re: LLMNR is done

From: Bernard Aboba <[email-masked]>
Date: Wed, 28 Jan 2004 13:05:37 -0800 (PST)

LLMNR was designed to handle situations in which hosts are highly
mobile, and to be extensible to use in larger scopes, if the initial
deployments prove successful.  These situations do not lend themselves
to multicast responses.

For a highly mobile situation, with a DNS TTL close to zero, multicast
responses are not useful to any host other than the one sending the
original query, yet they need to be processed by all hosts for marginal
benefit.

Multicast responses also do not scale beyond link-local scope to
situations where hundreds or even thousands of hosts could be listening
across a site. Given the design goals of LLMNR, multicast queries were
precluded early on.

While the content of queries might indeed be a higher layer issue,
it is very relevant to the interoperability question.  A host sending
a query for a ".local" name will not receive a response unless the
target also is configured with a ".local" name.  So in practice,
converging LLMNR and Rendezvous yields no useful benefits unless
the hosts also adopt the Rendezvous namespace model.

The problem with that model is that it requires users to either
type the ".local" extension, or for ".local" to be put into the
searchlist.  The former is a problem for users used to a flat
namespace (e.g. http://foo, which can be resolved via RFC 1001-1002,
NetBIOS over TCP/IP).  The latter results in lots of bogus
".local" queries.

In terms of proxying and power management, name conflict detection
can be run when systems power up again, and since name conflicts
are relatively unlikely, there is no need in LLMNR to
deploy proxies for this purpose, particularly in mobile
environments where they are likely to be serving up out of
date information.  In any case, since proxies depend on multicast
responses, once those are eliminated to improve scaling, they
can't be used anyway.

In terms of differing uses of the header bits, and other sections
of the DNS packet, almost every bit and field is used differently
in LLMNR and Rendezvous.

LLMNR does not allow multiple questions in a query, since these
are known to cause confusion.  Therefore there is no need to use the
TC bit in a query, as Rendezvous does.  Since LLMNR is not a service
discovery protocol, there is no need to implement known answer
suppression.

Since in LLMNR there are no proxies or non-authoritative answers, there
is no need to use the RA or AA bits either.

LLMNR specifies more strict handling of SOA and NS RRs in
order to handle the different delegation model of a peer-to-peer
name resolution protocol.

The CD or AD bits do not apply to a peer-to-peer name
resolution protocol where there is no implicit trust, so LLMNR does not
use them.

In order to be compatible with DNSSEC, LLMNR requires support
for EDNS0, which has its own way of handling MTU issues.  In
LLMNR automatically sending a packet of link MTU size would
not be wise because of the need to allow extension to larger
scopes going forward. So LLMNR and Rendezvous don't even handle MTU issues
the same way.

Rather than disallowing all non-zero RCODEs, LLMNR allows
error messages to be used in response to unicast queries,
in order to permit problem diagnosis and enable use of
DNSSEC & TSIG.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 28 Jan 2004 14:27:53 -0800

> across a site. Given the design goals of LLMNR, multicast queries were

I'm confused. LLMNR is only useful when there is no configured DNS, 
otherwise all queries go to unicast DNS and only fall back to LLMNR if 
the unicast DNS query fails (which one can not rely on). What sort of 
scenario are you likely to run in to where there would be no unicast 
DNS but there are routers configured to handle multicast? Where is this 
mentioned as a design goal?

It seems like LLMNR has a subset of the mDNS functionality. LLMNR 
focuses on solving the problem of resolving DNS entries when there is 
no DNS server. mDNS attempts to solve the problem of resolving DNS 
names when there is no DNS as well as resolving names even when there 
is a configured DNS server. In a number of situations, people may end 
up on the same network where names for the addresses they receive are 
arbitrary or nonexistent. A common example would be two people meeting 
in an airport and joining the same wireless network at the airport. If 
they had private addresses, there would be no point in using dynamic 
DNS to register their address. LLMNR wouldn't work.

-josh