Manual Key Rollover Exercise

OBJECTIVE

We are going to roll the KSK for the zones we have just signed.

REMINDERS

 - we are keeping our keys in /etc/bind/keys/

 - we currently have two or more keys in that directory, one KSK
   and one or more ZSKs.
   Each key is represented by two files, one ending in ".key" (the
   public key) and one ending in ".private" (the private key)

 - there is a DS RRSet in the "root" zone corresponding to our KSK

KSK ROLLOVER

The process is rather similar to the ZSK rollover:

1. Go to the key dir:

   # cd /etc/bind/keys/
   # ls K*

2. Just like in step 2 of the ZSK rollover, generate a new KSK
   You will need to use the "-f KSK" parameter to dnssec-keygen:

   # dnssec-keygen -r /dev/urandom -f KSK -a RSASHA256 -b 2048 -n ZONE MYTLD
         (Elliptic: replace "-a RSASHA256 -b 2048" with "-a ECDSAP384SHA384")
	 
   This will output something like:

   KMYTLD.+008+54511

3. Calculate a DS RRSet for the new KSK.

   # cd /etc/bind/keys/
   # dnssec-dsfromkey KMYTLD.+008+54511.key > dsset-MYTLD-54511.

   (here 54511 is just the ID of the new KSK so we know which DS is which).

   At this stage, we can decide to do the rollover in one of two ways:

   - Double signature
   We introduce a new KSK in to the DNSKEY RR set, and we will sign the ZSK
   with *both* the current ("old") KSK, and the new KSK. When a sufficient
   amount of time has elapsed (propagation time, TTL, etc.), we then
   substitute the DS record in the parent zone with that of the new KSK.
   Validators will have both KSKs in the cache, and the chain of trust
   can be validated using the new DS (trust anchor) in the parent.

   - Pre-publish
   We submit the DS for the new KSK immediately to the parent zone, and
   have it published alongside the existing one. After a sufficient amount
   of time has elapsed, we replace the current ("old") KSK with the new
   one (and proceed to sign the ZSK with the new KSK). Validators will
   by then have both DS in the cache, and the chain of trust can be validated.

   Of the two methods above, the double signature tends to be preferred as it
   doesn't require that the parent be able to handle multiple DS records for
   each child zone. Also, although this is perfectly valid, the extra DS with
   no (yet) published corresponding KSK in the child zone can cause some tools
   to issue warnings. And, as pointed out in point 12 below, pre-publishing
   requires two interactions with the parent (introduce new DS, retire old DS)
   while the double signature method only requires one (swap).

* Method 1: Double signature KSK rollover

4. Add the new KSK to the zone (edit the file):

   From this:

   $include "/etc/bind/keys/KMYTLD.+008+52159.key"; // KSK

   To this:

   $include "/etc/bind/keys/KMYTLD.+008+52159.key"; // KSK old
   $include "/etc/bind/keys/KMYTLD.+008+54511.key"; // KSK new

   Remember to increment the serial number too.

5. Let's sign the zone with the old and new KSK (only the ZSK will be signed
   by both KSKs)

   # cd /etc/bind/keys

   # dnssec-signzone -x -o MYTLD -k KMYTLD.+008+52159 -k KMYTLD.+008+54511 ../master/MYTLD

   # rndc reload MYTLD

6. Check with dig

   $ dig @127.0.0.1 dnskey MYTLD +multi
   $ dig @127.0.0.1 dnskey MYTLD +dnssec +multi

   Wait 2 min for the new zone to proagate through caches.

7. Log into RZM. You should notice that RZM has discovered your new KSK. 
   Verify that the DS record(s) match the contents of the
   dsset-MYTLD-54511. file created above.
   If so, click on SHA256 "eye" to "check" mark as good then "X" mark 
   the old ksk DS record for deletion. Then click "Update" and "Logout".

8. Check with dig - both before and after the TTL expire
   (e.g., 2 x max TTL of mytld zone and DS record)

   $ dig dnskey MYTLD +multi
   $ dig dnskey MYTLD +dnssec +multi

9. Remove the OLD KSK to the zone (edit the file):

   From this:

   $include "/etc/bind/keys/Kmytld.+008+52159.key"; // KSK old
   $include "/etc/bind/keys/Kmytld.+008+54511.key"; // KSK new

   To this:

   $include "/etc/bind/keys/Kmytld.+008+54511.key"; // KSK new

   Remember to increment the serial number too.

10. Let's sign the zone with only the new KSK

    # cd /etc/bind/keys
    # dnssec-signzone -x -o MYTLD -k KMYTLD.+008+54511 ../master/MYTLD
    # rndc reload MYTLD

11. Check with dig - both before and after the TTL expire
    (e.g., 2 x max TTL of mytld zone and DS record)

    $ dig dnskey MYTLD +multi
    $ dig dnskey MYTLD +dnssec +multi

12. Note that double signing requires only one interaction with the parent
    while pre-publishing will require two.


* Method 2: Pre-publish KSK rollover

1. Go to the key dir:

    # cd /etc/bind/keys/
    # ls -lt K*

2. Just like in step 2 of the ZSK rollover, generate a new KSK
   You will need to use the "-f KSK" parameter to dnssec-keygen:

    # dnssec-keygen -r /dev/urandom -f KSK -a RSASHA256 -b 2048 -n ZONE MYTLD
       (Elliptic: replace "-a RSASHA256 -b 2048" with "-a ECDSAP384SHA384")

    which might output:

    KMYTLD.+008+54511

3. Calculate a DS RRSet for the new KSK.

  # cd /etc/bind/keys/
  # dnssec-dsfromkey KMYTLD.+008+54511.key | tee dsset-MYTLD-54511.

  (here 54511 is just the ID of the new KSK so we know which DS is
  which).

4. Upload the dsset for your zone, using the RZM web interface.

   Using web interface, login as before.
   Under the "Edit Trust Anchor Details" section enter:

   Key Tag, 

   Digest

   Algorithm

   Digest type 

   from the output of step 3 above. E.g., for

   MYTLD. IN DS 54511      8          2          983F33D43D1EBB069BF60...
                 TAG    Algorithm  Digest-Type       Digest
                        RSASHA256

   Make sure to eliminate any spaces from the Digest and note that 
   you only need one trust anchor. (longer one is preferred)

   Click "Update" when done.  Wait a 2 minutes for update to propagate.


5. Double check that the new DS is published in the parent (root) zone
    alongside the existing one (you should wait at least 2 x TTL 
    until all the caches are updated):

   # dig @10.192.0.230 DS MYTLD
   ...
   ;; ANSWER SECTION:
   MYTLD    900 IN  DS 52159 8 2 31F1...
   MYTLD    900 IN  DS 54511 8 2 983F...  // <-- the new KSK
   ...

   Since both DS are now present in the world's caches and
   DNSSEC requires only one chain of trust to validate, 
   we can roll our KSK.

   Add the new KSK to the zone (edit the file), and we comment
   out (remove) the old KSK like this:

        ;$include "/etc/bind/keys/KMYTLD.+008+52159.key"; // KSK old
        $include "/etc/bind/keys/KMYTLD.+008+54511.key"; // KSK new

    Remember to increment the serial number too.

    ... notice how we simply get rid of the old KSK - we don't need
    it - both DS records are there, so it's enough to have only one
    KSK, since we already "know" about its DS "on the internet".

6. Let's sign the zone with the new KSK

  # cd /etc/bind/keys
  # dnssec-signzone -x -o MYTLD -k KMYTLD.+008+54511 ../master/MYTLD

  # rndc reload MYTLD

7. Check with dig - both before and after the TTL expire (or cache flush)

  # dig dnskey MYTLD +multi
  # dig dnskey MYTLD +dnssec +multi

  Notice that the key tag for the KSK (flag 257) has changed to
  the new one and that the "ad" Authenticated Data bit is still set.
 
8. Remove the original DS resouce record from the "root" using 
   the RZM web interface by logging in; clicking on the icon
   next to the old DS record until you get "X"; then click
   "Update".

   After 2 minutes, the old DS record should be gone from the root.

   You can check with:

   # dig DS MYTLD

9. Sit back and reflect on what an involved and annoying process
   this was, and how much better things would be if all your key
   rollovers were managed automatically.