Re: [homenet] how to bookmark .lan, /.home, /.my-homenet when not home

[Curtis Villamizar <[e-mail]>]

In message <CABOxzu1xoH9YbStyULeqpqQ8jdNFD0f0RgfbRjSPBEOvEt80=[e-mail]>
Kerry Lynn writes:
 
> On Mon, Jul 30, 2012 at 7:06 PM, Michael Richardson
> <[e-mail]> wrote:
> >
> > while reading drafts on the airplane, I have come to think that picking
> > any specific name a la ".local" for the homenet name service is fraught
> > with RFC1918-like confusion.  For the actual printer and refridgerator
> > (which does not move, but needs to talk to the TV) it's not a big deal,
> > but for mobile devices, I think it's gonna lead to confusion.
> >
> Michael,
>  
> For those of us familiar with
> http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns the
> continued use of ".local." in these threads is leading to some
> confusion, as we synonymize this with using Multicast DNS (mDNS)
> instead of Unicast DNS.
>  
> As was noted in a previous thread, "Special-Use Domain Names" has been
> approved as a Proposed Standard:
> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg10435.html
> The mDNS draft places ".local" in this category and specifies:
>  
>    that the DNS top-level domain ".local." is a
>    special domain with special semantics, namely that any fully-
>    qualified name ending in ".local." is link-local, and names within
>    this domain are meaningful only on the link where they originate.
>  
> > When I'm at your house, and I visit "fridge.local", do I get your
> > fridge, or mine?
>  
> Mine, by definition.  Given that I'm not sure how you mean ".homenet"
> to work by comparison, I'm not sure I completely understand the rest
> of the discussion.

I am not a fan of mDNS but avoiding conflict with mDNS is a good thing
and since this is decided one course of action is to define a
sitelocal.

The intent here is to allow routing within a site, not just bridging.

With ULA the problem that link local addresses are not supposed to be
routed is solved.  ULA avoids the issue of site boundaries that made
IPv6 site local addresses get depricated (a good thing IMHO).

It then becomes necessary only to coordinate the sitelocal domain
among router on the site and avoid leaking among sites.  This is
easily accomplished if the provider router offers a global routable
prefix and refusing to become part of or recognize the DNS site.

The issue is what happens when *my* fridge is not on the same home
subnet as *my* home computer.  (Sustituting a more realistic example,
like thermostats, water heater, alarm system, etc, where temp/time
profiles might be altered, but we'll stick with the fridge example).

> > Assuming I want mine, if I've discovered it when I was
> > at home, how would I bookmark and remember it, assuming it had a GUA?
> >
>  
> If you are remotely accessing resources in your home, you are probably
> more advanced than 99% of all home network users.  Why wouldn't the
> solution you use on the road apply equally well at your neighbor's house?
> (I'm thinking here of services like dyndns.)  You simply put the domain
> in which your fridge is registered earlier than ".local." in your DNS search
> path, no?  If all else fails, put it in /etc/hosts?

A separate issue is how to address the fridge from a computer at work
or a mobile phone where clearly neither are on the same site.  Here a
domain name has to be assigned and most likely something of the form
<subdomain>.<provider-fqdn> if there is not going to be a registration
fee.  The subdomain might be the same as the email address provided by
most home providers or <email>.site.<provider-fqdn>.  At worst the
mobile phone would need to have <email>.site.<provider-fqdn> in the
DNS search path so "fridge" can be resolved.

The sitelocal name then only serves a purpose when the site is not
connected to the provider and doesn't know its domain name.

> > I therefore propose adding a level of indirection (because that solves
> > every problem....), which (mobile) hosts will ideally become aware of.
> >
> > I think of this as a layer above the current LLMNR/mDNS/Bonjour++ layer.
> >
> > My idea is that the .homenet/.local discovery protocol would, in
> > addition to the AAAA ULA or GUA record, would provide a reference a
> > unique name which might not be globally resolvable from the DNS root,
> > but can be resolved by arrangement.  This would be not unlike
> > split-horizon DNS, but given IPv6 reachability, no VPN necessary.
> >
> > For sites where mglt-name-delegation works, great, use that!
> > For those where this doesn't work,  we need a new well known name.
> > Perhaps it can find a "logical" place in arpa.   Let's say it's based
> > upon the ULA, and the home with prefix A:B:C:D gets
> > D.C.B.A.homenet.arpa.  (add this to DNS search path...)
> >
> I think defining new "zones" under .arpa. may have merit in the following
> respect: ICANN is now in the business of selling dotless domain names.
> Despite the fact that there are many grandfathered special domain names
> (including .local.) nobody that I know of has yet attempted to allocate a
> new one.  Defining new special use names under .arpa. may be a way of
> allocating them within IETF's authority, without approval from ICANN.
>  
> Note also that http://tools.ietf.org/html/rfc6303 defines a registry that is
> apparently similar to special-names (at least there appears to be some
> overlap):
> http://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xml
>  
> Regards, -K-

A local router which provides DHCP can offer itself as a DNS resolver
and effectively become primary for the /128 of any inaddr for any ULA
within the site, returning the <hostname>.sitelocal address or the
<hostname>.<domain> address depending on whether a domain for the site
is unknown or known (either configured or learned).

If the provider offers a routeable address and a domain, then the
provider should also delegate both the forward domain and rDNS.  Of
course it would be real nice if the provider also offered a DNS
secondary and updated the NS record if it was accepted.  The site
router would then have to allow zone transfers to that secondary.
This is a fair amount of code that isn't written, but requires very
little more than 1) some extensions to DHCP and 2) a BCP to say that
this is a good idea and 3) the blessing to use sitelocal in this way
if no domain is configured (since local is defined to be linklocal).

draft-lemon-dhc-dns-pd-01.txt covers a lot of 1) above (some
extensions to DHCP).  It does not provide a means for the provider to
offer to be DNS secondary and that might be a usefule addition.

> > When an application resolves fridge.local,  if the fridge has a GUA
> > which it has provided to the CPE's DNS server,  then it also returns a
> > pointer to the "long-term name" (probably in a new RR) like
> > "fridge.D.C.B.A.homenet.arpa". Any bookmarks and the like would contain
> > that address (HTTP/HTML has existing mechanisms to deal with this),
> > other applications might see this as the canonical name. (getaddrinfo(3)
> > already has a canonname)
> >
> > My idea is that given IPv6 reachability for the HOME's CPE(s), that a
> > mobile recursive (secure) DNS resolver can learn to make queries for
> > D.C.B.A.homenet.arpa. directly to the home CPE, even when the mobile
> > device is not "at home".
> >
> > The mobile device needs to be "pair"ed with the CPE such that it agrees
> > to do this side-ways lookup.   It's pretty much identical to a windows
> > desktop joining an AD (but I can't speak to the "home edition" being
> > able to do that... don't do windows).
> >
> > This process is, I admit, a form of walled garden DNS, something I've
> > argued against as being unnecessary.  I'd rather that the ISPs provided
> > a name, but I feel that ISPs won't be very fast to offer this, and for
> > the home user with no native IPv6 (using a managed tunnel, for
> > instance), that a protocol such as I am suggesting, would provide a
> > clear value (something people would brag about to their friends...)
> > without requiring people to "wait" for their ISP.
> >
> > This does not replace "fridge.local" referring to the fridge on the
> > network that you are on, but it does provide a way to easily discover
> > and then bookmark "my fridge".
> >
> > (written offline using xemacs on android)