On Tue, Jul 31, 2012 at 1:42 PM, Michael Richardson <[email protected]> wrote: > >>>>>> "Kerry" == Kerry Lynn <[email protected]> writes: > >> When I'm at your house, and I visit "fridge.local", do I get your > >> fridge, or mine? > > Kerry> Mine, by definition. Given that I'm not sure how you mean > ".homenet" > Kerry> to work by comparison, I'm not sure I completely understand the > rest > Kerry> of the discussion. > > Yes, I agree that when I lookup "fridge.local", I'll get yours. > *unless* the mapping to a GUA is still in my browser's cache... > I haven't tried the scenario you mention, and since I'm not home it will be a while until I can...
> (I deleted a realistic situation for my smartphone talking to my stove > to find out when the roast is done) > > So what I'm after is a way for the fridge to say, when I lookup > "fridge.local" that it's GUA is 2001::F001 (mDNS can already do this), > but also that it's unicast DNS name is fridge.kerlyn.com. > Now I am starting to get what you mean. If you have a unicast DNS service deployed in your home you can populate it with specially named PTR records to indicate preferred registration zones (see section 11 of http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd). I guess in theory these names could also be discovered via mDNS. > Kerry> If you are remotely accessing resources in your home, you are > probably > Kerry> more advanced than 99% of all home network users. Why wouldn't the > Kerry> solution you use on the road apply equally well at your > Kerry> neighbor's house? > > Kerry, the point of end-to-end connectivity into the home is to permit > the things that us "1%" do, to be doable by everyone... Right? > Sure, but we shouldn't break things that already work, nor require additional configuration hassles for ALL users. It should be made relatively painless to introduce new functionality. What I'm trying to figure out is whether most people in these conversations are envisioning a unicast DNS service in the home that has a "locally defined" zone, as opposed to mDNS which *distributes* the name service. One way in which the latter may be deployed may be to have some "agent" that listens to mDNS announcements and then enters RRs into a unicast DNS. This still doesn't buy us FQDNs, however, unless the DNS has a delegated zone. > So, yes, dyndns is *a* solution, but I don't know how to automate it in > a scalable way. I'm concerned that for the homenet protocols to be > incrementally deployable ("create value") that we can not rely too much > on the ISPs doing the right thing for forward DNS delegation. > So you want to remotely access hosts in your residence, but without configuration of any sort? > Kerry> I think defining new "zones" under .arpa. may have merit in the > following > Kerry> respect: ICANN is now in the business of selling dotless > Kerry> domain names. > > Just to be clear: my idea isn't that IETF run a dyndns under arpa, but > that we have a WKN under arpa which is treated specially. > Right. And even though, in theory, we are able to request new TLDs from ICANN that warrant special semantics, this hasn't yet been attempted to my knowledge. > I understand that my idea is hard to evaluate without a document. > Should I write one then? > I'd support seeing more about naming/service discovery in homenet drafts as opposed to the mailing list. -K- > -- > Michael Richardson <[email protected]>, Sandelman Software Works > > _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
