Bind 9.9.x operation with dnssec

[Spain, Dr. Jeffry A.]

> With "auto-dnssec maintain", I expect the Zone Signing Keys and the individual RRSIGs to be completely managed and rotated as needed by bind, per https://kb.isc.org/article/AA-00626/0/Inline-Signing-in-ISC-BIND-9.9.0-Examples.html
and the Admin Reference, however, at the end of 4.9.7, it says:

> "By default, this rollover completes in 30 days, after which it will be safe to remove the old key from the DNSKEY RRset."

> This implies that I'm going to have to go in and do housekeeping in the keys directory, though I'm not sure when - I set this up in early March (according to the key activation comments - who remembers details that far back? ;-) ) and they haven't rotated yet...

I don't think you will need to do any housekeeping if you have your key timing metadata set up in a reasonable way. There are four relevant timestamps in the metadata: Publish, Activate, Inactive, and Delete. You can see this by listing the contents of your *.key files. My practice with ZSKs, which has been successful over the past year, has to been to generate a series of nine ZSKs with timing metadata computed from the following:
* Choose an inception date for DNSSEC operations, for example, today.
* Choose an active lifetime for the keys (90 days for me).
* Choose an introduction time, the number of days prior to activation that a key is published. (4 days for me).
* Choose a retirement time, the number of days after inactivation that a key is deleted (35 days for me. This needs to be at least 30 days, as you stated above, to allow record sets to be resigned with the new key as the old signatures expire.)
* Choose a rollover time, the number of days from activation of a key to inactivation of its predecessor (1 for me).

Rather than go through the computation process, see the attached dnssec-keyset bash script that sets the timing metadata appropriately for each key. For example you might run:
./dnssec-keyset 90 4 35 1 raindrop.us 9

For the KSKs, I have been using active lifetime 720, introduction time 7, retirement time 35, rollover time 7, so for example:
./dnssec-keyset -k 72- 7 35 1 raindrop.us 2

> When it comes to the DS records registered at the registrar, I'm not sure where that comes from: the only way I can see to get it is to do a DS query from the nameserver (and at least one document basically said that).  First, I'd like to know where it comes from, and second, it seems much too small, given ksks are supposed to be bigger as a result of being longer lived.

You would use the dnssec-dsfromkey utility to generate your delegation signer (DS) record data. The attached dnssec-keyset script shows how this fits in. The DS data is a digest of your public key. Its length depends on the digest algorithm you specifiy, typically SHA1 and/or SHA256. The digest length is fixed and not related to the length of your public key. The authenticity of your DNSKEY records is therefore predicated on the fact that the DS record is signed by the parent zone and the likelihood of a digest collision with two different keys is vanishingly small.

> When it comes time to roll the DS key, it looks like I pick a lifetime, say 3 months, generate a new DS key (how, such that 9.9.x will use it?

When BIND 9.9 rolls over your KSK, you need to have anticipated that and have published your new DS record in the parent zone prior to that. My practice has been to generate two KSKs, both of which are published but only the first of which is active, and to publish both DS records in the parent. As I understand it, there is no significant security risk to publishing a public key that is not being used for signing.

> Next, I have a DS record configured at my registrar obtained with dig from my nameserver, but that doesn't seem to be right...

Again, use the results of dnssec-dsfromkey. Typically you will enter this on your registrar's website. You will need the key identifier, algorithm, and DS data field.

I hope this is helpful. This is complicated. It took me quite a while to understand, and I still don't get it completely. However, inline-signing can be made to work well for you and pretty much automatic once you set up a proper series of keys with appropriate timing metadata. 

Regards, Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dnssec-keyset
Type: application/octet-stream
Size: 4837 bytes
Desc: dnssec-keyset
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120602/5544e83e/attachment.obj>