Re: clarification re mdns/llmnr
Rob Austein <sra+namedroppers@hactrn.net> Wed, 11 September 2002 18:03 UTC
Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19416 for <dnsext-archive@lists.ietf.org>; Wed, 11 Sep 2002 14:03:03 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pBYX-000AEw-00 for namedroppers-data@psg.com; Wed, 11 Sep 2002 10:45:37 -0700
Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17pBYU-000A9l-00 for namedroppers@ops.ietf.org; Wed, 11 Sep 2002 10:45:34 -0700
Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0450A198A; Wed, 11 Sep 2002 13:44:59 -0400 (EDT)
Date: Wed, 11 Sep 2002 13:44:59 -0400
From: Rob Austein <sra+namedroppers@hactrn.net>
To: Aidan Williams <aidan.williams@motorola.com>
Cc: namedroppers@ops.ietf.org, levone@microsoft.com, bernarda@microsoft.com, dthaler@microsoft.com
Subject: Re: clarification re mdns/llmnr
In-Reply-To: <3D7E915C.2000601@motorola.com>
References: <200208281155.HAA24447@ietf.org> <3D7E915C.2000601@motorola.com>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajing�-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20020911174500.0450A198A@thrintun.hactrn.net>
X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
At Wed, 11 Sep 2002 10:42:04 +1000, Aidan Williams wrote: > > On the zeroconf mailing list i recently wrote this: > > > Before leaping into the next set of comments I should summarise what > > I believe the state of play is with zeroconf naming. I have been > > following the discussion in dnsext, and my understanding was that > > there was general agreement on the following points: > > > > - mDNS/LLMNR was *not* DNS, > > rather it was a seperate protocol, seperate port, > > seperate cache, etc > > > > - there was agreement that mDNS/LLMNR should not be used > > as a substitute for DNS -- ie should not be used for > > looking up "one true DNS names" > > > > - that mDNS/LLMNR should not be used to transport DNS requests > > to a "back end resolver" > > > > In my opinion, these comments also apply to the IPv6 Node > > Information Query proposal as well. I think I believe all of the above. > > Right now, the -12 LLMNR document has examples with FQDNs in them. > > Unless there have been conversations that I am unaware of, I > > believe it was the intent of the working group *not* to support > > the resolution of names such as mylaptop.microsoft.com using LLMNR. I don't think I believe this one, although I could of course be wrong. If it's a separate namespace, it's a separate namespace. The fact that a name in one might happen to look like a name in the other is not in itself a reason to forbid it. The real question underlying all of this, however, is how these names are going to be used. In particular, how applications are going to deal with the general problem of having multiple discrete namespaces, most particularly applications that were not designed to support such a thing. Solve that, and the question of whether there's a strong reason to restrict the syntax of LLMNR names will probably be obvious. Once upon a time (back when dinosaurs still roamed the machine rooms in mighty herds) I used a mailsystem on which a fully-specified address in the MUA looked like sra@xx.lcs.mit.edu.#Chaos sra@xx.lcs.mit.edu.#Internet while saying just sra@xx.lcs.mit.edu was an invitation to the MUA to pick whichever naming realm it felt good about today. The mail software of course stripped the .#whatever tag off the end before handing the message off to the MTA, so this was strictly a user interface issue, not a protocol issue. I'm not suggesting reviving that particular user interface or notation, just pointing out that this is not the first time that this problem has arisen, and that there's more than one way to attack this kind of problem. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>
- Re: clarification re mdns/llmnr Rob Austein