We're going to manually roll the ZSK (Zone Signing Key) for the zones we have signed.
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.
We are keeping our keys in /etc/bind/keys/
We currently have two pairs of keys in that directory, one ZSK and one KSK.
Each pair 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
Take a look at what keys we have already generated. Make a note of the names of the files containing the current ZSK and KSK.
# cd /etc/bind/keys/
# ls -lt K*
We'll be creating a new ZSK, to replace the old one.
# dnssec-keygen -r /dev/urandom -a RSASHA256 -b 2048 -n ZONE MYTLD
Note: Replace MYTLD with the name of your zone!
You will get output similar to:
KMYTLD.+008+45000
Mak a note of this Key ID on a piece of paper:
ZSK 2 : 45000 (replace with what you got)
Make sure all the keyfiles are readable by the named process:
# chown bind K*
# chmod u+r K*
# ls -lt
You should now have a third key pair in the directory. If you check the DNSKEY RDATA (e.g., cat KMYTLD.+008+45000.key
), you should see the flags field is 256 (i.e. this is a ZSK, not a KSK).
Make a note of the name of the file containing the new ZSK.
# dig @10.0.0.252 MYTLD dnskey +multi
Your zone should contain one KSK and one ZSK (check the flags - 257/256 - to distinguish between them).
We need to add the new key to the zone, so it gets included in the next signing. At the end of the file /etc/bind/master/MYTLD, ADD the new key:
$include "/etc/bind/keys/KMYTLD.+008+45000.key";
Note: Increment the serial number.
Save the file and exit
We will need to get the new ZSK signed, but we will NOT sign zone data using the new ZSK. Initially, we only want the new ZSK to show up in the DNSKEY RRset alongside the existing one, and be signed by the current KSK.
This is called a "pre publish".
# cd /etc/bind/keys
# dnssec-signzone -x -o MYTLD -k KMYTLD.+008+52159 ../master/MYTLD KMYTLD.+008+51333
Note: key tag numbers from the manual signing example, replace with yours.
Notice in the above example that we are only using the current (old) ZSK and old KSK to sign, not the new one - this is to make sure that dnssec-signzone doesn't try to sign with both ZSKs. It wouldn't be "bad", but it would mean twice the data in the zone, one set of signaures having been generated using a KEY that hasn't been widely distributed yet.
We therefore dnssec-signzone
explicitly which keys to use when doing a rollover, PRECISELY because you want to control the timing of when a key is introduced, used to sign, and finally retired.
The output of the above command should be:
Zone signing complete:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 1 present, 0 revoked
../master/MYTLD.signed
Notice the ZSKs: 1 active, 1 present
First, make BIND reload the newly signed zone:
# rndc reload MYTLD
Then, check the zone contents:
# dig @10.X.1.1 MYTLD dnskey +multi
# dig @10.X.1.1 MYTLD dnskey +dnssec +multi
# dig @10.X.1.1 MYTLD soa +dnssec
Your zone should now contain one KSK and two ZSKs; both ZSKs should be present in the DNSKEY RRSet, which should be signed by the KSK.
BUT the SOA record (and other RRSets in the zone) should be signed only once, using the old ZSK. And the DNSKEY RRset should show all 3 keys (1 KSK, 2 ZSKs).
This is called "pre-publish".
At this time, we should wait 2 x TTL for both ZSKs to show up in everyone's cache (by default it is 120 seconds, or 2 minutes, in our lab, but this will be different "in real life").
Let's wait for at least 2 minutes before we sign with the new ZSK instead of the old ZSK.
After 2 minutes, ask one of your neighbors if they can lookup the DNSKEY for your domain. They can check the in-class cache (10.0.0.252) and, if they have configured it, their own caching resolver.
Again, the command to lookup the keys is:
# dig @10.0... MYTLD dnskey +multi
Once we are certain that "all the internet" (everyone in the class) can see both keys, we can sign with the new ZSK.
Remember, we have 3 keys - in our zone, we have:
$include "/etc/bind/keys/KMYTLD.+008+52159.key"; // KSK
$include "/etc/bind/keys/KMYTLD.+008+51333.key"; // ZSK we retire
$include "/etc/bind/keys/KMYTLD.+008+45000.key"; // new ZSK
Don't change any of these! But increment the serial number, then:
# cd /etc/bind/keys
# dnssec-signzone -x -o MYTLD -k KMYTLD.+008+52159 ../master/MYTLD KMYTLD.+008+45000
... Notice how we now use 45000 (new, second ZSK) to sign, not 51333 (old, previous ZSK) anymore.
Now, reload the zone to propagage the changes:
# rndc reload MYTLD
Check with dig like in step 5 that you are seeing only ONE signature for your RRsets - which means we are only signing using ONE ZSK - you still have to wait for the TTL to expire before you can retire the old ZSK.
Use dig
like earlier, to verify that we are only signing zone data with one ZSK.
# dig @10.X.1.1 www.MYTLD +dnssec
But also verify that the OLD ZSK is still published (but not used to sign) in the DNSKEY RRset:
# dig @10.X.1.1 MYTLD dnskey +multi
You should still see three keys.
After 2 minutes you should still see the AD bit set. Verify:
# dig MYTLD SOA +dnssec
... which indicates that during this rollover, the zone continues to validate and thus the zone is still secure.
After waiting at least 2 minutes (120s) for caches to clear, retire the old ZSK:
# cd /etc/bind/master/
Edit the zone file and add a comment sign (';') in front of the old ZSK (double check which key!)
$include "/etc/bind/keys/KMYTLD.+008+52159.key"; // KSK
; $include "/etc/bind/keys/KMYTLD.+008+51333.key"; // ZSK (commented out)
$include "/etc/bind/keys/KMYTLD.+008+45000.key"; // new ZSK
Increment the serial number.
Now resign the zone, but you will notice that we explicitly DON'T specify the ZSK we just commented. Since there is only one ZSK in the zone, we don't need to say which one to use.
# cd /etc/bind/keys
# dnssec-signzone -x -o MYTLD -k KMYTLD.+008+52159 ../master/MYTLD
# rndc reload MYTLD
# tail /etc/bind/log/general
Like earlier, check that signatures still validate, and that the OLD KZK is no longer in the RRset.
Also, check the RRSIGs (dig +dnssec soa MYTLD) in your zone show the key ID of the new ZSK. Hint: dig MYTLD +dnssec +multi
Does your domain still work ? :)