dnssec config sanity check
Paul B. Henson
henson at acm.org
Tue Oct 4 00:32:18 UTC 2011
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
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
More information about the bind-users