[Dnssec-deployment] Refresh interval Vs. SOA Expire

[Rickard Bellgrim]

On 1 mar 2011, at 18.39, Richard Lamb wrote:

Sorry, I should have written a definition of the refresh interval. It is the time interval when a
signature should be re-freshed and not re-used anymore.

Create a new signature if time() > (expiration - refresh)

http://trac.opendnssec.org/raw-attachment/wiki/Signer/Using/Configuration/kasp/reuse-of-signatures.png


Sorry for being dense but if I "resign" a record, I will update the validity period so that it shifts forward.
I am sure this is simply my lack of understanding the definition of "resign period" in the picture.

The re-sign period is how often you check if a signature should be re-used, or if a new one should be created.

E.g. we generate a new zone every second hour. Most of the time the signatures are ok and can be re-used. But sometimes we are closer than one refresh interval to the expiration time, then we have to create a new signature.

Could "refresh period" be thought of as validity period overlap?
e.g., validity period = 15 days but resign the record every 10 days?

There are two ways of signing your zone. Always create new signatures or try to re-use old signatures for some period of time. This depends on how many signatures you have to create. You can see in the results which TLDs who re-use signatures and which TLDs always re-generate its signatures.

If you always create new signatures:
Signature validity period > SOA expire ( + propagation delay + safety margin)

If you try to re-use signatures:
refresh period > SOA expire ( + propagation delay + safety margin)

Your option 1 below combined with validity period = 3xRefresh Period suggests a validity period greater than
3xSOA Exp or greater than month long validity periods for many zones.

Yes, the option is then to lower the SOA Expire value.

But the ratio between validity period and refresh period is mostly about performance (re-use / re-create ratio)

Is there no value in keeping the validity periods short for ZSK compromise recovery,
like simply > NxMAXTTL where N > 2 ?

Then you also need to have a really low SOA Expire.

It should be ok to re-use the signature almost up to the SOA Expire, but not too close.

For root?

Keep in mind that the time for the RRSIG is absolute and starts counting as soon as it is created. Whilst the time for SOA expire is relative and starts counting when the secondary receives the zone. You thus have a window of some minutes (do not know how long it takes for the root zone to propagate) where you have expired signatures before the name server decides to drop the zone.

The propagation time is not only about the time between the master and the last name server to update. It is also include the time from when the software starts to check the first signature.

So you should create and re-use signatures up to the point where you have enough time to introduce a new signature before you hit the limit of the SOA Expire.

Lets do some testing...

SOA exp 604800 (7 days)

Yes

SOA RRSIG Validity 608400 (7 days)

Yes (20110308000000 - 20110228230000 = 7 days 1 hour)

The extra 1 hour is probably because of inception offset.

But today is the 2nd March, so there is only 5.7 days until the signatures expire. You would then have expired signatures for more than 1 day before the zone is dropped.

// Rickard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20110302/1a9f822c/attachment.html