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
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
