Manual KSK rollover

Introduction

We’re going to manually roll the KSK (Key Signing Key) for the zones we have signed.

Notes

Commands preceded with “$” imply that you should execute the command as a general user - not as root.
Commands preceded with “#” imply that you should be working as root.
Commands with more specific command lines (e.g. “rtrX>” or “mysql>”) imply that you are executing commands on remote equipment, or within another program.

On your authritative server (SOA)

PLEASE make note of the KSK/ZSK IDs and write them down on a piece of paper as you work to remember which is which.

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:

Go to the key dir

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

Generate new KSK

Just like in step 2 of the ZSK rollover, except here we 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

This will output something like:

KMYTLD.+008+54511

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).

Which method to use ?

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 further 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

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!

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

You should see:

Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 2 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 present, 0 revoked

... notice the KSKs: `2 active`

# rndc reload MYTLD

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.

Upload the new DS

You’ll need to upload the new DS (dsset-MYZONE-…) to the Registry.

Copy the new DS dsset-MYTLD-54511 (replace with yours):

$ scp dsset-MYTLD-54511 sysadm@ns1.root:

Wait for the instructor to update, and check the root zone using dig, to verify that the DS has been published:

$ dig @10.0.0.237 ds MYTLD

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

Remove the OLD KSK from the zone

Edit the file, and change it rom 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.

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

… technically we don’t really need to explicitly specify which KSK to use since there is only one listed.

Either way, you should see:

Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 present, 0 revoked

Reload the zone with BIND

# rndc reload MYTLD

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

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

STOP HERE

Method 2: Pre-publish KSK rollover

NOTE: do not do the exercise below if you have done the double signature!

Upload the dsset for your zone, using scp:

scp dsset-MYTLD-54511 sysadm@ns1.root:

(… or sysadm@10.0.0.237:)

Let the instructor (Registry) know when the new DS is uploaded!

###Double check that the new DS is published

Check the parent (root) zone for publication of the new DS, alongside the existing one (you should wait at least 2 x TTL until all the caches are updated):

# dig @10.0.0.252 DS MYTLD

Look for this:

   ...
   ;; 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”.

Let’s sign the zone with the new KSK

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

Reload the zone

# rndc reload MYTLD

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.

Ask your instructor (Registry) to remove the original (old) DS

The DS for the old (previous) KSK isn’t required anymore in the root/parent.

You can check with:

# dig DS MYTLD

… to see if the DS is still published (or gone)

Moment of reflection

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.