Agenda: dnssec-bind-manual-ksk-rollover.txt

File dnssec-bind-manual-ksk-rollover.txt, 3.0 KB (added by admin, 6 years ago)
Line 
1Manual Key Rollover Exercise
2
3OBJECTIVE
4
5We are going to roll the KSK for the zones we have just signed.
6
7REMINDERS
8
9 - we are keeping our keys in /etc/namedb/keys/
10
11 - we currently have two or more keys in that directory, one KSK and one or
12   more ZSKs.
13   Each key is represented by two files, one ending in ".key" (the
14   public key) and one ending in ".private" (the private key)
15
16 - there is a DS RRSet in the "root" zone corresponding to our KSK
17
18
19KSK ROLLOVER
20
21The process is rather similar to the ZSK rollover:
22
231. Go to the key dir:
24
25    $ cd /etc/namedb/keys/
26    $ ls K*
27
282. Just like in step 2 of the ZSK rollover, generate a new KSK
29   You will need to use the "-f KSK" parameter to dnssec-keygen:
30
31    $ sudo dnssec-keygen -f KSK mytld
32
33   (Note we don't explicitly set the bitsize - dnssec-keygen defaults
34    to 1024 for ZSKs and 2048 bits for KSKs). Changing the size of the
35    keys is not a problem.
36
373. Calculate a DS RRSet for the new KSK.
38
39  $ cd /etc/namedb/keys/
40  $ sudo dnssec-dsfromkey Kmytld.+005+54511.key > dsset-mytld-54511.
41
42  (here 54511 is just the ID of the new KSK so we know which DS is
43  which).
44
454. Upload the dsset for your zone, using the web interface or using
46   SCP as shown by the root instructor
47
48   Tell an instructor that you have submitted a new DS RRSet, and that
49   you would like it to be added to the "root" zone. If you used the
50   web interface ("RZM"), this should have happened automatically.
51
525. Double check that the new DS is published in the parent (root) zone
53    alongside the existing one (you should wait at least 2 x TTL
54    until all the caches are updated):
55
56   $ dig DS mytld
57   ...
58   ;; ANSWER SECTION:
59   mytld    900 IN  DS 12345 5 2 31F1...
60   mytld    900 IN  DS 54511 5 2 983F...  // <-- the new KSK
61   ...
62
63   Since both DS are now present in the cache, we can roll our KSK.
64
65   Then we add the new KSK to the zone (edit the file), and we comment
66   out (remove) the old KSK:
67
68   From this:
69
70$include "/etc/namedb/keys/Kmytld.+005+46516.key"; // KSK
71
72   To this:
73
74;$include "/etc/namedb/keys/Kmytld.+005+46516.key"; // KSK old
75$include "/etc/namedb/keys/Kmytld.+005+54511.key"; // KSK new
76
77    Remember to increment the serial number too.
78
79    ... notice how we simply get rid of the old KSK - we don't need
80    it - both DS records are there, so it's enough to have only one
81    KSK, since we already "know" about its DS "on the internet".
82
836. Let's sign the zone with the new KSK
84
85  $ cd /etc/namedb/keys
86  $ sudo dnssec-signzone -o mytld -k Kmytld.+005+54511 ../master/mytld Kmytld.+005+45000
87
88  $ sudo rndc reload mytld
89
907. Check with dig - both before and after the TTL expire (or cache flush)
91
92  $ dig dnskey mytld
93  $ dig dnskey mytld +dnssec
94 
958. Tell an instructor that you would like the original DS resource
96   records to be removed from the "root" zone (or remove it yourself
97   using the web interface, if using the "RZM")
98
999. Sit back and reflect on what an involved and annoying process
100this was, and how much better things would be if all your key
101rollovers were managed automatically.
102