dnssec config sanity check

[Mark Andrews]

In message <4E8A5412.7050108 at acm.org>, "Paul B. Henson" writes:
> 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). 

Don't ASSUME that the DS will be published in time. Build checks into
your proceedures from the beginning.  e.g.

	Publish and activate July 1. Change DS records July 8. Check
	that DS is published July 15 and set inactivate and deletion
	dates if and only if new DS is published to August 1 and
	September 1 respectively.  If the DS is not publish chase
	up with parent and recheck the next day slipping inactivate
	and deletion dates for a day for each day the DS publication
	date is past July 15.

> 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
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org