Subject: ZEROCONF and multicast name resolution

From: Erik Guttman <[email-masked]>
Date: Wed, 24 Jul 2002 11:44:56 +0200 (MEST)

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Folks,

The appropriate place to discuss these matters is on the DNSEXT WG
mailing list.  I am cross posting this message to the ZEROCONF WG
list only in order to end the thread which we do not have the 
charter to resolve and redirect discussion to the forum which does.

Keith Moore and various interlocutors have been discussing
multicast name resolution on the ZEROCONF WG mailing list.
I will not summarize that discussion, but I believe the below
captures most of the major points.  If I fail to do justice
to your particular concerns, please expand.

Multicast-Based Name Resolution
-------------------------------

Multicast-based name resolution has been a goal of the ZEROCONF
WG since it was chartered.  The work item, to create a standards
track protocol, has been taken on by the DNSEXT WG.

This effort has been troubled, again because of disagreements
about the functional requirements, but also because of unease
from many involved in DNS standardization at the IETF.  The
requirements expressed in ZEROCONF WG documents were either
not clear, or they were not meet with agreement in the DNSEXT WG.

I believe the goals for multicast name resolution arise from
the following observations.

 - Peer to peer naming protocols exist today, and have for a
   long time (NetBIOS and AppleTalk).  

 - It is possible to use these protocols to resolve names without 
   the use of DNS.  

 - NetBIOS and AppleTalk names can be *the same* as host names in
   the DNS.

 - Some hosts *ALREADY* use alternative naming mechanisms to resolve
   names when DNS is not available (NIS, NetBIOS, AppleTalk, others).
   As has been brought out on the list, this is common practice and in
   no way incorrect with respect to the resolver APIs.

 - There is no IETF standard way to provide this function, over IP.
 
 - It is desirable to retire NetBIOS and AppleTalk for many reasons
   but without a functionally equivalent IETF standard solution, this 
   is not possible.

The ZEROCONF WG has attempted to articulate the requirements for
an IETF standard to allow this name to address (and reverse) 
resolution in environments without DNS support.

There are numerous areas where we run into differences of opinion.

 - What does it mean for hosts to respond to fully qualified 
   domain names which DNS would normally respond to?  Should 
   multicast name resolution use the same namespace as DNS? 

   Some have held that we need a special 'local' namespace,
   while others believe that a host should be able to respond
   to requests for its 'own' name.

 - What we really want is applications that continue to 
   function even when DNS fails or is not present:  http://foo
   will succeed if there is a host which can respond to a
   name resolution request for 'foo' using the non-DNS multicast
   name resoultion protocol.  

   Some seem to hold this is not an appropriate objective.

 - Should multicast name resolution be possible whether even when
   DNS *is* available?  This would prevent 'local' name resolution 
   from ever failing and ensure it always returns consistent
   information.

   Many have asserted that DNS has to be used, exclusively,
   for domain name resolution if it is available as this is the 
   current and expected behavior.

That these issues have not been clearly resolved has left
work on LLMNR (draft-ietf-dnsext-mdns-10.txt) in an uncertain state.  

Let's try to resolve the issues and can come up with a solution which 
will serve the many users of local, unadministered networks.

Thanks and regards,

Erik

--
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: Erik Guttman <[email-masked]>
Date: Wed, 24 Jul 2002 16:17:53 +0200 (MEST)

> work on LLMNR (draft-ietf-dnsext-mdns-10.txt) in an uncertain state.  

Oops.  I have not been to the past two IETF meetings and 
have been relying on the mailing list to stay informed.  

I gather it was decided at the Yokohama DNSEXT meeting to 
take the next revision of the mdns draft to WG last call.
So the doc isn't in an 'uncertain state' after all, except
maybe now after my untimely comments :-/

Erik

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Jul 2002 14:05:18 -0400

Erik,

thanks for the summary; to me it seems a reasonable reflection of the 
recent zeroconf discussion.  I'll go look at the namedroppers archive 
and see if I can glean what that group has said about this.

my concerns can briefly be summarized as follows:

- in general, changing existing APIs will break applications.  one way 
  to do this is to change an existing name lookup function in such
  a way that the names no longer have the same semantics as before,
  or it treats names as valid that were formally invalid, or 
  by introducing new error conditions that need to be distinguished
  from the old ones.  such changes seem a likely result of changing
  an existing name lookup API to also handle name lookup in an ad hoc 
  network.

- local names can be useful, but they should be easily distinguished
  from fully qualified dns names, both by humans and by applications.  

  the de facto standard way to do this is to omit dots from local names.  
  if that convention is also adopted for ad hoc networks then fewer 
  applications will break.

- if you provide another way to look up DNS names (as opposed to local
  names), it needs to have results that are consistent with DNS.
  just as one example, it needs to never return "no such name" or
  "no records" when in fact it cannot tell whether the name exists
  or whether there are any such records.  this is somewhat difficult 
  to do in a disconnected network.

- a name lookup protocol that works on an ad hoc network is useful.
  but expecting a name lookup protocol to also be usable for service
  discovery creates some conflicts that are not easily resolved.

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 25 Jul 2002 14:05:49 -0500

> Multicast-Based Name Resolution

First off, there needs to be a clarification in terminology. We keep
running into this. Party A interprets it as <this> when talking to Party B
who interprets it as <that>, and they end up talking around each other.
Please fix your [zeroconf] wording so that we at least know what we are
NOT talking about.

There are at least two different concepts of multicast name resolution. On
the one hand, there is the typical DNS resolver operating in a typical
environment, but using multicast destinations instead of static unicast
server addresses. In this model, the stub resolver can use multicast to
query any locally available server which might be able to answer the
query, rather than have to ask a known server, but is otherwise identical
to the existing protocol: the servers are the only systems that "listen"
for queries, they process the queries against the existing namespace and
partition hierarchy, and they use the same message formats to do their
work. This is what most people in the DNS community think about when you
say "multicast DNS" or "multicast name resolution" in the context of "work
for the DNSEXT WG."

Conversely, the model that the Zeroconf folks appear to be describing
(based on the last time I read the documents anyway) is for two strangers
to be able to identify each other through peer-level lookups, such as
having two users on a train communicate via friendly names. For all
practical purposes, this is not DNS. The nodes are peers (capable of
acting as servers) rather than clients, and there is no partition
hierarchy although the namespace respresents a shadow node of a particular
partition. In the end, it is an entirely different application which just
so happens to reuse the DNS message format. Therefore it is not DNS, and
it follows that this cannot be multicast DNS. Please call it something
else, "zeroconf neighbor naming lookup service" or anything.

It is also worth noting that these two uses do not conflict (although the
terminology sure does). Both are admirable objectives.

>    but without a functionally equivalent IETF standard solution, this 

All very true and reasonable claims, for the specific application scenario
you are describing.

These problems can be dealt with differently in a typical wired hierarchy
installation. EG, netbios and appletalk naming can be glued onto the
existing DNS easily if the user is configured for a specific environment,
essentially using DNS as a replacement for broadcasting. I can provide
more information on how this could work but it is OT for now. The point
here is that you are trying to use the DNS message as a container for a
vendor-neutral name lookup service in a multicast domain, and your list of
"facts" above represent this specific application naturally.

>    to requests for its 'own' name.

The DNS namespace is a logical view of the partition hierarchy (it is not
a mirror). Since you are not using the partition hierarchy, there is no
NEED for you to use the namespace. However, if you want to prevent the
collisions which are bound to occur in anarchist naming systems, then
using the DNS namespace is a reasonable first-stab at ensuring that two
nodes will have the same name.

This is BS, BTW, since there are lots of organizations that use the same
domain name (in traditional wired hierarchies, collisions are avoided
since the local servers only deal with authoritative sources). Also
consider that not all of the nodes will ever have touched a real DNS
domain name, and therefore may not have any preconceived notion of what
their actual FQDN should be. From this perspective, the use of the DNS
namespace gets you nothing substantive over any other namespace.

There is another consideration here, which is that the question section of
a DNS message is a fixed structure (EG, regardless of the QClass, labels
are restricted to 63 octets). You could get a lot more flexibility in your
naming if you used something else. Issues with conflicting names,
coordination between the friendly name and other namespaces (such as DNS)
would have to be resolved, but it would actually be simpler if you used
something else entirely. There are plenty of well-known techniques
available here -- automatic renaming on collision, using additional data
such as a full name or some other informational string to supplement the
name -- and these options are not available in a DNS-strict model.

>    Some seem to hold this is not an appropriate objective.

Sounds reasonable to me. Make it so. :p

>    current and expected behavior.

The use of nsswitch.conf files (or their ilk) is well-known to be workable
for this kind of dual usage. In order to make this seamless, you have to
be able to negotiate priority, but that is outside the scope of the
protocol spec. One possiblility here is that if the application knows it
is connected to a traditional wired infrastructure (it got a DHCP lease,
the DNS server is answering, whatever) then it should try DNS first and
then fail over to ZNNS, but again I would think that is outside the scope
of the protocol specification.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 25 Jul 2002 14:15:53 -0500

[I should have read/edited this before sending]

on 7/25/2002 2:05 PM Eric A. Hall wrote:

> netbios and appletalk naming can be glued onto the existing DNS easily
> if the user is configured for a specific environment, essentially using
> DNS as a replacement for broadcasting. I can provide more information
> on how this could work but it is OT for now.

This model would essentially provide fixed ZNNS servers for situations
where the peer-level registration and discovery was undesirable or
untenable. Think of it as providing WINS-like functionality if you want.
There are some tricks that can be done here with things like protocol-
specific SRV RRs, service-specific NBP/NBT RRs, etc. If the user is
attached to the network (as detected from whatever clues) then this would
be used as preferred since naming conflicts could be avoided.

> the use of the DNS namespace gets you nothing substantive over any
> other namespace.

That's not entirely true. See above.