1 | Manual Key Rollover Exercise |
---|
2 | |
---|
3 | OBJECTIVE |
---|
4 | |
---|
5 | We are going to roll the KSK for the zones we have just signed. |
---|
6 | |
---|
7 | REMINDERS |
---|
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 | |
---|
19 | KSK ROLLOVER |
---|
20 | |
---|
21 | The process is rather similar to the ZSK rollover: |
---|
22 | |
---|
23 | 1. Go to the key dir: |
---|
24 | |
---|
25 | $ cd /etc/namedb/keys/ |
---|
26 | $ ls K* |
---|
27 | |
---|
28 | 2. 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 | |
---|
37 | 3. 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 | |
---|
45 | At 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 | |
---|
64 | Of the two methods above, the double signature tends to be preferred as it |
---|
65 | doesn't require that the parent be able to handle multiple DS records for |
---|
66 | each child zone. Also, although this is perfectly valid, the extra DS with |
---|
67 | no (yet) published corresponding KSK in the child zone can cause some tools |
---|
68 | to issue warnings. And, as pointed out in point 12 below, pre-publishing |
---|
69 | requires two interactions with the parent (introduce new DS, retire old DS) |
---|
70 | while the double signature method only requires one (swap). |
---|
71 | |
---|
72 | * Method 1: Double signature KSK rollover |
---|
73 | |
---|
74 | 4. 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 | |
---|
87 | 5. 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 | |
---|
95 | 6. 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 | |
---|
101 | 7. 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 | |
---|
107 | 8. 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 | |
---|
113 | 9. 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 | |
---|
126 | 10. 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 | |
---|
133 | 11. 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 | |
---|
139 | 12. 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 | |
---|
144 | 4. 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 | |
---|
166 | 5. 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 | |
---|
197 | 6. 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 | |
---|
204 | 7. 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 | |
---|
209 | 8. 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 | |
---|
213 | 9. Sit back and reflect on what an involved and annoying process |
---|
214 | this was, and how much better things would be if all your key |
---|
215 | rollovers were managed automatically. |
---|
216 | |
---|