All,

In case anyone is interested, the bind 9.7 releases have made some 
improvements to the workings of DNSSEC zones which greatly improve the 
experience, but it's sadly not that well documented.

I thought I'd write up a brief summary of what I've found. This is 
limited to the mastering & signing of DNSSEC zones; there are also 
enhancements for managing DLV and other keys, but they're pretty simple.


== Signature management ==

The important option is "auto-dnssec maintain" on a zone. In my testing 
I used:

zone "test.local" IN {
         type master;
         file "data/zones/test.local/zone";
         auto-dnssec maintain;
         key-directory "data/zones/test.local";
         allow-update { nsg; };
};

This puts the zone file & keys into one per-zone directory, and tells 
bind to read and honour key metadata for the keys found in that directory.

It looks like future plans include automatic generation of new ZSK and KSK



== Signing the zone initially ==

This is really very easy; simply generate a KSK and ZSK, put them into 
the zone key directory, and issue "rndc sign":

   cd /var/named/data/zones/test.local

   # alternatively, use the "-K keydir" option to the following:
   dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 \
    -n ZONE -f KSK test.local
   dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 \
    -n ZONE test.local

NOTE: at this and ALL OTHER points after manipulating the key files, you 
need to make sure they're readable by bind. By default, it sets the 
perms 0600 on the private key, and re-sets these every time you modify 
the key - irritating if you want them owned by root.named and perms 
0640, which seems rather more secure.

Then do:

   rndc sign test.local

...and that's it. Easy.

This seems to work pretty well with large zones. The zone is signed in 
pieces, and the SOA increments slowly(ish). You can do concurrent DDNS 
updates at the same time; they'll be signed as the process runs.

As far as I can make out, bind first goes through and builds the NSEC 
chain, then walks the NSEC chain and signs it and the related RRs.

Performance on a moderately recent desktop PC (dual-core 2.4GHz PC with 
slow-ish SATA disks) seems to be ~450 signatures/seconds, so make of 
that what you will for timings.

There may still be advantages to signing the zone initially with 
dnssec-signzone - specifically you can use the "-j" option to set the 
jitter of the signatures, and spread the subsequent re-signing out.


== Rolling over the ZSK ==

1. Generate a new ZSK in the key directory with a publication time of 
"now" but activation time "unset":

   dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 \
    -P now -A none -n ZONE test.local

   rndc sign test.local

...the new DNSKEY should now be at the apex of the zone, but will not be 
used for signatures.

2. You should then wait sufficient time for the old DNSKEY RRset to 
expire from caches, before starting to use it for signing.

3. To start using it for signing, simply activate the new key and 
deactivate the old one:

   dnssec-settime -A now Ktest.local.+005+<newkeyid>
   dnssec-settime -I now Ktest.local.+005+<oldkeyid>

...future DDNS update into this zone will be signed by newkeyid and not 
oldkeyid. You then need to wait for bind to automatically re-sign the 
zone as the RRSIGs expire; this happens according to the 
"sig-validity-interval".

4. You can force bind to remove the old key and re-sign any records with 
that key at any time with:

   dnssec-settime -D now Ktest.local.+005+<oldkeyid>
   rndc sign test.local

...but obviously should not do that until step 2 (cache expiry) has 
occurred, else remote caching servers might have your old DNSKEY records 
and not be able to validate the new RRSIGs. It might be slow as well...

Be VERY VERY careful with this command. It *will* let you remove the ZSK 
from the zone, at which point it'll re-sign the zone with the KSK which 
is very much NOT what you want.

=== Rolling over the KSK ===

This is even easier:

1. Generate a new KSK:

   dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 \
    -n ZONE -f KSK test.local

2. Ensure the permissions are ok and instruct named to read it:

   rndc sign test.local

3. Generate the DS or DLV records & send them to the relevant people:

   dnssec-dsfromkey Ktest.local.+005+<newkeyid>.key
   dnssec-dsfromkey -l dlv.isc.org Ktest.local.+005+<newkeyid>.key

4. Wait for the suitable amount of time

5. Remove the old KSK and re-sign

   dnssec-settime -D now Ktest.local.+005+<oldkeyid>
   rndc sign test.local

Again, be VERY VERY careful with this, it will let you remove the last 
KSK from the zone, and that would (I imagine) cause serious problems.


The major piece of magic seems to be the extra metadata stored in the 
bind private key files for creation, publish, activate, inactive and 
delete dates, and the ability of the bind online (re)signing process to 
honour them, and the dnssec-settime command to manipulate them.

All in all, it's a big improvement over the previous versions.