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