dnssec config sanity check

[Paul B. Henson]

On 10/5/2011 10:25 AM, michoski wrote:

> Your initial hope is what I missed comments on...

Me too; didn't get any "that's horribly broken because" or any "that
looks good" feedback, guess I'll just have to review it a couple more
times and hope for the best.

> "It is recommended that the transition of a KSK from the published
> state to the ready state (introduction time) lasts for 45 days (RFC
> 5011, Automated Updates of DNS Security (DNSSEC) Trust Anchors). If
> the parent of the zone is signed, the recommended introduction time
> (SPARTA) is one week. The recommended period during which a KSK is
> retired before it is removed from the zone (retirement time) is four
> weeks. For the ZSK, the recommended introduction time is four days
> and the retirement time is two weeks."
>
> What values are other folks using?

I'm not sure why such a long retirement time is recommended,
particularly for the ZSK which has no dependencies on getting a parent
zone to update anything.

For the KSK, you don't want to use it to sign anything until the parent
has published the DS record, any old cached copies of that set without
the new one have expired, you've published the DNSKEY record, and any
old cached copies of that set have expired. For my case, I am publishing
the KSK for an entire year before using it, so can't see any issues
there. You don't want to remove a KSK until the parent has removed the
corresponding DS record, cached copies have expired, and there are no
longer any signatures floating around signed by it. My TTL is only 12
hours, so keeping it around for two weeks after I stop using it seems
more than sufficient (and if for some reason there is an excessive delay
getting the parent to remove the DS record, I can extend the publication
further).

For the ZSK, you don't want to sign anything with it after publication
until you are sure there are no old cached copies of the set floating
around without it. I'm going to publish the ZSK one month in advance of
using it, so again don't see any issues. You don't want to remove it
while there are potentially any cached signatures floating around that
use it. Again with a TTL of 12 hours, two days seems like it should be a
sufficient interval to wait.

You don't want your signature lifetime to be too short, resulting in
expired signatures before new ones are generated. My signature lifetime
will be 35 days, with a forced signing at least once a month on the
first of the month, along with a fresh signing anytime the backend data
changes. So I don't see a scenario where my signatures would expire.

The only edge case I can see that might cause a failure is if my primary
server dies or there is an issue transferring the new zone to
secondaries towards the end of the month. Hypothetically, if the
underlying data doesn't change, and the zone was only signed on the
first of the month, and an issue arises say the last week of the month,
there is a case where it is possible my secondaries will have a copy of
the zone that hasn't expired yet, but which does not have valid
signatures. I'm willing to live with this possibility, as the likelihood
of such a failure is low, and the likelihood it would be resolved
quickly is high :).

I guess if I missed anything at some point maybe Stephane Bortzmeyer
will be contacting me to let me know my dnssec deployment is broken and
asking what tool I'm using ;)...


-- 
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