Re: [homenet] tunnels as way to disambiguate .local

On Mon, Aug 6, 2012 at 9:39 PM, Evan Hunt <each@isc.org> wrote:
> On Mon, Aug 06, 2012 at 04:33:49PM -0400, Michael Richardson wrote:
>> No, the fridge must have a globally reachable address (GUA) to be reachable.
>
> You are correct, of course, and I was being unclear; sorry about that.
> I was trying to reflect what I thought I heard in the discussion in
> Vancouver, though, which was that a FQDN or the equivalent would be the
> best way to handle naming of remotely accessible devices.  It seemed to
> me that we had rough consensus on that point (perhaps I was mistaken),
> but not on naming of devices on "island" networks.
>
>> Tunnels are okay, but to use them, but has to get the DNS search order
>> and the DNS server list right, and that's walled garden territory.
>> *If* we are going to turn each home into a walled garden, then let's be
>> aware that we are doing that.
>
I'm of the opinion that in a "walled garden" scenario, the tunnel endpoint may
be the only resource that needs a global name / address.  I note that dyndns
supports a wide-area DNS-SD beta (ability to populate PTR, SRV, and TXT
RRs) and I'm going to look into this approach as an alternative to BTMM.

> For the purposes of my mom's house, I do think "walled garden" is the
> appropriate default setting, but our design should allow the default
> to be overridden without great difficulty.
>
I am generally supportive of this approach; certainly it would focus the
discussion between now and Atlanta.

> I think this general plan would meet those goals:
>
>     1) All discoverable devices on all networks MUST answer
>        to a locally reachable name, such as <devicename>.local,
>        <devicename>.sitelocal, <devicename>.<networkname>.local,
>        <devicename>.<ULA>, <devicename>-<ULA>.local, etc. (We
>        haven't settled the naming convention here. I personally like
>        <devicename>.<networkname>.local, with <devicename>.<ULA>.local
>        as a fallback in the event of the network's owner failing to
>        configure a network name);
>
+1, with the caveat that ".local." has special semantics (multicast
DNS-like requests to FF02::FB, port 5353) defined by
http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns

>    2) Networks configured to allow remote access to devices
>       SHOULD have a globally reachable domain name, either owned
>       by the user or in a vendor-managed namespace;
>
I'd like a bit more explanation re: this requirement.  In general it seems
there is no relation between a network and a domain name.  Exceptions
would include ".local." (maps to the local _link_, and therefore to the
prefix(es) assigned to that link; or domains ending in ".in-addr.arpa.".
http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd section 11 has
a method for determining the preferred registration zone(s) based on
a host's address.

>    3) If a device is configured for remote access and is on a
>       network which has had a FQDN configured as in (2), then
>       in addition to the locally reachable name described in (1),
>       the device MUST also answer to "<devicename>.<FQDN>".
>
I like to see us reserve "FQDN" for host names that are registered in
the global DNS namespace, and use "LQDN" (or some other alternative)
for host names in locally served zones.  Any support for this?

-K-

> --
> Evan Hunt -- each@isc.org
> Internet Systems Consortium, Inc.
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet