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

Kerry Lynn <kerlyn@ieee.org> Tue, 16 July 2013 14:49 UTC

Return-Path: <kerlyn2001@gmail.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 5959711E80D7 for <mdnsext@ietfa.amsl.com>; Tue, 16 Jul 2013 07:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 2ESj4UE1HNE0 for <mdnsext@ietfa.amsl.com>; Tue, 16 Jul 2013 07:49:15 -0700 (PDT)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6B34E11E80D5 for <mdnsext@ietf.org>; Tue, 16 Jul 2013 07:49:12 -0700 (PDT)
Received: by mail-ob0-f171.google.com with SMTP id dn14so831964obc.2 for <mdnsext@ietf.org>; Tue, 16 Jul 2013 07:49:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=np7FdaIeUxj93zZOvNQxWqGlJrjyNkFkFcmA5qgBb1c=; b=ACYQnFzjjUD9sp3gq1LxoyTP9B48X7Rybw0Xcxh033BsKo2AKK9Wp/kmzzxWRFvHyx PgygmJF4hWmKwLmJU+BtacGosTIwarTQwxiRmZGVQYFuIxDWgAqcH9hv5hKZF3SKQVjT WZASdT2dnqLaX13Hivds+YNn9CCMxm0tvTILYorifpTz6s038lC2UhoRq8BQw2pA4vlD NvxWgL9hXMgMD5BQhj7bp6CIL4xiWai40W5rZRXzoPzdzOBzM0QsBOSTffVd42kq7N2d pl41aw/+EARRGbsbFooub/nCKIDUIz9edNJzBPdxgO3Pm4/CCkeNYTAdy4N8MJgbhct9 4xmw==
MIME-Version: 1.0
X-Received: by 10.60.117.233 with SMTP id kh9mr2611010oeb.58.1373986151923; Tue, 16 Jul 2013 07:49:11 -0700 (PDT)
Sender: kerlyn2001@gmail.com
Received: by 10.60.94.239 with HTTP; Tue, 16 Jul 2013 07:49:11 -0700 (PDT)
In-Reply-To: <E36F274013087B4EA05E08EB5037503902C1DC@DEFTHW99EK5MSX.ww902.siemens.net>
References: <E36F274013087B4EA05E08EB5037503902C1DC@DEFTHW99EK5MSX.ww902.siemens.net>
Date: Tue, 16 Jul 2013 10:49:11 -0400
X-Google-Sender-Auth: 8bA7_NUggJVS9oY87UuXp_aCFLg
Message-ID: <CABOxzu27u5BMTZq2WKFk5O4nmLG87BXCdG6+M7+MeB-ZugDN9Q@mail.gmail.com>
From: Kerry Lynn <kerlyn@ieee.org>
To: "Albrecht, Harald" <harald.albrecht@siemens.com>
Content-Type: multipart/alternative; boundary=047d7b3a92a083059804e1a2148a
Cc: "mdnsext@ietf.org" <mdnsext@ietf.org>
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 14:49:16 -0000

On Tue, Jul 16, 2013 at 7:32 AM, Albrecht, Harald <
harald.albrecht@siemens.com> 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”?
>
>
I think the answer is (or should be) "yes".

First some guidance from RFC 6762:

   This document recommends a single flat namespace for dot-local host
   names, (i.e., the names of DNS "A" and "AAAA" records, which map
   names to IPv4 and IPv6 addresses), but other DNS record types (such
   as those used by DNS-Based Service Discovery [RFC6763
<http://tools.ietf.org/html/rfc6763>]) may contain
   as many labels as appropriate for the desired usage, up to a maximum
   of 255 bytes, plus a terminating zero byte at the end.  Name length
   issues are discussed further in Appendix C
<http://tools.ietf.org/html/rfc6762#appendix-C>.


The meaning of "recommends" as a keyword is equivalent to SHOULD.
Now why does RFC 6762 take this position?  It has to do with automagic
operation
of an mDNS resolver:

   A malicious host could masquerade as "www.example.com." by answering
   the resulting Multicast DNS query for "www.example.com.local.".  To
   avoid this, a host MUST NOT append the search suffix ".local.", if
   present, to any relative (partially qualified) host name containing
   two or more labels.  Appending ".local." to single-label relative
   host names is acceptable, since the user should have no expectation
   that a single-label host name will resolve as is.

So this places a restriction on resolvers, which is basically intended to
keep the fox out of
the hen house.  One should still expect "controller.machine2.local." to
resolve properly,
if there is an authoritative responder for this host name.  I assume it
would be invisible to
lookups in ".local.".

Some months back, the main criticism of mDNS in homenet was that if I
visited a friend's
house then my browser might confuse my bookmarked "www.refrigerator.local."
with my
friend's.  I mentioned at the time that most (all?) major printer vendors
solve this problem
by appending a collision-resistant substring to a human-readable substring
to create the
instance or host label, e.g.,
Officejet\032Pro\0328500\032A909g\032[4C0EA4].  A similar
approach was proposed by Brian Carpenter, but he proposed creating "zones"
in the
.local. namespace, e.g., <ULA>.local.

I suspect either approach can be made to work.  I suggest you take a look
at the Discovery
section of the ZigBee Smart Energy Profile 2 (now IEEE 2030.5)
specification:
http://www.zigbee.org/Standards/ZigBeeSmartEnergy/ZigBeeSmartEnergy20Standard.aspx
to see how your problem was solved using "fine-grained" discovery based on
the former
approach.

Regards, -K-