[Dnssec-deployment] Refresh interval Vs. SOA Expire

[Richard Lamb]

Very nice table.

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

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

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.

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

I look forward to the advice of experts on this list.

> >> I marked the rows where SOA Expire is less than the minimum validity.
> >
> > Looks to me like most of these have the Expire set to between 1 and
> > 1/2 of the minimum signature validity.
> 
> It should be ok to re-use the signature almost up to the SOA Expire, but not too close.

For root?
SOA exp 604800 (7 days) 
SOA RRSIG Validity 608400 (7 days)

> 
> **********************************
> 
> Keeping a fresh zone is now important with DNSSEC. The remaining signature lifetime limits how long
> time you have to restore your operations. .SE currently have signatures with remaining validity
> between 4 and 8 days, but with a SOA Expire on 28 days. This means that we have four days to get our
> servers up and running with an up-to-date zone. After the four days we have a zone with expired
> signatures for another 24 days. This is a little bit hazardous and we would like to change this. We
> see that there are two options here:
> 
> ***
> 
> 1. Have a refresh interval greater than SOA Expire.
> 
> This means that any secondary which does not get updated will remove the zone before the signatures
> starts to expire. The benefit with this is that everything will be handled by the servers without any
> intervention from the operator. What SOA Expire to choose depends on your requirements. It should be
> chosen so that you have enough time to fix any issues within your registry system / hidden master.
> 
> 2. Have a refresh interval that allows you time to react and withdraw the DS from root.
> 
> First you need time to detect the problem and start working on it. At one point in time, you must make
> a decision to withdraw your DS from the root. This process takes maximum two days. And finally one
> more day to allow the caches to expire. The problem here is that you have to keep a close eye on all
> of your server, including all instances in your anycast cloud.
> 
> ***
> 
> The question is: What values do other TLDs use?
> 
> The SOA Expire can be found in the SOA RR, which is no hazzle. To know the minimum and maximum
> remaining signature validity, then you need to have a complete knowledge of the zone. That is a little
> bit tricker. What you can do is to send random domain names to the TLD. Most likely, you will get a
> NXDOMAIN on that query. The benefit with DNSSEC, in this case, is that you also will get NSEC / NSEC3
> RRs with RRSIGs back. Thus getting some knowledge of the remaining validity.
> 
> What I did was to send 1000 random domain names (10 alfa-numeric-characters long) to all of the signed
> TLDs. I defined a TLD to be signed if there was a DS in the root zone. Also note that the queries was
> sent through a local resolver, thus not targeting any specific name server.
> 
> You can find the results in the txt-file. First you have the name of the TLD. Then its SOA Expire in
> seconds and days. Following with minimum and maximum validity in seconds and days. I marked the rows
> where SOA Expire is less than the minimum validity.
> 
> What do you think? What option should we go for? What values should be used?
> 
> // Rickard