<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>Jim Popovitch <jimpop@domainmail.org> wrote:<br></div>
<div><br></div>
<div>><br></div>
<div>> Hmmm, this is counter to what I've believed all along. I thought it was<br></div>
<div>> prudent to have key overlap during rollovers. <br></div>
<div><br></div>
<div>There are two separate things which you can overlap semi-independently:<br></div>
<div><br></div>
<div>* is the key published in the zone?<br></div>
<div><br></div>
<div>* is the key active, i.e. being used to generate signatures?<br></div>
<div><br></div>
<div>If you want to minimize RRSIG overhead when rolling a ZSK, the process is basically:<br></div>
<div><br></div>
<div>* publish new key, but inactive - old key continues to be published<br></div>
<div><br></div>
<div>* wait for changed DNSKEY RRset to propagate everywhere, so that validators become ready to trust the new key<br></div>
<div><br></div>
<div>* deactivate old key and activate new key - no change to DNSKEY RRset at this time, just change how RRSIGs are generated<br></div>
<div><br></div>
<div>* wait for zone to be re-signed and for old signatures to expire from caches; there will be a mix of old and new RRSIGs on different RRsets, but only one RRSIG on each<br></div>
<div><br></div>
<div>* unpublish old key<br></div>
<div><br></div>
<div>For a KSK the process is:<br></div>
<div><br></div>
<div>* add a DS record for the new key, keeping the DS for the old key; the new key is not published yet<br></div>
<div><br></div>
<div>* wait for the new bigger DS RRset to propagate, so validators are ready to trust the new key<br></div>
<div><br></div>
<div>* publish and activate the new KSK and unpublish and deactivate the old KSK at the same time; both old and new DNSKEY RRsets can be validated by the big DS RRset<br></div>
<div><br></div>
<div>* wait for the DNSKEY RRset to propagate, so nothing is using the old key any more<br></div>
<div><br></div>
<div>* remove the old DS record(s) for the old key<br></div>
<div><br></div>
<div>That is the process to minimize DNSKEY RRset size, but it involves two delegation updates; you can alternatively use a bigger DNSKEY RRset and make only one delegation update.<br></div>
<div><br></div>
<div>This is covered in much more detail in <a href="https://tools.ietf.org/html/rfc7583">https://tools.ietf.org/html/rfc7583</a> - the ZSK method above is in section 3.2.1 and the KSK method is in 3.3.2.</div>
<div><br></div>
<div id="sig49431681"><div class="signature">Tony.<br></div>
<div class="signature">--<br></div>
<div class="signature">f.anthony.n.finch <dot@dotat.at> http://dotat.at/ - I xn--zr8h punycode<br></div>
<div class="signature"><br></div>
</div>
<div><br></div>
</body>
</html>