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

[Kerry Lynn <[e-mail]>]

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.

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

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

> 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)
>
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet