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

From: "Albrecht, Harald" <[email-masked]>
Date: Tue, 16 Jul 2013 11:32:52 +0000

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'll illustrate this situation now in more detail: for instance, consider something like machines for producing bread rolls ... bakeries can buy such equipment from specialized machine manufacturers. Such (OEM) machines may very well be modular and with an inner structure that results on such a single machine equipped with several networked nodes, such as a user panel, a controller, and several devices for sensors and actuators. The OEM machine builder builds the machine and programs the networked nodes. Part of this process is, of course, to assign host names to the nodes. For instance, "hmi", "controller", "stamper", "former", "cooler", and so on. mDNS can be used in this situation to allow the individual nodes to communicate with each other independently of any concrete IP addresses set.

After the machine has been built, it is essentially sealed in terms of its setup. In particular, when the machine gets delivered to a customer and commissioned on site, it is not possible to change the host names as such anymore.

This is no problem if a customer just orders a single machine. However, if you need such machines, you surely need more than one. So we end up with multiple instances of the same blueprint. Of course, you could try to separate these machines into different subnets and thus different mDNS "domains". However, a bakery surely does not want to spend money on several routers just to make the name resolution work. Also, routers may very well increase administrative efforts ; something that these customers surely don't need and don't want.

So what is needed in this situation is to view the individual machines as domains, such as "machine1", "machine2", et cetera. The individual networked nodes inside these machines then would live in the sub name spaces, such as "controller.machine1" and "controller.machine2". We even see (in other applications) three levels of hierarchy, such as cells, machines, nodes inside these machines. However, these installations don't want to go the extra mile for a proper DNS infrastructure, but instead want to rely on a peer-based name resolution system, such as mDNS is one example of.

My (limited) understanding of mDNS is that this is not possible, as "controller.machine1.local" isn't allowed. Or am I mistaken here? Can mDNS handle such situations? Would IETF87 Berlin be the right place to discuss my situation and how to properly apply mDNS?

With best regards,
Harald Albrecht

Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
I IA AS CTO DH 1
Gleiwitzer Str. 555
90475 Nürnberg, Deutschland
Tel: +49 911 895-3847
Fax: +49 911 895-2105
mailto:[email-masked]

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Peter Löscher, Vorsitzender; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Süß; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Jul 2013 09:57:18 -0400

> 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…

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
[email-masked]

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 16 Jul 2013 10:49:11 -0400

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Jul 2013 11:14:44 -0400

> the hen house.  One should still expect "controller.machine2.local." to

Yes, if you tried to resolve "controller.machine2.local.", then it
_would_ resolve correctly.  The difficulty, however, is that most
resolving applications don't actually work truly fully-qualified that
way (i.e. by appending the final dot).  So it will work fine if you
have special name-handling code to make sure that everything is
actually really fully qualified always in local.  I think it would be
extremely wise to test how well that works in practice, but those who
have complete control over their application stack and so on might be
able to do it.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Albrecht, Harald" <[email-masked]>
Date: Wed, 17 Jul 2013 07:13:47 +0000

Thanks for the reply,

control over the software stack is right down to one of the problems: there is not a single software stack, there are multiple ones, so while we may have control over some of our own stacks, we won't have over the ones already out in the wild and which we want to interoperate with. Maybe a change would be possible, but my view is that this would first need consensus (where exactly? here in this group?) and in the "worst cast" an update to the RFC. Would this be a feasible approach at all?

With best regards,
Harald Albrecht

Siemens AG
Industry Sector

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im
> Auftrag von Andrew Sullivan
> Gesendet: Dienstag, 16. Juli 2013 17:15
> An: [email-masked]
> Betreff: Re: [mdnsext] Hierarchical (host) domain names in mDNS?
> 
> > the hen house.  One should still expect "controller.machine2.local."
> > to resolve properly,
> 
> Yes, if you tried to resolve "controller.machine2.local.", then it _would_
> resolve correctly.  The difficulty, however, is that most resolving applications
> don't actually work truly fully-qualified that way (i.e. by appending the final
> dot).  So it will work fine if you have special name-handling code to make
> sure that everything is actually really fully qualified always in local.  I think it
> would be extremely wise to test how well that works in practice, but those
> who have complete control over their application stack and so on might be
> able to do it.
> 
> Best,
> 
> A
> 
> --
> Andrew Sullivan
> [email-masked]
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

---

From: Erik Kline <[email-masked]>
Date: Wed, 17 Jul 2013 16:27:04 +0900

Would you be able to suffice with having the smaller nodes (“hmi”,
“controller”, “stamper”, “former”, “cooler”) be identifiable as
services offered via machine1 and machine2?  If all that any external
elements are doing is trying to talk to some specific service on those
nodes (REST-ful HTTP server, etc), could machine1 advertise _hdmi,
_controller, _stamper, ... services?

---

From: "Albrecht, Harald" <[email-masked]>
Date: Wed, 17 Jul 2013 07:29:49 +0000

> (It's actually not a DNS label, either, actually, but never mind that.)

As I'm curious to learn more on this topic ... why do you think that it's not a DNS label? At least, I thought it to be a label?

> 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.

I don't want a particular answer, I want to know. We may very well decide to not use mDNS, so it is really about finding out where the design "limitations" of mDNS are.

But no, my environment is rather openly hostile to traditional DNS use. Putting such rather useless discussions about reliability aside (as I trust DNS to be operated reliably) the main issue are the "business processes" of how host names (or rather domain names) enter DNS: they are not established and it will probably take at least half a decade at best to slowly introduce these environments to DNS.

> 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.

The point here is that there is no need for management: the "management" has already taken place when designing the automation as we are in fact mirroring the technological hierarchical names in DNS. We aldready have means in place that allow all kind of funny technological names to be used in a DNS-compatible manner, that is, in a manner compatible with LDH. We do acutually use DNS, but only on the large scale. What we need in these environments, however, is a small-scale and completely administration-free solution. mDNS is appealing here ... but my show stopper seems to be the "hierarchical names" thing.

> 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.

Yes, of course, that is an option. However, we ditched it as it wouldn't really integrate with the existing systems. People when would need to know which names to use in which context: oh, if it's "local" (well, ".local."), then I need to use the underlines, otherwise, I'll use the dots. Recipe for disaster.

> 
> Better, I suspect, would be to create a mechanism for registering names of
> the services and machines in a local registry.

As I indicated above, a local registry would still be a single point of failure. Adding redundancy to it is a big effort. And customers would not accept it just for local use. For large-scale use, they will accept, but then we're talking about full-blown DNS. mDNS is a peer system that in this aspect of its design is exactly what will perfectly fit into the environments we are dealing with. It's just that we need hierarchical names, maybe only two or three levels below ".local.", but we need it.

Putting this details aside, I really enjoy the replies and suggestions here!

With best regards,
Harald Albrecht

--- I have to add the following due to local law; let's hope that there are no other places with a law forbidding to add the following ---
Siemens AG
Industry Sector

---

From: "Albrecht, Harald" <[email-masked]>
Date: Wed, 17 Jul 2013 07:39:09 +0000

Hi Erik,

unfortunately not; I need "full A/AAAA connectivity", that is, we're not talking about a particular "transport" HTTP, but I need support for all transports that sit on top of IP, either directly or indirectly. Also, there is nothing such as a central "portal", that is, a web server that acts as the entrance to the individual systems.

For instance, our S7 controllers allow our customers to programmatically use TCP connections right from their control programs ... and there's a great demand of that. So, customers need to be able to either address within the same domain level, such as the "hmi" connecting to the "controller". But there's also need for inter-machine synchronization (or inter-cell), that is, "controller.machine1...." to "controller.machine2....".

At these levels, our customers only accept decentralized and administration-free technologies for name resolution. Only at much higher levels DNS is acceptable, such as when having to loosely connect different plants, et cetera.

With best regards,
Harald Albrecht

> Von: Erik Kline [mailto:[email-masked]]
> Gesendet: Mittwoch, 17. Juli 2013 09:27
> An: Albrecht, Harald
> Cc: [email-masked]
> “controller”, “stamper”, “former”, “cooler”) be identifiable as services
> offered via machine1 and machine2?  If all that any external elements are
> doing is trying to talk to some specific service on those nodes (REST-ful HTTP
> server, etc), could machine1 advertise _hdmi, _controller, _stamper, ...
> services?

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 17 Jul 2013 10:13:27 -0400

On Wed, Jul 17, 2013 at 3:13 AM, Albrecht, Harald <
[email-masked]> wrote:

> Thanks for the reply,
>
> control over the software stack is right down to one of the problems:
> there is not a single software stack, there are multiple ones, so while we
> may have control over some of our own stacks, we won't have over the ones
> already out in the wild and which we want to interoperate with. Maybe a
> change would be possible, but my view is that this would first need
> consensus (where exactly? here in this group?) and in the "worst cast" an
> update to the RFC. Would this be a feasible approach at all?
>
> Harald,

As I said previously, if your application provides a qualified domain name
ending in
".local" or ".local." then what you propose should work fine with an
mDNS-aware
resolver.  It is the TLD ".local" that triggers the behavior to multicast
the request to
port 5353.  What an mDNS-aware resolver won't do is to append ".local" to a
multi-
label host name if your application omits it.

IMO, this does not constitute "full control of the stack", nor is an update
to RFC 6762
required.  This is not a difficult experiment to set up; I have tried it
with OS X and
Ubuntu LTS.  You can ensure it works on Windows by installing Bonjour for
Windows.

-K-

> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard
> Cromme; Vorstand: Peter Löscher, Vorsitzender; Roland Busch, Brigitte
> Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt,
> Siegfried Russwurm, Peter Y. Solmssen, Michael Süß; Sitz der Gesellschaft:
> Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg,
> HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322
>
>
>
> _would_

---

From: "Albrecht, Harald" <[email-masked]>
Date: Thu, 18 Jul 2013 07:13:14 +0000

Hi,

thanks for the valuable feedback. I have no problem with explicitly appending ".local.", in fact, I would even like to make this explicit, so that "local" connections also need to use "controller.machine1.local.". This way, users will learn right from the start which names will trigger which resolution technologies.

My (negative) experience comes from experimenting with the mDNS tools in the Apple *nix package (if I remember correctly, the exact tests did a colleague of mine). The problem was that these command line tools reject any host domain name that doesn't fit into the "single-dns-label.localhost" template. So that is where my question and hesitation comes from. Of course, we may have done something wrong and the error is on our side. Anyway, I'm curious to learn more here in order to better understand the full picture.

So, from what you wrote I will ask my colleague to run the checks again not using the command line tools but using the mDNS resolver instead. It will be interesting what the results will be... looks as if there is a difference between the resolver and the command line tools.

With best regards,
Harald

Siemens AG
Industry Sector

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Kerry Lynn
Gesendet: Mittwoch, 17. Juli 2013 16:13
An: Albrecht, Harald
Cc: [email-masked]
Betreff: Re: [mdnsext] Hierarchical (host) domain names in mDNS?

On Wed, Jul 17, 2013 at 3:13 AM, Albrecht, Harald <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the reply,

Harald,

As I said previously, if your application provides a qualified domain name ending in
".local" or ".local." then what you propose should work fine with an mDNS-aware
resolver.  It is the TLD ".local" that triggers the behavior to multicast the request to
port 5353.  What an mDNS-aware resolver won't do is to append ".local" to a multi-
label host name if your application omits it.

IMO, this does not constitute "full control of the stack", nor is an update to RFC 6762
required.  This is not a difficult experiment to set up; I have tried it with OS X and
Ubuntu LTS.  You can ensure it works on Windows by installing Bonjour for Windows.

-K-

With best regards,
Harald Albrecht

Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
I IA AS CTO DH 1
Gleiwitzer Str. 555
90475 Nürnberg, Deutschland
Tel: +49 911 895-3847<tel:%2B49%20911%20895-3847>
Fax: +49 911 895-2105<tel:%2B49%20911%20895-2105>
mailto:[email-masked]<mailto:[email-masked]>

> Von: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] Im
> An: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
mdnsext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mdnsext