Subject: [homenet] Name resolution in the homenet architecture document

From: Ralph Droms <[email-masked]>
Date: Fri, 9 Mar 2012 13:05:55 -0500

Here's my list of "desired behaviors" for name resolution, proposed for inclusion in the architecture document; comments and suggestions welcome:

* Disconnected operation ("fate sharing"): name resolution for reachable devices continues if the local network is disconnected from the global Internet
* Relative name resolution: some naming convention that allows name resolution while mitigating the need to know an absolute location in the global DNS namespace
* Unmanaged operation
* Efficient message utilization: for example, keep unwanted traffic off of an IEEE802.15.4 network
* Representation in the global DNS namespace, for access from off-net

- Ralph

---

From: Ray Bellis <[email-masked]>
Date: Fri, 9 Mar 2012 18:24:25 +0000

> * Disconnected operation ("fate sharing"): name resolution for reachable devices continues if the local network is disconnected from the global Internet

Yes, absolutely!

> * Relative name resolution: some naming convention that allows name resolution while mitigating the need to know an absolute location in the global DNS namespace

Hmm, I'm uneasy about this one.

I've been vocal in my complaints about how broken the DNS Search Path mechanism is.  In particular, I'm concerned about the possible security implications of using a relative location when a mobile device is moving between networks.

> * Unmanaged operation

Yes

> * Efficient message utilization: for example, keep unwanted traffic off of an IEEE802.15.4 network

Yes

> * Representation in the global DNS namespace, for access from off-net

Yes.

A related issue, also touched on above, is the local namespace.  That is, should there be a single namespace used in the Homenet, regardless of whether the query mechanism is unicast DNS, mDNS, or xmDNS (per Kerry Lynn's draft), or even something that isn't DNS at all?

I'm OK with the idea of a non-DNS based protocol using a pseudo TLD to indicate that it's something different (c.f. ".UUCP"), but to me it just feels wrong that this should be necessary when using stuff that's _so_ close to "normal" unicast DNS.

Ray

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Mar 2012 13:45:29 -0500

>>>>> "Ray" == Ray Bellis <[email-masked]> writes:
    >> * Relative name resolution: some naming convention that allows
    >> name resolution while mitigating the need to know an absolute
    >> location in the global DNS namespace

    Ray> Hmm, I'm uneasy about this one.

    Ray> I've been vocal in my complaints about how broken the DNS
    Ray> Search Path mechanism is.  In particular, I'm concerned about
    Ray> the possible security implications of using a relative location
    Ray> when a mobile device is moving between networks.

I agree with your concern, but sufficient != necessary.

I do not believe that anyone *OUGHT* to pay attention to DNS search
order as provided by DHCP.

That doesn't mean that it shouldn't be available!!!!

(Most systems I've seen get this wrong.  If you select DHCP, your search
path is forced to DHCP, you have to select static to pick it)

    Ray> Yes.

    Ray> A related issue, also touched on above, is the local namespace.
    Ray> That is, should there be a single namespace used in the
    Ray> Homenet, regardless of whether the query mechanism is unicast
    Ray> DNS, mDNS, or xmDNS (per Kerry Lynn's draft), or even something
    Ray> that isn't DNS at all?

I want one.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Mar 2012 14:58:23 -0500

> I've been vocal in my complaints about how broken the DNS Search Path mechanism is.  In particular, I'm concerned about the possible security implications of using a relative location when a mobile…

Very true.   Ideally your homenet would have a namespace in the global DNS hierarchy that would remain the same regardless of where you connected, and your client would have TSIG credentials sufficient to update its own name in that namespace.   Roving namespaces seem fraught with opportunities for the wrong thing to happen, intentionally or otherwise.

---

From: Ralph Droms <[email-masked]>
Date: Sun, 11 Mar 2012 08:02:03 -0400

> Very true.   Ideally your homenet would have a namespace in the global DNS hierarchy that would remain the same regardless of where you connected, and your client would have TSIG credentials suffic…

This point is what I was trying to get at with my second bullet.  Ted, who is the "you" in the "where you connected": the homenet, the device, ???

Yes, I'm stalling for time...

There are two sides to the local or "relative" namespace - the device with the name and the entity trying to contact the device.  I'm trying to work through the scenarios (independent of whether the solution is in applications, a service, DNS-SD, DNS, etc.) and write them down...

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Sun, 11 Mar 2012 09:53:24 -0400

> This point is what I was trying to get at with my second bullet.  Ted, who is the "you" in the "where you connected": the homenet, the device, ???

IOW, when a device is configured locally, how does that configuration propagate through the homenet gateway to the real world, when the gateway isn't necessarily connected when the device configures?

My preferred answer is that the homenet gateway is authoritative for the zone that's being updated, and can process updates even when disconnected.   I realize that MDNS-style solutions are in some sense easier, but they don't give you a consistent name, so you wind up with the search list problem Ray is talking about.

Of course, in this scenario, if the homenet is disconnected, a roaming device would be unable to update it until it reconnected.   I think this is probably okay.

I realize this is a bit more heavyweight than what some people have been talking about, and I'm not claiming they're wrong and I'm right; I'm just saying that this is how I would want my homenet to work, and I think it ties into the idea of end-to-end functionality for homenets, both internally and externally.

---

From: Jim Gettys <[email-masked]>
Date: Sun, 11 Mar 2012 11:03:37 -0400

On 03/11/2012 09:53 AM, Ted Lemon wrote:
> On Mar 11, 2012, at 8:02 AM, Ralph Droms <[email-masked]
> <mailto:[email-masked]>> wrote:
>> This point is what I was trying to get at with my second bullet.
>>  Ted, who is the "you" in the "where you connected": the homenet, the
>> device, ???
>
> IOW, when a device is configured locally, how does that configuration
> propagate through the homenet gateway to the real world, when the
> gateway isn't necessarily connected when the device configures?
>
> My preferred answer is that the homenet gateway is authoritative for
> the zone that's being updated, and can process updates even when
> disconnected.   I realize that MDNS-style solutions are in some sense
> easier, but they don't give you a consistent name, so you wind up with
> the search list problem Ray is talking about.

That's exactly what we're trying to achieve with CeroWrt, with its use
of Bind (with both interior and exterior views).  (See bind a as a place
holder for "real fully featured DNS server" if you have some other
favourite; it's just that dnsmasq can't support this kind of vision at
the moment). Again, "running code" rather than assertion is what we'd
like here, though I think we're far enough along to be able to claim
this is feasible and desirable.  I see/hope that mDNS and uPNP become
legacy protocols in the long run; my previous mail on this topic is that
I am always concerned that there are transition strategies that really work.

>
> Of course, in this scenario, if the homenet is disconnected, a roaming
> device would be unable to update it until it reconnected.   I think
> this is probably okay.
As do I...
>
> I realize this is a bit more heavyweight than what some people have
> been talking about, and I'm not claiming they're wrong and I'm right;
> I'm just saying that this is how I would want my homenet to work, and
> I think it ties into the idea of end-to-end functionality for
> homenets, both internally and externally.
>
Exactly.  Care to help with the final piece of the CeroWrt demonstration
of this?  What's needed are two things:
        1) some dhcp handshake with the upstream ISP provider to provide
the domain keys so that the domain can be delegated and the home router
become the authoritative for the delegated domain.
        2) GUI work so that if the user has a domain of their own (or
the ISP does not/is incapable of delegation), you can get it hooked up
with your DNS provider; while we have bind all running fine, the GUI
work for configuring bind has lagged (I've been intending to do it, but
have been somewhat ill of late). Right now, the CeroWrt GUI is still for
configuring dnsmasq, which we don't use.

I think there is an interesting question of whether interior *names*
should be automatically published into the global DNS by default or
not,  which will depend on the security of the devices and systems and
the users' expertise, if only to make it a bit harder for attackers to
discover interior systems to attack (since with IPv6 finding them by
brute force address space search is relatively hard).

I suspect that it should default to "off", myself, if only because I
know I have boxes in my house that the vendors seldom if ever update the
firmware for, and I don't want them exposed.  Clearly, we have the
reality of many insecure devices mouldering in home environments, and
can't ignore this problem.
                                             Jim

---

From: Ted Lemon <[email-masked]>
Date: Sun, 11 Mar 2012 11:18:19 -0400

I am actually working on a draft that is a start at addressing this problem, and indeed the initial comments I got back suggest that there is more work to do along the lines you're talking about—my draft as written just dealt with the reverse zone and not the forward zone.   The draft is at http://tools.ietf.org/html/draft-lemon-dhc-dns-pd-00.   I think I need to add the bit that you just described, and I might try to turn around a -01 before the deadline to do this.   I'd be curious to know what you think about it.

---

From: Fred Baker <[email-masked]>
Date: Sun, 11 Mar 2012 08:22:18 -0700

Two things someone will need to think about:

ICANN is now selling "dotless" names. A name without dots has a defined behavior in most DNS resolvers; they find a way to further qualify them. Do we want to humor ICANN, or solve this?

mDNS is crippled, in that it operates on a single LAN. That might describe Apple networks; per the architecture document it doesn't describe all home networks. Do we want to provide an admin-scope multicast address for it, and if so, what do we recommend for routing?

On Mar 9, 2012, at 10:05 AM, Ralph Droms wrote:

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Ted Lemon <[email-masked]>
Date: Sun, 11 Mar 2012 11:25:11 -0400

> brute force address space search is relatively hard).

Doesn't making the zone non-enumerable and disabling zone transfers address this problem?   I guess you could still do a dictionary attack on the zone and decrease the cost of the search somewhat in the usual case, but it's a pretty sketchy way to try to start an attack.   Having said that, I think it's probably fine to disable propagation of the zone by default, except that then we have to figure out what to name the non-propagated zone, and how to deal with the transition from non-propagated to propagated.

---

From: Jim Gettys <[email-masked]>
Date: Sun, 11 Mar 2012 11:43:25 -0400

On 03/11/2012 11:25 AM, Ted Lemon wrote:
> On Mar 11, 2012, at 11:03 AM, Jim Gettys <[email-masked]
> <mailto:[email-masked]>> wrote:
> Doesn't making the zone non-enumerable and disabling zone transfers
> address this problem?   I guess you could still do a dictionary attack
> on the zone and decrease the cost of the search somewhat in the usual
> case, but it's a pretty sketchy way to try to start an attack.  
> Having said that, I think it's probably fine to disable propagation of
> the zone by default, except that then we have to figure out what to
> name the non-propagated zone, and how to deal with the transition from
> non-propagated to propagated.
>

Had been thinking more along the line of the multiple "view" stuff in
bind; there would be/is already a public view, and then a private view
only visible internally.
                        - Jim

---

From: Ralph Droms <[email-masked]>
Date: Sun, 11 Mar 2012 11:48:16 -0400

Fred...

> ICANN is now selling "dotless" names. A name without dots has a defined behavior in most DNS resolvers; they find a way to further qualify them. Do we want to humor ICANN, or solve this?

Do you have a pointer to a description of the behavior of "dotless" names?

> mDNS is crippled, in that it operates on a single LAN. That might describe Apple networks; per the architecture document it doesn't describe all home networks. Do we want to provide an admin-scope…

See draft-lynn-homenet-site-mdns-00.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Sun, 11 Mar 2012 13:24:18 -0400

> bind; there would be/is already a public view, and then a private view

Oh, I see, automagic DNS split horizon.   That does make sense, yes.

---

From: Ralph Droms <[email-masked]>
Date: Sun, 11 Mar 2012 13:25:37 -0400

Suppose that view is on a per-device basis rather than per server?

With something like environment variables in front of "classic" DNS resolution in the host resolver...

- Ralph

---

From: Jim Gettys <[email-masked]>
Date: Sun, 11 Mar 2012 13:27:09 -0400

> With something like environment variables in front of "classic" DNS resolution in the host resolver...

What's the use case for such complexity?  Otherwise, my answer is KISS...
                    - Jim

---

From: Ralph Droms <[email-masked]>
Date: Sun, 11 Mar 2012 13:30:38 -0400

> What's the use case for such complexity?  Otherwise, my answer is KISS...

I think a device will want multiple views...
* network it's currently attached to
* "home" network it's usually attached to
* (OK, so it's Sunday afternoon; I'm busy with other stuff and ran out of other contexts.  Anyone?  Buehler?)

...and avoid split views in the DNS itself and avoid all the questions about what gets published where.

- Ralph

---

From: Ray Bellis <[email-masked]>
Date: Tue, 13 Mar 2012 16:16:38 +0000

> ICANN is now selling "dotless" names. A name without dots has a defined behavior in most DNS resolvers; they find a way to further qualify them. Do we want to humor ICANN, or solve this?

AIUI, the problem is more that on some operating systems a dotless name is first looked up in non-DNS based name spaces (e.g. NetBIOS).  Only if those fail is it considered by DNS, with an optional search suffix.

Hence on any particular network one cannot guarantee that the dotless name won't already exist in some other name space that then masks the (very expensive) DNS-based version.

Ray

---

From: Ralph Droms <[email-masked]>
Date: Tue, 13 Mar 2012 12:23:09 -0400

> AIUI, the problem is more that on some operating systems a dotless name is first looked up in non-DNS based name spaces (e.g. NetBIOS).  Only if those fail is it considered by DNS, with an optional…

"dotless name" == "pay-for-play TLDs" ???

- Ralph

---

From: David R Oran <[email-masked]>
Date: Tue, 13 Mar 2012 12:26:13 -0400

> "dotless name" == "pay-for-play TLDs" ???
Just remember to dot your I(cann)s and cross your t(LD)s.

Sorry, couldn't resist...

---

From: Tim Chown <[email-masked]>
Date: Wed, 14 Mar 2012 15:47:07 +0000

On 13 Mar 2012, at 16:26, David R Oran <[email-masked]> wrote:

> 
> On Mar 13, 2012, at 12:23 PM, Ralph Droms wrote:.
>> 

Well let's hope ICANN don't cash in on .site while xmdns is being defined...

Tim

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Mar 2012 15:00:57 -0400

>>>>> "Tim" == Tim Chown <[email-masked]> writes:

    Tim> Well let's hope ICANN don't cash in on .site while xmdns is
    Tim> being defined...

That was my major comment about the document.
I don't like .site.  Yeah, it's generic enough to work everywhere.
But, I think it will be confusing to the public.  I think that .home
would be better, but all of these are also rather english specific.

Maybe there is an esperanto or lojban speaker that could give us a
better four letter word.  (cause, you know, it will be used in the
context of my f#(#$ .*#$@# is busted!)

---

From: Dave Taht <[email-masked]>
Date: Wed, 14 Mar 2012 12:18:55 -0700

On Wed, Mar 14, 2012 at 12:00 PM, Michael Richardson <[email-masked]> wrote:
>    >> Sorry, couldn't resist...
>

What I have been using has been '.lan'. I've seen it used elsewhere,
too, on private nets, but I have no idea how common it is.

I was surprised to see it was what was used in the
http://www.air-stream.org.au/ wireless net

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Mar 2012 12:18:29 -0700

> context of my f#(#$ .*#$@# is busted!)

You want four letter words? I can give you four letter words...

---

From: Paul Duffy <[email-masked]>
Date: Wed, 14 Mar 2012 15:55:51 -0400

.premise would provide wiggle room for consumer, commercial, or 
industrial sites

On 3/14/2012 3:00 PM, Michael Richardson wrote:
>>>>>> "Tim" == Tim Chown<[email-masked]>  writes:

---

From: Thomas Herbst <[email-masked]>
Date: Wed, 14 Mar 2012 13:00:00 -0700

Not to be pedantic, but would that be .premises?

Noun:A house or building, together with its land and outbuildings,
occupied by a business or considered in an official context.

Rather than 

Noun:A previous statement or proposition from which another is inferred or
follows as a conclusion.

tom

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 14 Mar 2012 16:22:09 -0400

> would be better, but all of these are also rather english specific.
Is .local confusing to the public?  I'm not sure they ever see it
(unless they're running Wireshark).  What they *do* see is a list
of instance names for a given service (as, for example, when adding
a printer from a list).

Just like .local, .site defines a behavior for an xmDNS aware resolver.
That is to multicast the DNS query to port 5353 on FF05::FB.

.site SHOULD NOT be used to name a local unicast DNS TLD.  If
DNS is deployed in your homenet, it seems the cleanest thing is
to get yourself a domain or have your ISP delegate you a zone.  If
some random name is used for your TLD, then perhaps the term
"FQDN" should not be applied to a service in that context.

-K-

---

From: Paul Duffy <[email-masked]>
Date: Wed, 14 Mar 2012 16:28:03 -0400

+1

The latin ".locus" may also work.  ;)

On 3/14/2012 4:00 PM, Thomas Herbst wrote:
> On 3/14/12 12:55 PM, "Paul Duffy"<[email-masked]>  wrote:
>

---

From: SM <[email-masked]>
Date: Wed, 14 Mar 2012 14:11:46 -0700

Hi Dave,
>too, on private nets, but I have no idea how common it is.

See www.icann.org/en/groups/ssac/documents/sac-045-en.pdf

Regards,
-sm

---

From: Dave Taht <[email-masked]>
Date: Wed, 14 Mar 2012 14:36:12 -0700

> See www.icann.org/en/groups/ssac/documents/sac-045-en.pdf

That, in it's own weird way, is confirmation that .lan is widely used
as an internal dns address... :)

For reference, this is how to configure bind9 to not leak a private
.lan or .whatever to the roots.

https://github.com/dtaht/ceropackages/blob/master/net/bind-latest/files/chroot/named/etc/bind/localzones/us.zones

https://github.com/dtaht/ceropackages/blob/master/net/bind-latest/files/chroot/named/etc/bind/master/lan.internal

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Mar 2012 11:31:28 +1300

On 2012-03-15 10:36, Dave Taht wrote:
...
> .lan or .whatever to the roots.

.lan isn't a very good choice IMHO, since it does not imply multiple
segments and routing.

.whatever would be a good choice in so many ways :-)

If we want something fairly neutral which isn't Anglocentric,
how about .ici ("here" in French)?

   Brian

---

From: Jim Gettys <[email-masked]>
Date: Wed, 14 Mar 2012 18:43:27 -0400

> .lan isn't a very good choice IMHO, since it does not imply multiple

It doesn't have that binding in my mind.

We could try .han if you like: home area       network....

Jim

---

From: Tim Chown <[email-masked]>
Date: Wed, 14 Mar 2012 22:48:01 +0000

> .lan isn't a very good choice IMHO, since it does not imply multiple

We should really make this work transparently for the user, so the choice is not important.  They should grasp that devices in their homenet must have unique names within that network, but not be exposed to the .lan, .site, .home or .dave domain used wherever possible.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Mar 2012 11:55:37 +1300

> We should really make this work transparently for the user, so the choice is not important.  They should grasp that devices in their homenet must have unique names within that network, but not be e…

I fully agree; just let's choose something that is neutral and simple when users
do happen to see it.

   Brian

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 14 Mar 2012 22:34:21 -0400

> https://github.com/dtaht/ceropackages/blob/master/net/bind-latest/files/chroot/named/etc/bind/master/lan.internal

Dave,

This is interesting work.  Do you see it expanding to cover the
list of domains described in RFC 6303 and registered by IANA:
http://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xml

Granted, ISPs probably have sacrificial servers deployed but by
also filtering at the CER the bad packets, as Fred said, have to
thread two needles.

-K-

---

From: Evan Hunt <[email-masked]>
Date: Thu, 15 Mar 2012 02:58:03 +0000

> This is interesting work.  Do you see it expanding to cover the list of
> domains described in RFC 6303 and registered by IANA:

BIND 9 covers those by default now.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.