[dns-operations] Pre-publishing KSKs and ZSKs

Edward Lewis edward.lewis at icann.org
Tue Nov 24 16:40:02 UTC 2015

On 11/24/15, 8:06, "dns-operations on behalf of Matthijs Mekking"
<dns-operations-bounces at dns-oarc.net on behalf of matthijs at pletterpet.nl>

>This is obviously a trade off between response size and the duration to
>recover from an emergency. I am no good in policy so I leave the
>assessment judging to somebody else :)

I'll add to that based on work I've done previously.

This is a classic case of "sunny day" or "rainy day" planning.  I.e., do
you run home to get an umbrella after you are slightly wet with rain or do
you always carry an umbrella in your bag?

Pre-root signing (read that as "once upon a time, in a land far, far
away") I'd set up a key policy of long ttl (6d) with an emergency key.
Over time I'd change to a shorter ttl (couple of hours) and no emergency
key.  The reason I'd favor the latter now is resolvers have shorter ttl
caps (specifically meaning when BIND was the only game in town it had 7d,
unbound has 1d now) and the track record says that its more common for an
operator to make a mistake than an intentional attack to cause validators
to SERVFAIL something.

The main reason to publish an emergency key (all the time) is to save the
time to pre-publish a new key or signature before a change.  With a
shorter ttl involved, this savings is less significant.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20151124/f18d0887/attachment.bin>

More information about the dns-operations mailing list