In message <[email protected]> james woodyatt writes: > On Jul 30, 2012, at 13:28 , Ted Lemon <[email protected]> wrote: > > > > The work's already started in the dhc working group: > > > > <http://tools.ietf.org/html/draft-lemon-dhc-dns-pd> > > > > I'd be curious to hear your feedback on this draft. > > That's a good submission for the DHC group. > > I'm thinking I'd much more like to see a specific recommendation that HOMENET > gateways implement a site-managed reverse tree, optionally augmented with a > zero-configuration method for generating content explicitly managed by a > knowledgeable home network administrator. > > For example, after I install a fresh HOMENET gateway in my new house, I > expect the following things just to happen correctly without any forethought: > > 1. The integrated DNS content server should have authority for all of the > ip6.arpa corresponding to the IPv6 prefixes delegated by its service provider; > > 2. The integrated DNS resolving server should answer [on the local network > only] for the locally generated ULA prefixes required by RFC 6106. > > 3. Queries for PTR records in zones for which it's authoritative should > always produce a synthesized answer if no explicitly configured records are > stored in the content server. > > For examples, > > 3a. dig -x fd35:5a4b:92a9:fb::1 -> > fd35-5a4b-92a9-fb--1.local. > > 3b. dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc -> > 2001-5a8-4-2290-a95f-dd2e-3201-eafc.subscriber-3021134.example.net. > > 4. I should be able to override explicitly the domain automatically delegated > by my service provider with my own registered FQDN if I want to do so, so > that example 3b above becomes: > > 3b.(2). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc -> > 2001-5a8-4-2290-a95f-dd2e-3201-eafc.conjury.org. > > 5. I should be able to override explicitly the automatically generated FQDN > for any hosts on my network if I want to do so, so that examples 3a and 3b > above become: > > 3b.(3). dig -x fd35:5a4b:92a9:fb::1 -> > zardoz.local. > > 3b.(4). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc -> > zardoz.subscriber-3021134.example.net. > > 6. I should be able to do both. > > 3b.(5). dig -x fd35:5a4b:92a9:fb::1 -> > zardoz.home.conjury.org. > > 3b.(6). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc -> > zardoz.conjury.org. > > Yes, I get that DNSOP people don't like to contemplate this problem. I don't > want to debate about why I think they're wrong to defer it, but my thoughts > aren't all that different from those of anyone else in the > application/security community. Can we skip past the part when I enumerate > them again? > > I guess I had hoped the HOMENET group would more easily find consensus around > addressing this promptly, but that may have been wishful thinking. > > > -- > james woodyatt <[email protected]> > member of technical staff, core os networking
I agree with 99.8% of this. s/\.local/.sitelocal/ and allow a home network to be routed and then I agree with 100% of this. I think you could add to the above that the provider should offer to delegate a forward zone and a reverse zone via DHCP extension and offer to provide DNS secondary for those zones. Note that draft-lemon-dhc-dns-pd doesn't go that far (offering a forward zone name to use), but it would be a useful addition. It would be nice if the customer router could request that the provider secondary also pick up a zone allocated to the site by a registrar. The provider router can verify this by looking up the NS records for that zone and determining that the A or AAAA for at least one of the existing nameservers falls with the static address allocation of the site. This would be for advanced users and the advanced user (or a sufficiently advanced DHCP/nameserver coupling) could then update the list of NS records adding the provider secondary. Again draft-lemon-dhc-dns-pd doesn't go that far. The provider side would have to be able to offer to secondary for both a zone offerred by the provider and offer to accept a zone name in a DHCP response (with verification against NS records). No zone name in the response could imply acceptance of the provider offerred zone or it could be explicitly accepted. Given the support for these extensions in a provider side DNS nameserver and support for these extensions in at least a subset of home routers, this can all be automated such that there is no real work for DNS ops. The worst that can happen is the provider becomes a DNS secondary for bad-name.example.com but can easily identify the perpetrator and in a manner of their choosing the provider can bludgeon said perpetrator with their AUP. As long as funny-characters+code.example.com or really-long-name+code.example.com doesn't cause some resolvers to crash or run code, then there is no harm in bad-name.example.com. Curtis _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
