On Jul 30, 2012, at 13:28 , Ted Lemon <mel...@fugue.com> 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 <j...@apple.com> member of technical staff, core os networking _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet