dnssec config sanity check

[Paul B. Henson]

We are getting ready to deploy dnssec, and I'd appreciate a quick sanity 
check on our configuration and key timings to make sure I didn't miss 
anything that would cause things to blow up ;).

Our zone data is maintained in a revision control repository; when 
changes are made there is a process that generates a bind format zone 
file from the data, checks it for syntax errors, compiles, and then 
signs it, at the end reloading the zone into bind with rndc.

Our zones are configured with a 1 hour refresh/5 minute retry/two week 
expiration for zone transfers and a default TTL of 12 hours.

We're using RSASHA256 for both KSK and ZSK, with a keysize of 2048 and 
1024 respectively.

The KSK's are rotated yearly on July 1 at midnight. New KSK's are 
created with a publish date set 1 year in the future, an inactive date 2 
years in the future, and a deletion date of 2 years and 14 days in the 
future. At any given time there are 2 or 3 KSK's being published: the 
key currently being used to sign the ZSK, the key that will be used to 
sign the ZSK starting at the next rotation period, and for 14 days after 
the rotation the key that was previously being used (this 14 day window 
is to ensure enough time to update the DS entries in the parent zones). 
The ZSK's are rotated monthly on the 1st at 12:02am. New ZSK's are 
created with a publish date set 1 month in the future, an inactive date 
2 months in the future, and a deletion date of 2 months and 2 days in 
the future. At any given time there are 2 or 3 ZSK's being published: 
the key currently being used to sign the zone, the key that will be used 
to sign the zone starting at the next rotation period, and for 2 days 
after the rotation the key that was previously being used.

dnssec-signzone is configured to automatically pull the appropriate keys 
from the key directory, and the zones are signed with NSEC3 with a 35 
day validity and 30 minute jitter. After the new keys are generated on 
the first of the month, all of the zones fiels are generated and signed.

The only issue I see is that if there are no updates to the zone in a 
given month (resulting in another signing with a 35 day validity from 
that date), and the master dies on the last day of the month, the slaves 
will have zones which would be good for two weeks based on SOA timings, 
but with signatures that will die off in as little as five days. I don't 
consider that very likely; there are typically updates at least every 
day or two, and if our master died I'm pretty sure we'd have it fixed 
within 24 hours.

Are there any timing issues or edge cases that I'm missing? Thanks in 
advance for any feedback...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768