Re: [mdnsext] Hierarchical (host) domain names in mDNS?

Andrew Sullivan <ajs@anvilwalrusden.com> Tue, 16 July 2013 13:57 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: mdnsext@ietfa.amsl.com
Delivered-To: mdnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C4F21F9D4F for <mdnsext@ietfa.amsl.com>; Tue, 16 Jul 2013 06:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.772
X-Spam-Level:
X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3neo9e+O8uQ for <mdnsext@ietfa.amsl.com>; Tue, 16 Jul 2013 06:57:22 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3C11621F9D45 for <mdnsext@ietf.org>; Tue, 16 Jul 2013 06:57:21 -0700 (PDT)
Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D689B8A031 for <mdnsext@ietf.org>; Tue, 16 Jul 2013 13:57:19 +0000 (UTC)
Date: Tue, 16 Jul 2013 09:57:18 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: mdnsext@ietf.org
Message-ID: <20130716135718.GB23286@mx1.yitter.info>
References: <E36F274013087B4EA05E08EB5037503902C1DC@DEFTHW99EK5MSX.ww902.siemens.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E36F274013087B4EA05E08EB5037503902C1DC@DEFTHW99EK5MSX.ww902.siemens.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [mdnsext] Hierarchical (host) domain names in mDNS?
X-BeenThere: mdnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mdnsext>
List-Post: <mailto:mdnsext@ietf.org>
List-Help: <mailto:mdnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 13:57:32 -0000

On Tue, Jul 16, 2013 at 11:32:52AM +0000, Albrecht, Harald wrote:
> Hello,
> 
> something I couldn't find a proper answer to I would like to ask the mDNS experts on this list: is it possible to apply mDNS also to situations where the decentralized, configuration-free operation of mDNS is required but where the individual hosts within the same network need to make use of hierarchical domain names? Such as "controller.machine2.local"?
> 

No. 

The mDNS specification is in RFC 6762.  Right at the beginning, it
says, "To remedy this problem, this document allows any computer user
to elect to give their computers link-local Multicast DNS host names
of the form: "single-dns-label.local.".  Note the "single-dns-label".
(It's actually not a DNS label, either, actually, but never mind that.)

Unfortunately, you can't do what you want.  

It seems that the environment you need is much more amenable to
traditinal DNS use.  That's probably not the answer you want, but I
think it's likely true.  This isn't too surprising.  You can't really
have an unmanaged namespace that is also managed, which is sort of
what you seem to want.

One thing you could do is use some sort of trickery to make your
labels flat, like service1_machine1.local, service2_machine1.local,
service1_machine2.local, and so on.  This is slightly hideous because
there's no convenient way to split up the service name from the
machine name (one of the distinct advantages of te DNS is this
hierarchical name space).  But you could generate such labels
programmatically, I think.

Better, I suspect, would be to create a mechanism for registering
names of the services and machines in a local registry.  Your
configuration would need to be just a little bit smarter, from the
sounds of things, but it would allow you to create a self-contained
system that allowed these machines to co-operate.  You could trivially
set up a DNS zone with one name per customer, so that you shipped a
box with customer1.example.com, customer2.example.com, and so on, with
the machines to be configured.  That's in effect your "router" (you
could do this on any of the standard user-programmable wireless
gateways derived from the WRT-style products).  Then you could even
charge for so-called "vanity" service if there was a customer that
already had a corporate domain name and wanted to include that
instead.  (Or just make it a user-configurable option at install time,
&c. &c.)

Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com