On Mon, Jul 30, 2012 at 7:06 PM, Michael Richardson <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
