| 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 | ----------- Alternative path for double signed KSK rollover ---------------- |
|---|
| 46 | |
|---|
| 47 | 4. Add the new KSK to the zone (edit the file): |
|---|
| 48 | |
|---|
| 49 | From this: |
|---|
| 50 | |
|---|
| 51 | $include "/etc/namedb/keys/Kmytld.+008+52159.key"; // KSK |
|---|
| 52 | |
|---|
| 53 | To this: |
|---|
| 54 | |
|---|
| 55 | $include "/etc/namedb/keys/Kmytld.+008+52159.key"; // KSK old |
|---|
| 56 | $include "/etc/namedb/keys/Kmytld.+008+54511.key"; // KSK new |
|---|
| 57 | |
|---|
| 58 | Remember to increment the serial number too. |
|---|
| 59 | |
|---|
| 60 | 5. Let's sign the zone with the old and new KSK |
|---|
| 61 | |
|---|
| 62 | $ cd /etc/namedb/keys |
|---|
| 63 | $ sudo dnssec-signzone -o mytld -k Kmytld.+008+oldksk -k Kmytld.+008+newksk ../master/mytld Kmytld.+008+zsk |
|---|
| 64 | |
|---|
| 65 | $ sudo rndc reload mytld |
|---|
| 66 | |
|---|
| 67 | 6. Check with dig |
|---|
| 68 | |
|---|
| 69 | $ dig @127.0.0.1 dnskey mytld +multi |
|---|
| 70 | $ dig @127.0.0.1 dnskey mytld +dnssec +multi |
|---|
| 71 | |
|---|
| 72 | |
|---|
| 73 | 7. Log into RZM and click "Update". You should notice that RZM has discovered |
|---|
| 74 | your new KSK. Verify that the DS record(s) match the contents of the |
|---|
| 75 | dsset-mytld-newksk file created above. |
|---|
| 76 | If so, click on SHA256 "eye" to mark as good then mark the old ksk |
|---|
| 77 | DS record for deletion. Then click "Update". |
|---|
| 78 | |
|---|
| 79 | 8. Check with dig - both before and after the TTL expire |
|---|
| 80 | (e.g., 2 x max TTL of mytld zone and DS record) |
|---|
| 81 | |
|---|
| 82 | $ dig dnskey mytld +multi |
|---|
| 83 | $ dig dnskey mytld +dnssec +multi |
|---|
| 84 | |
|---|
| 85 | 9. Remove the OLD KSK to the zone (edit the file): |
|---|
| 86 | |
|---|
| 87 | From this: |
|---|
| 88 | |
|---|
| 89 | $include "/etc/namedb/keys/Kmytld.+008+52159.key"; // KSK old |
|---|
| 90 | $include "/etc/namedb/keys/Kmytld.+008+54511.key"; // KSK new |
|---|
| 91 | |
|---|
| 92 | To this: |
|---|
| 93 | |
|---|
| 94 | $include "/etc/namedb/keys/Kmytld.+008+54511.key"; // KSK new |
|---|
| 95 | |
|---|
| 96 | Remember to increment the serial number too. |
|---|
| 97 | |
|---|
| 98 | 10. Let's sign the zone with only the new KSK |
|---|
| 99 | |
|---|
| 100 | $ cd /etc/namedb/keys |
|---|
| 101 | $ sudo dnssec-signzone -o mytld -k Kmytld.+008+newksk ./master/mytld Kmytld.+008+zsk |
|---|
| 102 | |
|---|
| 103 | $ sudo rndc reload mytld |
|---|
| 104 | |
|---|
| 105 | 11. Check with dig - both before and after the TTL expire |
|---|
| 106 | (e.g., 2 x max TTL of mytld zone and DS record) |
|---|
| 107 | |
|---|
| 108 | $ dig dnskey mytld +multi |
|---|
| 109 | $ dig dnskey mytld +dnssec +multi |
|---|
| 110 | |
|---|
| 111 | 12. Note that double signing requires only one interaction with the parent |
|---|
| 112 | while pre-publishing requires two. |
|---|
| 113 | |
|---|
| 114 | ----------- end alternate ------------------ |
|---|
| 115 | |
|---|
| 116 | 4. Upload the dsset for your zone, using the web interface or using |
|---|
| 117 | SCP as shown by the root instructor |
|---|
| 118 | |
|---|
| 119 | Tell an instructor that you have submitted a new DS RRSet, and that |
|---|
| 120 | you would like it to be added to the "root" zone. If you used the |
|---|
| 121 | web interface, this should have happened automatically. |
|---|
| 122 | |
|---|
| 123 | If using web interface, login as before. |
|---|
| 124 | |
|---|
| 125 | Under the "Edit Trust Anchor Details" section enter the Key Tag, |
|---|
| 126 | Digest, Algorithm, and Digest type from the output of |
|---|
| 127 | step 3 above. E.g., |
|---|
| 128 | |
|---|
| 129 | mytld. IN DS 54511 8 2 983F33D43D1EBB069BF60... |
|---|
| 130 | TAG Algorithm Digest-Type Digest |
|---|
| 131 | RSASHA256 |
|---|
| 132 | |
|---|
| 133 | Make sure to eliminate any spaces from the Digest and note that you |
|---|
| 134 | only need one trust anchor. |
|---|
| 135 | |
|---|
| 136 | Click "Update" when done. Wait a minute for update to propagate. |
|---|
| 137 | |
|---|
| 138 | 5. Double check that the new DS is published in the parent (root) zone |
|---|
| 139 | alongside the existing one (you should wait at least 2 x TTL |
|---|
| 140 | until all the caches are updated): |
|---|
| 141 | |
|---|
| 142 | $ dig @10.10.0.230 DS mytld |
|---|
| 143 | ... |
|---|
| 144 | ;; ANSWER SECTION: |
|---|
| 145 | mytld 900 IN DS 52159 8 2 31F1... |
|---|
| 146 | mytld 900 IN DS 54511 8 2 983F... // <-- the new KSK |
|---|
| 147 | ... |
|---|
| 148 | |
|---|
| 149 | Since both DS are now present in the cache, we can roll our KSK. |
|---|
| 150 | |
|---|
| 151 | Then we add the new KSK to the zone (edit the file), and we comment |
|---|
| 152 | out (remove) the old KSK: |
|---|
| 153 | |
|---|
| 154 | From this: |
|---|
| 155 | |
|---|
| 156 | $include "/etc/namedb/keys/Kmytld.+008+52159.key"; // KSK |
|---|
| 157 | |
|---|
| 158 | To this: |
|---|
| 159 | |
|---|
| 160 | ;$include "/etc/namedb/keys/Kmytld.+008+52159.key"; // KSK old |
|---|
| 161 | $include "/etc/namedb/keys/Kmytld.+008+54511.key"; // KSK new |
|---|
| 162 | |
|---|
| 163 | Remember to increment the serial number too. |
|---|
| 164 | |
|---|
| 165 | ... notice how we simply get rid of the old KSK - we don't need |
|---|
| 166 | it - both DS records are there, so it's enough to have only one |
|---|
| 167 | KSK, since we already "know" about its DS "on the internet". |
|---|
| 168 | |
|---|
| 169 | 6. Let's sign the zone with the new KSK |
|---|
| 170 | |
|---|
| 171 | $ cd /etc/namedb/keys |
|---|
| 172 | $ sudo dnssec-signzone -o mytld -k Kmytld.+008+54511 ../master/mytld Kmytld.+008+45000 |
|---|
| 173 | |
|---|
| 174 | $ sudo rndc reload mytld |
|---|
| 175 | |
|---|
| 176 | 7. Check with dig - both before and after the TTL expire (or cache flush) |
|---|
| 177 | |
|---|
| 178 | $ dig dnskey mytld +multi |
|---|
| 179 | $ dig dnskey mytld +dnssec +multi |
|---|
| 180 | |
|---|
| 181 | 8. Tell an instructor that you would like the original DS resource |
|---|
| 182 | records to be removed from the "root" zone (or remove it yourself |
|---|
| 183 | using the web interface) |
|---|
| 184 | |
|---|
| 185 | 9. Sit back and reflect on what an involved and annoying process |
|---|
| 186 | this was, and how much better things would be if all your key |
|---|
| 187 | rollovers were managed automatically. |
|---|
| 188 | |
|---|