+1 to everything Curtis said here. I will amplify one point: DNSSEC trust anchors can be configured when shipped (and are in fact included in every BIND 9 release, though they're not trusted unless you say so in named.conf).
The only trust anchor you really need is the key for the root zone, and optionally for a DNSSEC Lookaside Validation zone such as dlv.isc.org, and both of these can keep themselves up to date using RFC 5011 trust anchor management. Depending on how things are set up on your network, you might want to have your system automatically generate a key for .local or .lan or whatever you call the private namespace, but that shouldn't be necessary in most cases. This is fiddly, but it's not hard -- my ISCwrt router at home meets more-or-less all of these needs using BIND 9 and ISC DHCP. On Sat, Jun 30, 2012 at 10:27:43PM -0400, Curtis Villamizar wrote: > 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. -- Evan Hunt -- [email protected] Internet Systems Consortium, Inc. _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
