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

File dnssec-bind-manual-ksk-rollover-vRU.txt, 11.1 KB (added by trac, 5 years ago)
Line 
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
231. Перейдите в ключевой каталог:
24
25    $ cd /etc/namedb/keys/
26    $ ls K*
27
282. Точно как в шаге 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
373. Создайте набор записей 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
784. Добавьте новый 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
915. Давайте подпишем зону старым и новым 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
996. Проверьте
100
101  $ dig @127.0.0.1 dnskey mytld +multi
102  $ dig @127.0.0.1 dnskey mytld +dnssec +multi
103
104
1057. Залогиньтесь в RZM и намжите "Update".  Вы заметите что RZM обнаружил
106   ваш новый KSK.  Проверьте что записи DS соответствуют содержимому файла
107   dsset-mytld-newksk, который вы создали выше.
108   Если все нормально, нажмите на "глаз" около SHA256, чтобы отметить
109   его как действующий, потому пометьте старую запись DS для удаления.
110   Нажмите "Update".
111
1128. Проверьте с помощью dig - и до и после времени TTL (например,
113   два раза по максимальному TTL зоны mytld и записи DS)
114
115  $ dig dnskey mytld +multi
116  $ dig dnskey mytld +dnssec +multi
117
1189. Уберите СТАРЫЙ 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
13110. Давайте подпишем зону только лишь новым 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
13811. Проверьте с помощью dig - и до и после времени TTL (например,
139    два раза по максимальному TTL зоны mytld и записи DS)
140
141  $ dig dnskey mytld +multi
142  $ dig dnskey mytld +dnssec +multi
143
14412. Обратите внимание на то, что двойное подписывание требует связываться
145    c администратором родительской зоны только один раз, тогда как
146    предварительная публикация требует двух сеансов.
147
148* Метод 2: Обновление KSK предварительной публикацией
149
1504. Закачайте набор записей 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
1715. Проверьте и перепроверьте, что новый 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
2036. Давайте подпишем зону новым 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
2107. Проверьте с помощью dig - и до и после времени TTL (или сброса кэшей)
211
212  $ dig dnskey mytld +multi
213  $ dig dnskey mytld +dnssec +multi
214 
2158. Дайте знать преподавателю, что вы хотите, чтобы старый DS был убран из
216   корневой зоны (или уберите его сами с помощью web интерфейса)
217
2189. Посидите и поразмышляйте о том, насколько этот процесс является
219сложным и раздражающим, и насколько лучше было бы если бы все
220обновления ключей делались автоматически.