In message <[email protected]> Andrew Sullivan writes: > 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
One solution, the one you are describing is where the CPE runs DHCP only and uses the dyndns protocol to make addresses available globally. Another solution is have the CPE run both DHCP and bind (or equiv) and run dyndns. The provider could delegate and secondary a subdomain of the provider with no need to contact a domain registry. When a domain registrar is needed is only when the homenet needs or wants (maybe for ego reasons) a domain residing in a TLD (such as .com or .org) and would not accept a subdomain from the provider. For example the homenet user wants foo.com and would not accept something of the form foo.site.provider.com, which would be less permanet (the delegation is lost if switching providers). Curtis _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
