dnskey algorithm update

[Jay Ford]

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-ford at uiowa.edu, phone: 319-335-5555