<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">On 14 Aug 2017, at 13:20, A. Schulze <<a href="mailto:sca@andreasschulze.de">sca@andreasschulze.de</a>> wrote:</span></font><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"><br>could you explain more verbose the relation of "30 days" and "resign one a week" to "a expire time of 3 weeks"?<br><br>I would like to understand that :-)<br></span></font></blockquote></div></div><div><br></div><div>No problem - it is tricky, and I probably didn't help by being very imprecise with the numbers :-)</div><div><br></div><div>I have quoted the relevant part of the BIND ARM below.</div><div><br></div><div>To unpack it a bit, by default signatures last 30 days from the time they are generated - they have a fixed expiry time (not a relative time like TTLs). So as the signatures get older, there is less of the 30 days left. This remaining time must be longer than the zone expiry time plus maximum TTL, to ensure that no legitimate queries get an invalid signature in response.</div><div><br></div><div>The oldest a signature can get depends on how frequently it is regenerated. By default this is every 7.5 days, leaving 22.5 days remaining before the old signatures become invalid, i.e. a little more than three weeks.</div><div><br></div><div>The "several multiples" advice at the end of the quote below is interesting. If you have a deep zone transfer graph, with multiple hops from the primary master to the furthest secondary, the zone can take a long time to fully expire. But there is an awkward tension between the desire for short signature lifetimes (to reduce the scope for replay attacks) and long expiry times (to make operational response to transfer failures less of an emergency). I tend to favour shorter signatures and better monitoring :-)</div><div><br></div><div>>> sig-validity-interval Specifies the number of days into the future when DNSSEC signatures automatically generated as a result of dynamic updates will expire. There is an optional second field which specifies how long before expiry that the signatures will be regenerated. If not spec-ified, the signatures will be regenerated at 1/4 of base interval. The second field is specified in days if the base interval is greater than 7 days otherwise it is specified in hours. The default base interval is 30 days giving a re-signing interval of 7 1/2 days. The maximum values are 10 years (3660 days).</div><div><br></div><div><div>The signature inception time is unconditionally set to one hour before the current time to allow for a limited amount of clock skew.</div><div><br></div><div>The sig-validity-interval should be, at least, several multiples of the SOA expire interval to allow for reasonable interaction between the various timer and expiry dates. <<</div><br><div>Tony.<div>-- </div><div>f.anthony.n.finch <<a href="mailto:dot@dotat.at">dot@dotat.at</a>> <a href="http://dotat.at">http://dotat.at</a></div></div></div></body></html>