1 | Упражнение: обновление ключа вручную |
---|
2 | |
---|
3 | ЗАДАЧА |
---|
4 | |
---|
5 | Мы собираемся обновить KSK для зоны, которую мы только что подписали. |
---|
6 | |
---|
7 | НАПОМИНАНИЯ |
---|
8 | |
---|
9 | - мы храним наши ключи в /etc/namedb/keys/ |
---|
10 | |
---|
11 | - там у нас сейчас хранится две (или более) пары ключей, одна пара для KSK |
---|
12 | и одна или более для ZSK. |
---|
13 | Каждая пара представлена двумя файлами, один заканчивается |
---|
14 | на ".key" (открытый ключ), и другой заканчивается на ".private" |
---|
15 | (закрытый ключ) |
---|
16 | |
---|
17 | - в корневой зоне есть набор записей DS, соответствующий нашему KSK |
---|
18 | |
---|
19 | ОБНОВЛЕНИЕ KSK |
---|
20 | |
---|
21 | Этот процесс довольно похож на обновление ZSK: |
---|
22 | |
---|
23 | 1. Перейдите в ключевой каталог: |
---|
24 | |
---|
25 | $ cd /etc/namedb/keys/ |
---|
26 | $ ls K* |
---|
27 | |
---|
28 | 2. Точно как в шаге 2 обновления ZSK, создайте новый KSK |
---|
29 | Вам необходимо использовать параметр "-f KSK" для dnssec-keygen: |
---|
30 | |
---|
31 | $ dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE mytld |
---|
32 | |
---|
33 | Вывод будет похож на: |
---|
34 | |
---|
35 | Kmytld.+008+54511 |
---|
36 | |
---|
37 | 3. Создайте набор записей DS для нового KSK. |
---|
38 | |
---|
39 | $ cd /etc/namedb/keys/ |
---|
40 | $ sudo dnssec-dsfromkey Kmytld.+008+54511.key > dsset-mytld-54511. |
---|
41 | |
---|
42 | (здесь 54511 это идентификатор нового KSK, так что мы знаем, какой |
---|
43 | DS какому ключу соответствует). |
---|
44 | |
---|
45 | На этой стадии мы можем решить, каким из двух методов производить |
---|
46 | обновление: |
---|
47 | |
---|
48 | - Двойное подписывание |
---|
49 | |
---|
50 | Мы добавляем новый KSK в набор записей DNSKEY, и мы подпишем ZSK, |
---|
51 | используя и текущий ("старый") KSK, и новый KSK. Через достаточный |
---|
52 | промежуток времени (время распространения, TTL, и т.д.) мы поменяем |
---|
53 | запись DS в родительской зоне на ту, которая содержит новый KSK. |
---|
54 | Валидаторы будут иметь оба KSK в кэше, и доверительная цепочка |
---|
55 | может быть проверена используя новый DS в родительской зоне. |
---|
56 | |
---|
57 | - Предварительная публикация |
---|
58 | |
---|
59 | Мы немедленно передаем DS для нового KSK в родительскую зону, и |
---|
60 | публикуем ее вместе с существующим. Через достаточный промежуток |
---|
61 | времени, мы заменяем текущий ("старый") KSK на новый, и подписываем |
---|
62 | ZSK новым KSK. Валидаторы будут иметь оба DS в кэше, и доверительная |
---|
63 | цепочка может быть проверена. |
---|
64 | |
---|
65 | Двойное подписывание используется чаще, потому что оно не требует чтобы |
---|
66 | родительская зона могла поддерживать несколько записей DS для каждой |
---|
67 | дочерней зоны. Дополнительно, несмотря на то, что это совершенно нормально, |
---|
68 | дополнительные DS с (пока) не опубликованными KSK в дочерней зоне могут |
---|
69 | привести к тому, что некоторые инструменты будут выдавать |
---|
70 | сообщения-предупреждения. Наконец, как указано в пункте 12 ниже, |
---|
71 | предварительная публикация требует два раза связываться с администратором |
---|
72 | родительской зоны (добавить новый DS, убрать старый DS), тогда как |
---|
73 | метод двойного подписывания требует связываться только один раз |
---|
74 | (замена одного DS на другой). |
---|
75 | |
---|
76 | * Метод 1: Обновление KSK двойным подписыванием |
---|
77 | |
---|
78 | 4. Добавьте новый KSK в зону (отредактируйте файл): |
---|
79 | |
---|
80 | Было: |
---|
81 | |
---|
82 | $include "/etc/namedb/keys/Kmytld.+008+52159.key"; // KSK |
---|
83 | |
---|
84 | Должно стать: |
---|
85 | |
---|
86 | $include "/etc/namedb/keys/Kmytld.+008+52159.key"; // KSK старый |
---|
87 | $include "/etc/namedb/keys/Kmytld.+008+54511.key"; // KSK новый |
---|
88 | |
---|
89 | Не забудьте также увеличить серийный номер. |
---|
90 | |
---|
91 | 5. Давайте подпишем зону старым и новым KSK (только ZSK будет подписан |
---|
92 | обоими KSK) |
---|
93 | |
---|
94 | $ cd /etc/namedb/keys |
---|
95 | $ sudo dnssec-signzone -o mytld -k Kmytld.+008+oldksk -k Kmytld.+008+newksk ../master/mytld Kmytld.+008+zsk |
---|
96 | |
---|
97 | $ sudo rndc reload mytld |
---|
98 | |
---|
99 | 6. Проверьте |
---|
100 | |
---|
101 | $ dig @127.0.0.1 dnskey mytld +multi |
---|
102 | $ dig @127.0.0.1 dnskey mytld +dnssec +multi |
---|
103 | |
---|
104 | |
---|
105 | 7. Залогиньтесь в RZM и намжите "Update". Вы заметите что RZM обнаружил |
---|
106 | ваш новый KSK. Проверьте что записи DS соответствуют содержимому файла |
---|
107 | dsset-mytld-newksk, который вы создали выше. |
---|
108 | Если все нормально, нажмите на "глаз" около SHA256, чтобы отметить |
---|
109 | его как действующий, потому пометьте старую запись DS для удаления. |
---|
110 | Нажмите "Update". |
---|
111 | |
---|
112 | 8. Проверьте с помощью dig - и до и после времени TTL (например, |
---|
113 | два раза по максимальному TTL зоны mytld и записи DS) |
---|
114 | |
---|
115 | $ dig dnskey mytld +multi |
---|
116 | $ dig dnskey mytld +dnssec +multi |
---|
117 | |
---|
118 | 9. Уберите СТАРЫЙ KSK из файла зоны: |
---|
119 | |
---|
120 | Было: |
---|
121 | |
---|
122 | $include "/etc/namedb/keys/Kmytld.+008+52159.key"; // KSK старый |
---|
123 | $include "/etc/namedb/keys/Kmytld.+008+54511.key"; // KSK новый |
---|
124 | |
---|
125 | Должно стать: |
---|
126 | |
---|
127 | $include "/etc/namedb/keys/Kmytld.+008+54511.key"; // KSK новый |
---|
128 | |
---|
129 | Не забудьте также увеличить серийный номер. |
---|
130 | |
---|
131 | 10. Давайте подпишем зону только лишь новым KSK |
---|
132 | |
---|
133 | $ cd /etc/namedb/keys |
---|
134 | $ sudo dnssec-signzone -o mytld -k Kmytld.+008+newksk ./master/mytld Kmytld.+008+zsk |
---|
135 | |
---|
136 | $ sudo rndc reload mytld |
---|
137 | |
---|
138 | 11. Проверьте с помощью dig - и до и после времени TTL (например, |
---|
139 | два раза по максимальному TTL зоны mytld и записи DS) |
---|
140 | |
---|
141 | $ dig dnskey mytld +multi |
---|
142 | $ dig dnskey mytld +dnssec +multi |
---|
143 | |
---|
144 | 12. Обратите внимание на то, что двойное подписывание требует связываться |
---|
145 | c администратором родительской зоны только один раз, тогда как |
---|
146 | предварительная публикация требует двух сеансов. |
---|
147 | |
---|
148 | * Метод 2: Обновление KSK предварительной публикацией |
---|
149 | |
---|
150 | 4. Закачайте набор записей DS для вашей зоны, либо используя web интерфейс, |
---|
151 | либо при помощи SCP, в зависимости от того, что сказал преподаватель. |
---|
152 | |
---|
153 | Сообщите преподавателю, что вы закачали новый набор DS, и что вы |
---|
154 | хотите добавить его в корневую зону. Если вы использовали web |
---|
155 | интерфейс, это должно было произойти автоматически. |
---|
156 | |
---|
157 | Если вы используете web интерфейс, залогиньтесь, как раньше. |
---|
158 | |
---|
159 | В разделе "Edit Trust Anchor Details" введите метку ключа, дайджест, |
---|
160 | алгоритм, и типа дайджеста (из вывода на шаге 3 выше). Например, |
---|
161 | |
---|
162 | mytld. IN DS 54511 8 2 983F33D43D1EBB069BF60... |
---|
163 | Метка Алгоритм Тип дайджеста Дайджест |
---|
164 | RSASHA256 |
---|
165 | |
---|
166 | Уберите все пробелы из поля дайджеста и обратите внимание, |
---|
167 | что вам нужен только один "якорь доверия". |
---|
168 | |
---|
169 | Нажмите "Update". Подождите минуту для распространения обновления. |
---|
170 | |
---|
171 | 5. Проверьте и перепроверьте, что новый DS опубликован в родительской |
---|
172 | (корневой) зоне вместсе с существующим (вам придется подождать |
---|
173 | по крайней мере два раза по TTL прежде чем все кэши обновлены): |
---|
174 | |
---|
175 | $ dig @10.20.0.230 DS mytld |
---|
176 | ... |
---|
177 | ;; ANSWER SECTION: |
---|
178 | mytld 900 IN DS 52159 8 2 31F1... |
---|
179 | mytld 900 IN DS 54511 8 2 983F... // <-- новый KSK |
---|
180 | ... |
---|
181 | |
---|
182 | Поскольку оба DS теперь в кэше, мы можем обновить наш KSK. |
---|
183 | |
---|
184 | Затем мы добавим новый KSK в файл зоны, и мы откомментируем |
---|
185 | (уберем) старый KSK: |
---|
186 | |
---|
187 | Было: |
---|
188 | |
---|
189 | $include "/etc/namedb/keys/Kmytld.+008+52159.key"; // KSK |
---|
190 | |
---|
191 | Должно стать: |
---|
192 | |
---|
193 | ;$include "/etc/namedb/keys/Kmytld.+008+52159.key"; // KSK старый |
---|
194 | $include "/etc/namedb/keys/Kmytld.+008+54511.key"; // KSK новый |
---|
195 | |
---|
196 | Не забудьте также увеличить серийный номер. |
---|
197 | |
---|
198 | ... обратите внимание, что мы просто убрали старый KSK - он |
---|
199 | нам более не нужен - обе записи DS есть в родительской зоне, |
---|
200 | так что нам достаточно иметь только один KSK, поскольку |
---|
201 | "на интернете" его DS уже известен. |
---|
202 | |
---|
203 | 6. Давайте подпишем зону новым KSK |
---|
204 | |
---|
205 | $ cd /etc/namedb/keys |
---|
206 | $ sudo dnssec-signzone -o mytld -k Kmytld.+008+54511 ../master/mytld Kmytld.+008+45000 |
---|
207 | |
---|
208 | $ sudo rndc reload mytld |
---|
209 | |
---|
210 | 7. Проверьте с помощью dig - и до и после времени TTL (или сброса кэшей) |
---|
211 | |
---|
212 | $ dig dnskey mytld +multi |
---|
213 | $ dig dnskey mytld +dnssec +multi |
---|
214 | |
---|
215 | 8. Дайте знать преподавателю, что вы хотите, чтобы старый DS был убран из |
---|
216 | корневой зоны (или уберите его сами с помощью web интерфейса) |
---|
217 | |
---|
218 | 9. Посидите и поразмышляйте о том, насколько этот процесс является |
---|
219 | сложным и раздражающим, и насколько лучше было бы если бы все |
---|
220 | обновления ключей делались автоматически. |
---|