<div dir="ltr">Hi Yuri,<div><br></div><div>Thank you very much for the clarifications provided.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 31, 2017 at 12:39 PM, Yuri Schaeffer <span dir="ltr"><<a href="mailto:yuri@nlnetlabs.nl" target="_blank">yuri@nlnetlabs.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Emil,<br>
<br>
I have some clarifications.<br>
<span class=""><br>
> There are no signatures created/remaining in the signed zone with the<br>
> retired key and it's completely redundant it's kept in the zonefile for<br>
> so long.<br>
<br>
</span>I'm not sure about the order of events in your zone, you might have done<br>
some manual clean or resigns? But it general it isn't redundant at all<br>
for the old ZSK to be published for some time. Where it not for caching<br>
in DNS, DNSSEC would be much simpler. The old ZSK needs to be published<br>
as long as some resolvers still have data cached signed by the old key.<br>
<br></blockquote><div><br></div><div>I completely understand the caching issue and why the transition time between retire and dead key states is related to the signature validity period. In my case though the longest TTL in the zone is a day and all signatures are recreated at each run of the signer (Refresh period is zero), which means there is no need for more than a day (+ some propagation delay) for the old key to be kept in the zone. Instead it is kept for 31 days resulting a bigger DNSKEY responses for 30 more days.</div><div>What I propose is to use the refresh period in the calculation of the period the ZSK shall be kept in the zone. I'll simplify it leaving all safety margins and max TTL aside and say that period should be validity period - refresh time and in the case the refresh time is zero then that period should be max TTL + safety margins.</div><div> </div><div>Emil</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> <<a href="http://example.com" rel="noreferrer" target="_blank">http://example.com</a>> ZSK<br>
<span class="">> retire 2017-08-23 13:50:48 (dead) 2048 8<br>
<br>
</span>Here we see that the retire state of the key lasts for 1 month. This is<br>
because your signature validity is 31 days.<br>
<br>
Also, the way OpenDNSSEC 1.4 works is that when it changes the state of<br>
a key it will calculate the time of the next state change and save it in<br>
the database. Changing the KASP does not affect currently set times.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Note: ODS 2.1 is more flexible in this regard.<br>
<span class="HOEnZb"><font color="#888888"><br>
//Yuri<br>
<br>
</font></span><br>______________________________<wbr>_________________<br>
Opendnssec-user mailing list<br>
<a href="mailto:Opendnssec-user@lists.opendnssec.org">Opendnssec-user@lists.<wbr>opendnssec.org</a><br>
<a href="https://lists.opendnssec.org/mailman/listinfo/opendnssec-user" rel="noreferrer" target="_blank">https://lists.opendnssec.org/<wbr>mailman/listinfo/opendnssec-<wbr>user</a><br>
<br></blockquote></div><br></div></div>