[dns-operations] DNSSEC zone resigning and key roll-over

[Joe Abley]

On 2009-10-26, at 08:44, Patrick, Robert wrote:

> I'm trying to grok DNSSEC zone resigning versus zone-signing-key  
> (zsk) roll-over.

You can roll over your ZSK as infrequently as you want. As you note  
there are various recommendations you can refer to, and potentially an  
emergency might make you want to do on an ad-hoc basis as well as on a  
schedule. Re-signing is somewhat orthogonal.

As RFC 4033 says, "RRSIG records that accompany zone data have defined  
inception and expiration times that establish a validity period for  
the signatures and the zone data the signatures cover."

Consider the expiration times in the RRSIGs in your zone as an  
alternative to "zone expiration" which you mention later on in your  
message.

If you have an RRSIG in your zone whose expiry time has already past,  
a validator will not be able to obtain a secure answer from your  
nameserver for the corresponding signed resource record set. Your goal  
as a zone administrator ought to be to make sure that you re-sign  
(i.e. re-generate the RRSIG resource records) sufficiently regularly  
that no expired RRSIGs are ever cached around the world, and hence  
every validator who wants an answer is able to get one with an RRSIG  
that has not expired.

If there's a non-zero operational risk of being late to re-sign (and  
there surely is, for everybody) you might add more time between the  
time at which re-signing occurs and the expiry time of the RRSIGs  
before re-signing.

This makes the decision of how frequently to re-sign the zone a  
function of the RRSet TTLs, the signature validity period you use and  
your own assessment of the operational likelihood that the signing  
infrastructure breaks and its time to repair.

Signing every 24 hours with RRSIG expiry dates that are 30 days in the  
future seems like it's likely not to land you in trouble (e.g.  
assuming you don't have any RRSets with really long TTLs in your zone,  
and that you might notice and fix a broken cron job in a week or two,  
etc).

Note also that every time you make a change to a zone (change an A  
record, add an MX, etc) you need to (re-)generate RRSIGs for the  
changed/added records, and modify the NSEC or NSEC3 RRSets which need  
to be changed. In practice this is most easily achieved by re-signing  
the whole zone again, for the kind of relatively small zone you  
imagine signing out of cron. If you use a nameserver which supports on- 
line re-signing (e.g. recent BIND9), and you introduce zone changes  
dynamically (e.g. using UPDATE) then this is taken care of for you.

If you use DNSSEC management software like OpenDNSSEC then all of  
this, including key rollover, will likely be taken care of for you.

> If I automatically resign a zone every 24 hours using a cron job,  
> but forget to perform roll-over, nothing breaks on days 31, 32, 33,  
> etc. so long as the zone continues to be resigned, correct?

Correct. If you never do a ZSK rollover, but continue to serve RRSIGs  
whose expiry dates are comfortably in the future, everything will be  
fine.

> The longer I wait to perform zsk roll-over, the greater the risk  
> that an attacker may compromise my key through brute-force or  
> equivalent attacks, but DNS continues to function, correct?

Yes.

> With each resigning, presumably the zone expiration clock can be  
> reset, such that a zone with a 30-day expiration will never expire  
> if it is resigned once every 24-hours via a cron job, plus resigned  
> whenever a record is created/updated/deleted.   Changing a published  
> zsk to the current zsk certainly amounts to a zone update, thus the  
> zone is resigned during rollover, but if I forget to rotate keys  
> would the zone remain valid so long as it was resigned on a  
> recurring schedule?

Yes.


Joe