Reverse DNS RFCs and Recommendations
bjorn at mork.no
Mon Nov 4 12:45:58 UTC 2013
Mark Andrews <marka at isc.org> writes:
> That said it is possible to completely automate the secure assignment
> of PTR records. It is also possible to completely automate the
> secure delegation of the reverse name space. See
I like that. I'd really like to see CPE vendors implementing it.
AFAICT, it is perfectly possible to apply that on top of the idea you
had about letting TCP clients update their own key. CPEs supporting the
DHCPv6 option will use that, while the others still have the ability to
add a KEY record from a TCP client in the deletated prefix. As long as
you let TSIG signed updates trump anything and do not allow unsigned
updates if there is a KEY, then these should work just fine together.
But I believe the draft could use a couple of clarifications to avoid
CPE generates DHCPv6 Prefix Delegation [RFC3633] request which
includes a KEY-RDATA option (code point TBA) which contains a the
rdata of a DNS KEY record containing a RSASHA256 key using the public
components of the previously generated RSA key pair.
Is this new DHCPv6 option to be placed under OPTION_IA_PD, or is it a
"top level" option? I.e. will it be possible to set different keys for
(the theoretical) multi-prefix requests?
We've already seen confusion wrt placement of the OPTION_DNS_SERVERS, so
it is important to explicitly state where such options, which may be
considered local to part of the DHCPv6 message, belong. I do know that
RFC3315 is clear on the default:
Unless otherwise noted, each option may appear only in the options
area of a DHCP message and may appear only once.
But experience with OPTION_DNS_SERVERS has shown that this is not
enough. Pleace be explicit about where in the packet any new DHCPv6
CPE device generates DNS UPDATE [RFC2136] which delegates the reverse
name space to itself and others if they have been configured. The
CPE uses SIG(0) [RFC2931] to sign the request with owner name
matching the reverse of the delegated prefix.
This could use a few examples and clarifications wrt the owner name. I
interpret it as:
IA_PD = 2001:db8:1::/48 => owner name = 184.108.40.206.8.b.d.0.1.0.0.2.ip6.arpa
But what about for example IA_PD = 2001:db8:2:4::/62 ? Are you going to
add multiple owner names, or should there be some rule here allowing
multiple delegations with a single owner name for PD on non-nibble
boundaries? For example
IA_PD = 2001:db8:2:4::/62
=> owner name = 220.127.116.11.18.104.22.168.8.b.d.0.1.0.0.2.ip6.arpa
allowed to update:
(not that I would ever consider delegating prefixes on anything but
nibble boundaries, but someone else might - and the draft should
consider this possibility)
More information about the NANOG