% DNSSEC - ZSK Rollover with BIND9
# Prerequisites
We assume that:
- your authoritative server soa.grpXX.dns.te-labs.training is serving your TLD
- your TLD is signed using BIND9, from an earlier lab
- you are using two key pairs, a KSK and a ZSK
- a DS RRSet has been uploaded to our workshop root server, and is published in the workshop root zone
If any of these things are not true, finish off the previous labs before
you start this one. If you need help getting up-to-date, one of your
friendly workshop lab staff will be happy to assist.
Before you continue, check that:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ dig @soa.grpXX.dns.te-labs.training yourtld dnskey +dnssec +multiline
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
shows you one ZSK and one KSK. Remember that the KSK has flags 257.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ dig @10.0.0.237 yourtld soa +dnssec +multiline +norec
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gives you a secure referral to your TLD's server: i.e. a response that
includes an NS RRSet and a DS RRSet in the AUTHORITY section. The
DS RRSet should be signed.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ dig @10.0.0.252 yourtld soa +dnssec +multiline
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gives you the SOA record from your TLD, and that it is signed.
# Introduction
In this lab, we will carry out a manual key rollover of the ZSK. Since
we are not changing the KSK, we do not need to send new DS records
to the parent zone. Our approach will be to
- set some timers on the existing ZSK
- create a new ZSK in addition to the existing one (a "successor ZSK")
- include the new ZSK in the DNSKEY RRSet (so it contains two ZSKs)
- sign with both the old and the new ZSK
- when it is safe to do so, stop signing with the old ZSK
- when it is safe to do so, remove the old ZSK
BIND9 will handle most of these steps for us, but we will still have to
generate a new ZSK and provide timing instructions for the transition.
# ZSK Rollover
## Set some timers on the current ZSK (the "retiring" ZSK)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ cd /etc/bind/keys
$ ls
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work out which key file is your ZSK by looking in the file and checking
the flags value. The ZSK will have the value 256. That's the one we want.
In our example, this is the ZSK. Remember that your filename will be
different! Do not simply cut and paste Kmytld.+008+57564 later in the lab!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sysadm@soa:/etc/bind/keys$ cat Kmytld.+008+57564.key
; This is a zone-signing key, keyid 57564, for mytld.
; Created: 20200819082249 (Wed Aug 19 08:22:49 2020)
; Publish: 20200819082249 (Wed Aug 19 08:22:49 2020)
; Activate: 20200819082249 (Wed Aug 19 08:22:49 2020)
mytld. IN DNSKEY 256 3 8 AwEAAdpQtOTDy+9...
sysadm@soa:/etc/bind/keys$
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We will set an "inactive" time and a "delete" time for this key. These
parameters are required by BIND9 to manage the ZSK rollover. In the example
below we are going to use "+30mi" to mean "thirty minutes from now" and
"+2h" to mean "two hours from now". In the real world you would
probably use much longer timers.
The dnssec-settime command will record the timers in the key file.
You can look to see what has changed, compared to before.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ sudo dnssec-settime -I +30mi -D +2h Kmytld.+008+57564
sysadm@soa:/etc/bind/keys$ sudo dnssec-settime -I +30mi -D +2h Kmytld.+008+57564
./Kmytld.+008+57564.key
./Kmytld.+008+57564.private
sysadm@soa:/etc/bind/keys$ cat Kmytld.+008+57564.key
; This is a zone-signing key, keyid 57564, for mytld.
; Created: 20200819082249 (Wed Aug 19 08:22:49 2020)
; Publish: 20200819082249 (Wed Aug 19 08:22:49 2020)
; Activate: 20200819082249 (Wed Aug 19 08:22:49 2020)
; Inactive: 20200819095530 (Wed Aug 19 09:55:30 2020)
; Delete: 20200819112530 (Wed Aug 19 11:25:30 2020)
mytld. IN DNSKEY 256 3 8 AwEAAdpQtOTDy+9...
sysadm@soa:/etc/bind/keys$
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
## Create a new ZSK (a "successor" ZSK)
We do not need to specify the full set of parameters when we generate
a new ZSK (algorithm name, key size, etc) because we will tell the
dnssec-signzone command that we are creating a successor to the old
ZSK, and the software will make sure the new key it generates matches.
We will use the -i option to specify a much shorter pre-publication
interval than is normal, to be compatible the very short timers we used in
step one.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sysadm@soa:/etc/bind/keys$ sudo dnssec-keygen -S Kmytld.+008+57564 -i10mi
Generating key pair................+++++ .............................+++++
Kmytld.+008+07659
sysadm@soa:/etc/bind/keys$
sysadm@soa:/etc/bind/keys$ sudo chown -R bind:bind /etc/bind/keys
sysadm@soa:/etc/bind/keys$ sudo rndc loadkeys mytld
sysadm@soa:/etc/bind/keys$
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
## Check the logs!
Just in case we forgot anything and accidentally made named sad, let's
check the logs.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sysadm@soa:/etc/bind/keys$ cd /var/log
sysadm@soa:/var/log$ sudo tail syslog
Aug 19 09:34:27 soa named[3219]: received control channel command 'loadkeys mytld'
Aug 19 09:34:27 soa named[3219]: zone mytld/IN (signed): reconfiguring zone keys
Aug 19 09:34:27 soa named[3219]: zone mytld/IN (signed): next key event: 19-Aug-2020 09:45:30.008
sysadm@soa:/var/log$ date
Wed Aug 19 09:35:52 UTC 2020
sysadm@soa:/var/log$
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We can see that BIND9 received the "loadkeys" command, that there were no errors
and that there is some kind of key event gloing to happen in about ten minutes
(at 09:45 UTC in our example, here).
## Watch the DNS
We expect the new ZSK to be published in the DNSKEY RRSet ten minutes
before it is used. Right now, how many ZSKs are published, and how many
signatures are being published for other records in the zone, like the SOA?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sysadm@soa:~$ dig @soa.grp1.dns.te-labs.training mytld. dnskey +multiline
; <<>> DiG 9.11.3-1ubuntu1.12-Ubuntu <<>> @soa.grp1.dns.te-labs.training mytld. dnskey +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2175
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: c46913c97edb66ed5a022cfa5f3cf3339973d12458e2322d (good)
;; QUESTION SECTION:
;mytld. IN DNSKEY
;; ANSWER SECTION:
mytld. 3600 IN DNSKEY 257 3 8 (
AwEAAbJy4xHsDcWJGV0vcR4ARUU0XXxkUGwOKV+VKukC
yXg1X3ncWgGynKskgKedD/6u+wMaxpiZkvdNsrqGKIJi
fa79zSy2zcRMM7f1qHbQG+Fw17PIrzeysXYxrqzDQAkN
QopOxOpc9V8yKmUUVmj+3I6VFZYnu7iJompsku/Ml9ij
fKYdzLB8eAfhtCd+mSFZZYVoepyDGO7f4JhScAk//OJt
GBOjqB4BnPy4fbFC+qdG6uPSwVfBobWsA3kmiVq4ma7k
ULT4ejn/3ZH+Wt0jWNfKdEF2D5nGIWEb/Q/z1d1QigFy
50WJBZ8TDq7BH+uFtVV3pkxNo0O7pL46EeS8cE8=
) ; KSK; alg = RSASHA256 ; key id = 37666
mytld. 3600 IN DNSKEY 256 3 8 (
AwEAAdpQtOTDy+9rOiaUY+gATrgCftdFDCXDhKcMrWaX
onIqG8X4yh/VhKegjau7hsS55IFXuYr9avhqLDM5fLk8
Ek0obwcvym8viprg86hm33NOE7h+eu8YiNLkQyo5PcSy
TyXxDDqHKPY8ijA2wTAaW/kJAn68Fwy7SWvrDoQojPo3
HzRi//1LndC1N8B2y9DkZv1kKeUdo20r7uv1Id5uLexE
qlf0nxBFt2lPClbJYCR3GyByk1tPw6T3zzHvyC7lmF32
+tPk6lG+YK8oCWs8Z7yZRT641ENODsnYWpHV5CFyZxD2
tfgn7B7KGaG5cSYObfGtJN2Tya3a4+EgM1F9KnE=
) ; ZSK; alg = RSASHA256 ; key id = 57564
;; Query time: 0 msec
;; SERVER: 10.1.1.1#53(10.1.1.1)
;; WHEN: Wed Aug 19 09:38:59 UTC 2020
;; MSG SIZE rcvd: 615
sysadm@soa:~$ dig @soa.grp1.dns.te-labs.training mytld. soa +dnssec +multiline
; <<>> DiG 9.11.3-1ubuntu1.12-Ubuntu <<>> @soa.grp1.dns.te-labs.training mytld. soa +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25717
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 359cb4b434cc9861272462ca5f3cf42e018b69c30535ad20 (good)
;; QUESTION SECTION:
;mytld. IN SOA
;; ANSWER SECTION:
mytld. 3600 IN SOA soa.grp1.dns.te-labs.training. jabley.te-labs.training. (
2020081903 ; serial
10000 ; refresh (2 hours 46 minutes 40 seconds)
2400 ; retry (40 minutes)
604800 ; expire (1 week)
3600 ; minimum (1 hour)
)
mytld. 3600 IN RRSIG SOA 8 1 3600 (
20200918084649 20200819074649 57564 mytld.
V0l455Le6u6V0aMXTExU/cKg+M6Z0brfHgs/LGilFPn9
tta7XAm6I0rbhMkCQ1CHG2Qv7fMvPiiYEw/HUbqbQUdg
M4Jv1iZUlsuHR35z8KX7C0f8ILCWenOnkQQw5IWCvKYO
39Ew3t10yhwUDafEAsJHwz5PTMWhUXKN8xjuDxnfGQXP
DCes4CFGqaJhWWmVAXgzpQVw0PqRcslLLWSCODTGeAj2
VSNquWYNoeVjJSWA5/wWsWJ4jtjQmgW9rVPKjb376DNv
4YGxWv5s5J4NUXKTdJav7pUQQFQ+wdJoncYIfbjw1GNq
kMNMlAyy/MmRwedavNdpd1P30o8Szk5nsw== )
;; AUTHORITY SECTION:
mytld. 3600 IN NS soa.grp1.dns.te-labs.training.
mytld. 3600 IN RRSIG NS 8 1 3600 (
20200918075613 20200819072604 57564 mytld.
EA/zxeXTzzomI05UhGpzw0arD4CgpwO48C0HD/YI/9RE
3e7w7kAlrkqnNp3bvTCjJCE3AN2vcgAXspbQWNfKzI35
ND9uZthLNF74izyz4rZgvr6/NpTm98pvaTrenEAZPJuZ
x/3fBwI3ABznVAXo2fCV+G6sCIdHc8s8m7u/dVfYYbo6
Yx1EtO5Jjg8aNfxVBNtsDPkFmxpuWQb7TvYexSkUhyfL
2hdytLQRAk/W2cNUdX9iqOaZajXoAp6JCQZobp+HtFaj
TkkS2DGq6Cl8gHDUyaXyM5PzACNNdkkBVPhAXF0jTzQw
RpcR9Y5rFPxsVUhUO6Zh5MI5Rq9M/upznQ== )
;; Query time: 0 msec
;; SERVER: 10.1.1.1#53(10.1.1.1)
;; WHEN: Wed Aug 19 09:43:10 UTC 2020
;; MSG SIZE rcvd: 729
sysadm@soa:~$
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Once a bit more time has passed, you should be able to see that the
new ZSK is being published:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sysadm@soa:~$ date
Wed Aug 19 09:45:45 UTC 2020
sysadm@soa:~$ dig @soa.grp1.dns.te-labs.training mytld. dnskey +multiline
; <<>> DiG 9.11.3-1ubuntu1.12-Ubuntu <<>> @soa.grp1.dns.te-labs.training mytld. dnskey +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15775
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ea8a925d41e79ef4c0d8796c5f3cf4cfa0a39a752055569b (good)
;; QUESTION SECTION:
;mytld. IN DNSKEY
;; ANSWER SECTION:
mytld. 3600 IN DNSKEY 256 3 8 (
AwEAAbo26WFCUmzbGAFFDOmqqO0hxicUt16pSeXf8j90
n6dgpqmIvxPJB7N0RP/LKfXaFAsmrd9M+qwJLYrmxasD
MuVS5TS6Mx10BjrK3WFJckgGS+ytFYIC/8R6hVKfAWGy
3/aWW7BmibmAUEb9Q8eKb2KCx7p7Do5HfsalopXWpqJY
cQgvaB5uCa+NRKS8RB07R4RjNXtPIRn5/h32SOemoFee
pjE3qlI+WRt6kfIuJFRpUm+NxVEKEXr3LHt04DA9+8tN
qX6cxzslFr5QsX6NfrirUc9P3z6FlAw7T+VWdOWSW3id
vx0xokPW7KJ6nzFtV+l5SItM529yO8EcdJYSdPk=
) ; ZSK; alg = RSASHA256 ; key id = 7659
mytld. 3600 IN DNSKEY 256 3 8 (
AwEAAdpQtOTDy+9rOiaUY+gATrgCftdFDCXDhKcMrWaX
onIqG8X4yh/VhKegjau7hsS55IFXuYr9avhqLDM5fLk8
Ek0obwcvym8viprg86hm33NOE7h+eu8YiNLkQyo5PcSy
TyXxDDqHKPY8ijA2wTAaW/kJAn68Fwy7SWvrDoQojPo3
HzRi//1LndC1N8B2y9DkZv1kKeUdo20r7uv1Id5uLexE
qlf0nxBFt2lPClbJYCR3GyByk1tPw6T3zzHvyC7lmF32
+tPk6lG+YK8oCWs8Z7yZRT641ENODsnYWpHV5CFyZxD2
tfgn7B7KGaG5cSYObfGtJN2Tya3a4+EgM1F9KnE=
) ; ZSK; alg = RSASHA256 ; key id = 57564
mytld. 3600 IN DNSKEY 257 3 8 (
AwEAAbJy4xHsDcWJGV0vcR4ARUU0XXxkUGwOKV+VKukC
yXg1X3ncWgGynKskgKedD/6u+wMaxpiZkvdNsrqGKIJi
fa79zSy2zcRMM7f1qHbQG+Fw17PIrzeysXYxrqzDQAkN
QopOxOpc9V8yKmUUVmj+3I6VFZYnu7iJompsku/Ml9ij
fKYdzLB8eAfhtCd+mSFZZYVoepyDGO7f4JhScAk//OJt
GBOjqB4BnPy4fbFC+qdG6uPSwVfBobWsA3kmiVq4ma7k
ULT4ejn/3ZH+Wt0jWNfKdEF2D5nGIWEb/Q/z1d1QigFy
50WJBZ8TDq7BH+uFtVV3pkxNo0O7pL46EeS8cE8=
) ; KSK; alg = RSASHA256 ; key id = 37666
;; Query time: 0 msec
;; SERVER: 10.1.1.1#53(10.1.1.1)
;; WHEN: Wed Aug 19 09:45:51 UTC 2020
;; MSG SIZE rcvd: 891
sysadm@soa:~$
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
## Time Passes
Keep watching as time continues to pass. Verify that your TLD is
still signed consistently:
- the right number of ZSKs are published in the DNSKEY RRSet
- the right ZSKs are being used to publish signatures
- the responses you receive from the workshop validating resolver are being returned with the ad flag set
- at the appropriate time, based on the timers you sent earlier, the old ZSK is retired
## Success!
At the end of this process you should have sucessfully rolled your ZSK.