DNSSEC KSK Key Rollover

Probably the most crucial part in a DNSSEC environment is the maintenance of the key-signing key, the KSK. You should rollover this key on a regular basis, though not that often as the zone signing keys, the ZSKs. I am doing a KSK rollover every 2 years.

In the following I will describe the two existing methods for a KSK rollover along with a step-by-step guide how I performed such a rollover for my zone “weberdns.de”. Of course again with many graphics from DNSViz (with “redundant edges”) that easily reveal the keys and signatures at a glance.

Note that this blogpost is NOT about the Root Zone KSK Rollover that appears in 2017/2018. It is merely about your OWN zone that is secured via DNSSEC.

This blogpost is part of a series about DNSSEC. Refer to this list for all articles.

Generally keep in mind that as long as a single chain-of-trust is authentic, you won’t have any problems. Hence: Unless you’re deleting a DNSKEY or a DS record, you must not be afraid. You can add KSKs (DNSKEY 257) and DS records without the fear of loosing your secured zone. However, be carefully in talking to your registrars since at some point they must replace/delete the correct DS record pointing to your KSK. For official details about key rollovers in general, or especially for key signing key rollovers, refer to RFC 6781, section 4.1.2, Key Signing Key Rollovers.

Again: It’s all about Timing!

The RFC mentiones two approaches for the KSK rollover. The first one is called “Double-Signature KSK Rollover“. While the child domain has the new KSK along with the old KSK present in the zone in parallel (hence the name: double-signature since both KSKs sign the ZSK), the parent zone replaces the old DS with the new DS record at a time. The old KSK must not be deleted before the TTL of the old DS record times out:

The other approach is called “Double-DS KSK Rollover“. Here the parent zone has both DS records in parallel (hence the name) while the child replaces the old KSK with the new one at a time, just after the new DS record is propageted in the global DNS. The old DS record can be removed after the TTL of the old KSK times out:

While the ZSK rollover, refer to this blogpost, relies on the four different dates a DNSKEY stores (publish, activate, inactive, delete), a KSK rollover only needs active and delete. That is: publish/activate can be at the same time, while inactive/delete can be at the same time as well.

For my KSK rollover I decided to use the first variant (double-signature) in which I have two KSKs in my zone while replacing the DS record at the parent zone. However, I did not fully follow “Figure 4” within this RFC section 4.1.2 since during a short period both DS records were present at my parents zone. That is: two DS records pointing to two KSKs. However, though not needed this was no problem for a valid chain-of-trust.

0) Initial

My initial situation: only one DS RR and one KSK (id: 63202). Querying the “dnskey” for my weberdns.de zone revealed exactly this single KSK (DNSKEY type 257) and a single ZSK (DNSKEY type 256) as well:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

weberjoh@jw-nb12-lxold:~$dig weberdns.dednskey+multi

;<<>>DiG9.10.3-P4-Ubuntu<<>>weberdns.dednskey+multi

;;global options:+cmd

;;Got answer:

;;->>HEADER<<-opcode:QUERY,status:NOERROR,id:43722

;;flags:qr rd ra ad;QUERY:1,ANSWER:2,AUTHORITY:0,ADDITIONAL:1

;;OPT PSEUDOSECTION:

;EDNS:version:0,flags:;udp:4096

;;QUESTION SECTION:

;weberdns.de.INDNSKEY

;;ANSWER SECTION:

weberdns.de.3260INDNSKEY25638(

AwEAAdx+50fsj7Sxy2DvKiSIdo5YKl/REUJxgson+6O2

aXba9Kaj8Eowwmc/9gOacvCrQyzr3TY2b1wdP0Gg0VeH

Yoa0A1LxWa9dy2Ts14yixcZ5KFYzubkz+doteFa3BFeJ

oanQLLaDvB1Tx1GNz2XuuNvznZ4/ptQuqCQUPcvSYENn

);ZSK;alg=RSASHA256;key id=32058

weberdns.de.3260INDNSKEY25738(

AwEAAdQXI+UfqnGbHdwJtBBStf0CM8Q8nXcriaOysrpG

EDNkM//amUBD2YMWQ3g+htca6tmzfDJMM5D0gOk5d4Id

EmdywkcH+0rGLjNiNEPFnZUpwb6XsYD+ZI/WEuSlp+KC

EV8vwELq7VltABrFT+9Rz5CEvokTxonzQrvnfclVHaGw

O7cglgALsFqJCqBpvDZvEr2Z6dSepjDnFC9BPS6V8PGS

NwAYEtzDp/lrQojkCj28xHj2OCjpr0dIQjdjGFJTHIlc

9cYTAHjdPDsC8Eqfs5HcL3ruU6cbqjTn+5Lm4RdXpOWV

gemVvIGDnUN+v+Tma/WgtQk7U3saizNJ3epCv3s=

);KSK;alg=RSASHA256;key id=63202

;;Query time:1msec

;;SERVER:2003:de:2016:120::a08:53#53(2003:de:2016:120::a08:53)

;;WHEN:Mon Sep1813:26:12CEST2017

;;MSG SIZE rcvd:464

Same for the DS record (only a single one) at the parent zone:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

weberjoh@jw-nb12-lxold:~$dig weberdns.deds+multi

;<<>>DiG9.10.3-P4-Ubuntu<<>>weberdns.deds+multi

;;global options:+cmd

;;Got answer:

;;->>HEADER<<-opcode:QUERY,status:NOERROR,id:37644

;;flags:qr rd ra ad;QUERY:1,ANSWER:1,AUTHORITY:0,ADDITIONAL:1

;;OPT PSEUDOSECTION:

;EDNS:version:0,flags:;udp:4096

;;QUESTION SECTION:

;weberdns.de.INDS

;;ANSWER SECTION:

weberdns.de.81323INDS6320282(

2F9112FF344BCDF9C6F9A7548F04184AAE73458C7150

DE8FFFA3B7D9893C5EEE)

;;Query time:1msec

;;SERVER:2003:de:2016:120::a08:53#53(2003:de:2016:120::a08:53)

;;WHEN:Mon Sep1813:26:53CEST2017

;;MSG SIZE rcvd:88

DNSViz:

1) Generating a new KSK

I generated a new KSK as always, corrected the ownership to be readable by BIND, and did a reload:

2) New DS in Parent Zone

Now I sent my new DS record to my parent zone which did not replace the old DS but added it. Hence there were two DS records in the zone. Note that this step is NOT NEEDED and I just wanted to test it. You MUST NOT have both KSKs and both DS RR active while using one of the KSK rollover schemes.

Haha, and just to mix up more keys: Since my scheduled ZSK (not KSK) rollover took place in the meantime, I had two ZSKs in the zone as well (ids: 32058, 54816), which gave 4x DNSKEYs along with 3x RRSIGs. You can see this in the DNSViz graph above as well. ;)

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

weberjoh@nb15-lx:~$dig weberdns.dednskey+dnssec+multi

;<<>>DiG9.10.3-P4-Ubuntu<<>>weberdns.dednskey+dnssec+multi

;;global options:+cmd

;;Got answer:

;;->>HEADER<<-opcode:QUERY,status:NOERROR,id:24477

;;flags:qr rd ra ad;QUERY:1,ANSWER:7,AUTHORITY:0,ADDITIONAL:1

;;OPT PSEUDOSECTION:

;EDNS:version:0,flags:do;udp:4096

;;QUESTION SECTION:

;weberdns.de.INDNSKEY

;;ANSWER SECTION:

weberdns.de.2992INDNSKEY25638(

AwEAAdx+50fsj7Sxy2DvKiSIdo5YKl/REUJxgson+6O2

aXba9Kaj8Eowwmc/9gOacvCrQyzr3TY2b1wdP0Gg0VeH

Yoa0A1LxWa9dy2Ts14yixcZ5KFYzubkz+doteFa3BFeJ

oanQLLaDvB1Tx1GNz2XuuNvznZ4/ptQuqCQUPcvSYENn

);ZSK;alg=RSASHA256;key id=32058

weberdns.de.2992INDNSKEY25738(

AwEAAdQXI+UfqnGbHdwJtBBStf0CM8Q8nXcriaOysrpG

EDNkM//amUBD2YMWQ3g+htca6tmzfDJMM5D0gOk5d4Id

EmdywkcH+0rGLjNiNEPFnZUpwb6XsYD+ZI/WEuSlp+KC

EV8vwELq7VltABrFT+9Rz5CEvokTxonzQrvnfclVHaGw

O7cglgALsFqJCqBpvDZvEr2Z6dSepjDnFC9BPS6V8PGS

NwAYEtzDp/lrQojkCj28xHj2OCjpr0dIQjdjGFJTHIlc

9cYTAHjdPDsC8Eqfs5HcL3ruU6cbqjTn+5Lm4RdXpOWV

gemVvIGDnUN+v+Tma/WgtQk7U3saizNJ3epCv3s=

);KSK;alg=RSASHA256;key id=63202

weberdns.de.2992INDNSKEY25738(

AwEAAbBpiuX423e8HACUAvARMzUH+stqMAFq0jmthfA7

FQc8d5sqMfZcK0vcg4QFIotAVIh8AfATggHP7tIy6rVu

KqCnvF4LFan4ONNZ7c3WhLMiHB80F4M85NmRMMh/ssb3

2X10Th+iN3g2vPJtvP+rxoeRVT5XyNwbDB+AUCZgsElw

wRmgB+UPQPLU1pZg9bOKW07ejdtayplItPqiuLQ5eRp8

OWeb92AtSpAORp8g4phc+ctvoH9a79lLCszTXiiJgaW3

8iLwD5rZHvqmKL6mSq/qEgxaQHkphinyfYJ7YzH+kbmO

n7WXCgfbjSrVYhiCXeK+NKGgbUwJlwbHVfdYLVM=

);KSK;alg=RSASHA256;key id=3880

weberdns.de.2992INDNSKEY25638(

AwEAAdnRt6U7iD6mT8AOyKLX8nhKZSbE5lfQxkfrqcn6

XPGa96g1ywquKCU/XiMyGcjIx+98EcH2jiHHpAKnGkM4

ggP/iGW8q9CCskQAaKshrwCkp2wa6IpahSpgxgOrs6bM

K5ZXJ+HKb2Xp5V98pJtSE+itUXUDXrauIVAPYY4i0935

);ZSK;alg=RSASHA256;key id=54816

weberdns.de.2992INRRSIG DNSKEY823600(

20171118011635201710190105033880weberdns.de.

ndm9Q9p+t++Fd2QZUhNYrGTxpMuBYA8i3ObrkDtsuGjE

zPtVO+Rs3ltkp56tpRHbJHwaUfoPz0iVM0KFk1t6M94I

H8PiTUxNJ9hMbQidKQ5uapR1AShPBTUcu8Lw54ecpYyU

l7pC7AggH3kvTVZ7kQvgmYehuXAfNFZGUzJuaBFimWt5

W/HbfkT+d1r2WDdim/BV/tugPonmcvdQaU7tGv6Wb6HI

gXV9Q1eHMzduGvfjIQU00hvsoPvsr4BIeZwZurDmJ46/

O5xOPHHCntWR71djBI/k+ROPjTU8Rw+DIngGW/NKwhCQ

E+xlsVAdDAT/O1fdz4Dt7Vv7SosP3aMn0A==)

weberdns.de.2992INRRSIG DNSKEY823600(

201711180116352017101901050332058weberdns.de.

OaLfVLoOxWDwve5HN9M4oqrxCk+X61PXlVnvVFo9cb1Y

PDLpr2aOQf+lXl/2DcShPHpsOEMtIgShXufZTvdnTMWp

0kqqxDNLf2HLa5PGnJUnxj7ofBsEoInH2nr+Y2xEdybK

fTdtzI/V0U9od78+N7xUOr0reqK+MW+YzEId0Y0=)

weberdns.de.2992INRRSIG DNSKEY823600(

201711180116352017101901050363202weberdns.de.

hku8McB9L7ZJMt/j8K9Y7A/vXXcz9S9ppDh5hdgjai8l

iZ+Pg6Lcc5icc1ifvGzGY1jQPV92c52qJK6kusk/a2uP

W9CUfKICFWGwkaLBh+CeQUgoLffe4PUPJK8zm2q6JBax

w7FNI1HFI9J4Aws+j86PPoxNv3u7R/KVQ68hH2QhZyJ4

Kc2Evpd49GrPlk0ntxsrirEFExUQCOAi29/0L+yIFs31

aMDy/E9E50EhKnlqA6OGD9IwCkLT5r9tPTaClVz4u230

7oyq+rz/uUnHlIhYW5ZF5NFNY4IRVKDn0nMTXWK0iyZ+

/7E82bfYwSWhxhr1dYB+KMMKkJtu3qpQqQ==)

;;Query time:2msec

;;SERVER:2003:de:2016:120::a08:53#53(2003:de:2016:120::a08:53)

;;WHEN:Tue Oct2414:48:13CEST2017

;;MSG SIZE rcvd:1657

After some time I told my parent zone to remove the old DS record which is the actual “DS change” event. That is: The new and only DS record pointed to the new KSK, while the old KSK was still present in the zone. DNSViz:

Now I had to wait for the TTL of the old DS record to time out.

3) Deleting the old KSK

Just for fun I did not only set the delete date but scheduled it after one day of inactivity. Note again that this is NOT NEEDED. You can simply set both dates at one time.

And, as expected, after the “delete” date the old KSK was completely gone. That is: During several steps in the last days/weeks the chain of trust was always valid, while at the end a single and new DS record pointed to the single and new KSK at my zone. So for the last time today, the DNSViz graph: