Reverse DNS RFCs and Recommendations

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
> http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00

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
interpretation bugs:

   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
options belong.

   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 = 1.0.0.0.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 = 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
              allowed to update:
                         4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
                         5.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
                         6.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
                         7.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

(not that I would ever consider delegating prefixes on anything but
nibble boundaries, but someone else might - and the draft should
consider this possibility)

Bjørn