On Wed, Aug 08, 2012 at 08:32:01AM -0400, David R Oran wrote:
> Yes, and a fairly hard one given the manual/administrative nature of
> domain registrations and the geek factor of secure dynamic DNS
> updates for all services to the global DNS.
What is this "geek factor" whereof you speak? Once you have a name
registered, registered your service with a service like dyn.com's
DynDNS service, and told your gateway about it, everything else Just
Works. I know this mostly because I know people who don't know
anything about what they are doing, but who are able to navigate this
far.
What probably is true is at least the following:
1. Many people don't want to pay for (thereby use) their own
name, and don't want to pay extra for a service like this. Dyn
and (I believe) some of its competitors have free services of this
sort, but they're somewhat restricted in what they can do. (Still,
you can do this today when you buy shipping product from some
vendors, without doing a single extra thing.)
2. Registering DNS names and somehow hooking them up to edge systems
remains hard. DNSOP is actually investigating this problem, but
maybe this WG ought to collaborate on that.
3. Split-horizon DNS isn't that reliable, and tends to leak.
4. Trying to make this work smoothly with .local addresses is probably a
good way to cause confusion
For what it's worth, after the discussion in Vancouver I went back to
colleagues at Dyn to ask about previous work on standardizing what I
might call the CPE-to-DNS-provider link, as I was pretty sure there'd
been previous work. Indeed there had, and I'm attempting to dust it
off. If we're serious about systems inside our target networks being
somehow addressable from the global Internet, then it seems to me a
mechanism to integrate easily to the global DNS without requiring
major lock-in (or major upgrade of DHCP) is going to be something
we'll have to tackle.
> Much as it would be great for Homenet to solve this problem and get
> a lot more functionality for users, this may be a bridge too far for
> the current work, which is focused on getting routing and naming
> INSIDE the home seamless and completely auto-configuring.
If, on the other hand, we are in fact going to limit our scope to
inside the home network (and what problem is it, exactly, that we
have? My network can already do this, I think?) then of course the
above is just needless extra work.
> I think the problem of disambiguating names of resources in the home
> has to be dealt with to prevent users whose devices are mobile from
> violating the principle of least astonishment. I don't think the
> ability to resolve names of home resources from anywhere on the
> Internet has to be solved in order to solve the disambiguation
> problem.
I think that's a little optimistic. As soon as you have the problem,
"The name in context X is the same as in context Y and I want to be
able to tell the difference when I cross context," you are already in
Internet land. That's an interoperation problem, at least from the
user's point of view.
Best,
A
--
Andrew Sullivan
[email protected]
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
