In message <[email protected]> Michael Thomas writes: > On 06/29/2012 08:34 AM, Ralph Droms wrote: > > > > a) Homenet name-service MUST NOT interfere with Internet name-service > > "Internet name-service"? Do you mean "DNS"? "Co-exist" might be a > > better word. Users want a single interface into naming and don't > > want to have to differentiate between "naming stuff on my local network" > > and "naming stuff in the Internet". Ted Lemon raised this issue much > > more eloquently during the WG meeting. > > > > I'll add my first bullet here, rephrased a little: > > > > a.1) Relative name resolution: some naming convention that allows name > > resolution while mitigating the need to know an absolute location in the > > Internet name-service > > > >> b) Homenet name-service MUST NOT be in Internet name space. > > How are things in the home identified from outside the homenet? > > > > Maybe I can add some fuel to Olafur's fire. I'd like to say that the > homenet name service MUST be DNS.
+1 > This may sound like heresy, but here's my reason: I want the ability > to transition from a private name space to a public name space with > minimal fuss. I don't want a different naming mechanism that has > its own oddities just because I can't think up a clever domain name > for my home net that goes into the global DNS when I'm forced to > install my router. When I'm finally inspired, I want to be able to make > that transition and then worry about the split horizon implications > (if I even get around to caring about such a thing). > > So perhaps, we can make use of statistically unique naming to keep > things from bumping into one another, etc... this is sort of off the cuff, > but the real point is not having to transmogrify one naming scheme into > another. Yuck. > > Mike > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet I'm not sure that some of the respondents later in this thread understand what DNS can do already with no changes. 1. An important domain that is visible to the outside world can also remain available even if the Internet is not available. Local hosts which use DHCP can be told to query a local DNS cache. That DNS cache can be a DNS secondary (or primary) to your enterprise's domain, or a local domain. As a primary, it never expires. As a DNS secondary it can continue to serve DNS queries for the domain when the Internet is unavailable until the zone file expires (typically days). Example: In every well run enterprise today, the local DNS caches are DNS primary or DNS secondary for the local domain. 2. A local domain can be either visible to the Internet or not visible. It is also possible to provide different results locally and to the Internet. You can create a .local domain that can't be reached except by The NS record available to the outside world can point to a different nameserver than the set of nameservers for that same domain that are used internally. This gets annoying for remote users when switching the enterprise VPN on and off, but otherwise it works just fine. [btw- An alternate that avoids the VPN issue is to create site specific subdomains that are not visible to the outside world.] Example: Most enterprises reuse their domain internally, serving up their name resolutions to private addresses, but only provide the name resolution for the hosts with global addresses to the outside world. 3. Devices can already register their own host name to IP address mapping. Dynamic DNS is far from a new concept. A DHCP client can provide its own host name when retrieving an address. The DHCP server can be coupled to a DNS cache which adds the forward (and optionally reverse) DNS mappings to the appropriate zones until the DHCP lease expires. Example: ISC dhcpd and ISC bind can be coupled in this way. [Not intended as an endorsement. No doubt many others can as well.] Others have suggested DNSSEC. That may conflict with the zero configuration goal unless a trust anchor is supplied at shipment time. Zero configuration and the existing cert hierarchy seem to me to be conflicting goals, but I'd be open to being told otherwise. The "zero configuration" goal implies that the default configuration for the homenet router in isolation (no other routers discovered) must be to serve as a DNS cache, offer a .local domain, and add an entry into the .local domain for any DHCP lease allocated. If other homenet routers are discovered, then some form of election is needed to figure out a DNS primary for the .local domain. One could argue that the homenet router could also get a proper domain name from the provider, but most providers will give their domain name in response to DHCP queries. If the provider is know to provide a useful domain name, then trusting the domain offerred by the provider can be a simple configuration override. Simple configuration could substitute a real domain name for the .local default name. Whether to supress providing local mappings to external queries could also be a simple configuration knob. We need a extremely strong motivation to reinvent the wheel on something as fundamental as name resolution. I don't see that we have any unmet requirement that can't be solved using DNS as the basis. I admit that we can't use any of the existing freely available DNS server software (that I am aware of) because it does not do anything useful in the absense of configuration and configuration is overly complex for homenet use. Curtis _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
