Track2Agenda: 04-dnssec-bind-manual-ksk-rollover.txt

File 04-dnssec-bind-manual-ksk-rollover.txt, 6.8 KB (added by Andy Linton, 7 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
12   and one or 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   $ dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE mytld
32
33   This will output something like:
34
35   Kmytld.+008+54511
36
373. Calculate a DS RRSet for the new KSK.
38
39  $ cd /etc/namedb/keys/
40  $ sudo dnssec-dsfromkey Kmytld.+008+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
45At this stage, we can decide to do the rollover in one of two ways:
46
47- Double signature
48
49  We introduce a new KSK in to the DNSKEY RR set, and we will sign the ZSK
50  with *both* the current ("old") KSK, and the new KSK. When a sufficient
51  amount of time has elapsed (propagation time, TTL, etc.), we then
52  substitute the DS record in the parent zone with that of the new KSK.
53  Validators will have both KSKs in the cache, and the chain of trust
54  can be validated using the new DS (trust anchor) in the parent.
55
56- Pre-publish
57
58  We submit the DS for the new KSK immediately to the parent zone, and
59  have it published alongside the existing one. After a sufficient amount
60  of time has elapsed, we replace the current ("old") KSK with the new
61  one (and proceed to sign the ZSK with the new KSK). Validators will
62  by then have both DS in the cache, and the chain of trust can be validated.
63
64Of the two methods above, the double signature tends to be preferred as it
65doesn't require that the parent be able to handle multiple DS records for
66each child zone. Also, although this is perfectly valid, the extra DS with
67no (yet) published corresponding KSK in the child zone can cause some tools
68to issue warnings. And, as pointed out in point 12 below, pre-publishing
69requires two interactions with the parent (introduce new DS, retire old DS)
70while the double signature method only requires one (swap).
71
72* Method 1: Double signature KSK rollover
73
744. Add the new KSK to the zone (edit the file):
75
76   From this:
77
78$include "/etc/namedb/keys/Kmytld.+008+52159.key"; // KSK
79
80   To this:
81
82$include "/etc/namedb/keys/Kmytld.+008+52159.key"; // KSK old
83$include "/etc/namedb/keys/Kmytld.+008+54511.key"; // KSK new
84
85    Remember to increment the serial number too.
86
875. Let's sign the zone with the old and new KSK (only the ZSK will be signed
88   by both KSKs)
89
90  $ cd /etc/namedb/keys
91  $ sudo dnssec-signzone -o mytld -k Kmytld.+008+oldksk -k Kmytld.+008+newksk ../master/mytld Kmytld.+008+zsk
92
93  $ sudo rndc reload mytld
94
956. Check with dig
96
97  $ dig @127.0.0.1 dnskey mytld +multi
98  $ dig @127.0.0.1 dnskey mytld +dnssec +multi
99
100
1017. Log into RZM and click "Update". You should notice that RZM has discovered
102   your new KSK.  Verify that the DS record(s) match the contents of the
103   dsset-mytld-newksk file created above.
104   If so, click on SHA256 "eye" to mark as good then mark the old ksk
105   DS record for deletion.  Then click "Update".
106
1078. Check with dig - both before and after the TTL expire
108   (e.g., 2 x max TTL of mytld zone and DS record)
109
110  $ dig dnskey mytld +multi
111  $ dig dnskey mytld +dnssec +multi
112
1139. Remove the OLD KSK to the zone (edit the file):
114
115   From this:
116
117$include "/etc/namedb/keys/Kmytld.+008+52159.key"; // KSK old
118$include "/etc/namedb/keys/Kmytld.+008+54511.key"; // KSK new
119
120   To this:
121
122$include "/etc/namedb/keys/Kmytld.+008+54511.key"; // KSK new
123
124    Remember to increment the serial number too.
125
12610. Let's sign the zone with only the new KSK
127
128  $ cd /etc/namedb/keys
129  $ sudo dnssec-signzone -o mytld -k Kmytld.+008+newksk ./master/mytld Kmytld.+008+zsk
130
131  $ sudo rndc reload mytld
132
13311. Check with dig - both before and after the TTL expire
134   (e.g., 2 x max TTL of mytld zone and DS record)
135
136  $ dig dnskey mytld +multi
137  $ dig dnskey mytld +dnssec +multi
138
13912.  Note that double signing requires only one interaction with the parent
140     while pre-publishing requires two.
141
142* Method 2: Pre-publish KSK rollover
143
1444. Upload the dsset for your zone, using the web interface or using
145   SCP as shown by the root instructor
146
147   Tell an instructor that you have submitted a new DS RRSet, and that
148   you would like it to be added to the "root" zone. If you used the
149   web interface, this should have happened automatically.
150
151   If using web interface, login as before.
152
153   Under the "Edit Trust Anchor Details" section enter the Key Tag,
154   Digest, Algorithm, and Digest type from the output of
155   step 3 above. E.g.,
156
157   mytld. IN DS 54511    8          2      983F33D43D1EBB069BF60...
158                TAG  Algorithm Digest-Type Digest
159                     RSASHA256
160
161   Make sure to eliminate any spaces from the Digest and note that you
162   only need one trust anchor.
163
164   Click "Update" when done. Wait a minute for update to propagate.
165
1665. Double check that the new DS is published in the parent (root) zone
167    alongside the existing one (you should wait at least 2 x TTL
168    until all the caches are updated):
169
170   $ dig @%PREFIX%.0.230 DS mytld
171   ...
172   ;; ANSWER SECTION:
173   mytld    900 IN  DS 52159 8 2 31F1...
174   mytld    900 IN  DS 54511 8 2 983F...  // <-- the new KSK
175   ...
176
177   Since both DS are now present in the cache, we can roll our KSK.
178
179   Then we add the new KSK to the zone (edit the file), and we comment
180   out (remove) the old KSK:
181
182   From this:
183
184$include "/etc/namedb/keys/Kmytld.+008+52159.key"; // KSK
185
186   To this:
187
188;$include "/etc/namedb/keys/Kmytld.+008+52159.key"; // KSK old
189$include "/etc/namedb/keys/Kmytld.+008+54511.key"; // KSK new
190
191    Remember to increment the serial number too.
192
193    ... notice how we simply get rid of the old KSK - we don't need
194    it - both DS records are there, so it's enough to have only one
195    KSK, since we already "know" about its DS "on the internet".
196
1976. Let's sign the zone with the new KSK
198
199  $ cd /etc/namedb/keys
200  $ sudo dnssec-signzone -o mytld -k Kmytld.+008+54511 ../master/mytld Kmytld.+008+45000
201
202  $ sudo rndc reload mytld
203
2047. Check with dig - both before and after the TTL expire (or cache flush)
205
206  $ dig dnskey mytld +multi
207  $ dig dnskey mytld +dnssec +multi
208 
2098. Tell an instructor that you would like the original DS resource
210   records to be removed from the "root" zone (or remove it yourself
211   using the web interface)
212
2139. Sit back and reflect on what an involved and annoying process
214this was, and how much better things would be if all your key
215rollovers were managed automatically.
216