On Wed, 6 Jan 2016, Carl Byington wrote:
My zones are currently using algorithm 5 (RSASHA1), with two KSKs and
two ZSKs with overlapping timers. In preparation for updating to
algorithm 8 (RSASHA256), I read:
The bind-users thread "KSK signing all records; NSEC3 algorithm
status?"
https://tools.ietf.org/html/rfc6781#page-31
https://labs.ripe.net/Members/anandb/dnssec-algorithm-roll-over
Is there a more authoritative document that describes the algorithm roll
over procedure? It seems that I need to:
generate new ZSK and KSKs using algorithm 8
sign the zone with all the keys
wait one ttl cycle, then publish a new dnskey rrset
wait one ttl cycle, then upload the new ds rrset
...
eventually, remove the old KSKs from the dnskey rrset,
but still use them to sign the zone
wait one ttl cycle, then resign the zone without the
old KSKs.
Carl:
When I did that algorithm upgrade, I used something close to this process
(based on the dual-signature method):
# generate new RSASHA256 ZSK & KSK (active & published)
dnssec-keygen -K Keys.dnssec -a RSASHA256 -b 1024 -n ZONE $ZONE
dnssec-keygen -K Keys.dnssec -a RSASHA256 -b 4096 -n ZONE -f KSK $ZONE
# re-sign the zone, using smart signing to pick up all keys
dnssec-signzone -K $KEY_DIR -d $KEY_DIR -S -o $ZONE $DIR/$ZONE
# re-load the zone (add any other required rndc args)
rndc reload $ZONE
# add DS record(s) for new KSK in parent zone;
# left as an exercise for the reader
# wait at least 1 TTL cycle (minimum of that for $ZONE & that for the
# DS records in the parent zone) to let new DNSKEY, RRSIG, & DS records
# propagate
# move old keys out of key dir so they don't get used
mv $KEY_DIR/K$ZONE.+005+* $TMP_DIR
# re-sign the zone (with just new keys)
dnssec-signzone -K $KEY_DIR -d $KEY_DIR -S -o $ZONE $DIR/$ZONE
# re-load the zone (add any other required rndc args)
rndc reload $ZONE
# delete DS record(s) for old KSK in parent zone;
# left as an exercise for the reader
# if all good, delete old keys
rm $TMP_DIR/K$ZONE.+005+*
where:
$ZONE is the zone being upgraded
$KEY_DIR contains the key files
$DIR contains the zone files
$TMP_DIR contains old keys temporarily
You can get by with activating the new (RRSIG,DNSKEY,DS) set as a group
immediately after creation & re-signing because the old set is still present
as the basis for validation while the new set propagates around.
Likewise, after the TTL cycle you can delete the old (RRSIG,DNSKEY,DS) set as
a group because by then the new set is present as the basis for validation.
It worked for me. As always, your experience might vary.
I recommend working through this for a zone which:
o doesn't matter
o has the parent under your direct control
These tools are extremely useful:
http://dnsviz.net/
http://dnssec-debugger.verisignlabs.com/
Use them to view & verify things at each stage. To really have some fun,
purposefully break some part of your test zone & see how the above tools show
it.
________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-5555
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
