minimal-any on master

Tony Finch dot at dotat.at
Mon Sep 5 18:36:00 UTC 2016


Jim Popovitch <jimpop at domainmail.org> wrote:

>
> Hmmm, this is counter to what I've believed all along.  I
> thought it was
> prudent to have key overlap during rollovers.

There are two separate things which you can overlap semi-independently:

* is the key published in the zone?

* is the key active, i.e. being used to generate signatures?

If you want to minimize RRSIG overhead when rolling a ZSK, the process
is basically:

* publish new key, but inactive - old key continues to be published

* wait for changed DNSKEY RRset to propagate everywhere, so that
  validators become ready to trust the new key

* deactivate old key and activate new key - no change to DNSKEY RRset at
  this time, just change how RRSIGs are generated

* 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

* unpublish old key

For a KSK the process is:

* add a DS record for the new key, keeping the DS for the old key; the
  new key is not published yet

* wait for the new bigger DS RRset to propagate, so validators are ready
  to trust the new key

* 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

* wait for the DNSKEY RRset to propagate, so nothing is using the old
  key any more

* remove the old DS record(s) for the old key

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.

This is covered in much more detail in
https://tools.ietf.org/html/rfc7583 - the ZSK method above is in section
3.2.1 and the KSK method is in 3.3.2.

Tony.
--
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--
  zr8h punycode

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160905/c2537b7c/attachment-0001.html>


More information about the bind-users mailing list