Reverse DNS RFCs and Recommendations

Mon Nov 4 20:16:22 UTC 2013

In message <87iow8tjw9.fsf at nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
> 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?

As far as I cans see there is no point in using different key RDATA.
All it does is introduce key management problems.  I expect a CPE
to only use a single public key for all prefixes that are delegated
to it.  That said we should look at rolling the key.  CPE replacement
etc.

> 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

The DHCP server would add multiple KEY records each with the same
RDATA.  This would still be a single DNS UPDATE transaction. A non
nibble aligned PD results in multiple delegations in the DNS.

The CPE would perform multiple DNS UPDATE requests, one for each
delegation.

Doing it the other way would require telling the nameserver the
nameserver that key A is allowed to update B, C and D as well.

With multiple keys each one is self describing about what it can
update.  In terms of named's update policy you would just add this
grant clause to the zone configuration on the master to allow the
CPE to add/update the delegation.

		update-policy {
			grant * self *;
		};

> (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=C3=B8rn
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org