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

[Kerry Lynn <[e-mail]>]

On Tue, Jul 16, 2013 at 7:32 AM, Albrecht, Harald <
[e-mail]> 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-