Я только что настроил DNSSEC на своем главном DNS-сервере и при тестировании с копанием с каждого сервера на другой обнаружил, что, хотя на каждом сервере были записи RRSIG, они были разными.
Это ожидаемое поведение? Я вижу, что каждый сервер имеет разное время в подписи, так что это вызывает? Это вообще проблема?
главный результат:
example.com. 600 IN RRSIG NS 5 2 600 (
20181225201200 20181125193702 47985 example.com.
PNY/8BLZrBZ6Ax27MsblQg/QGPyIrS/uK/xAJY9DXw+s
nexXcvRXbEG+3E4yotVtay/ACN4+qMto4Ny87yyM7XFI
t0cBHnRx6n1DqU0jX0ARNWWDjaNRW/PlYrTKeqyXesVj
Cew44FJDXSd+65PxFlvQRDw6ZIdSbDYdXF1OYMw= )
раб результат:
example.com. 600 IN RRSIG NS 5 2 600 (
20181225193928 20181125191401 47985 example.com.
b034jrblNOi/Rmm7o34pRMLwH2Qa4dPuJ7ssTGWam/7z
b8JTaCtgKwrglzBXzcGaUfcxfCTNeBV0o6HXDvQ7kmx4
pZVt8Igvsw/ansIJOsvG+k+nS+ZHTACsgFaOgOegTnNb
+SMspj5n54s/mdMhAMreMKYXBPyVEfN0PFVv574= )
Если это простая установка BIND master / slave (я считаю, что это, вероятно, так), типичный способ выполнения DNSSEC - это подписать главную зону и просто передать (AXFR/IXFR) уже подписанную зону (передача зоны будет включать все записи, а также подписи) оттуда.
Если речь идет именно об этом типе настройки, вы можете ожидать увидеть только разные RRSIG записи на разных серверах имен на короткое время после того, как в главную зону были внесены изменения (например, новые записи или только что обновленные подписи), до того, как обновленная зона будет передана другими серверами имен.
Если разные RRSIG записи сохраняются, может быть что-то не так с настройкой передачи зон между серверами (отсутствие уведомления?), что, конечно, не только задержит синхронизацию RRSIG записи, но все изменения в зоне. (Вы можете сравнить SOA.SERIAL ценности, как с dig +nssearch example.com.)
Как уже было подробно описано Патриком Мевзеком, существуют также принципиально разные подходы к подписи зон, такие как генерация подписей на лету непосредственно на сервере имен, отвечая на запрос, и в этом случае разные подписи с разных серверов могут быть нормой, а не просто происходить в переходном состоянии "рассинхронизация", описанном выше.
Это ожидается: ожидается, что если что-либо изменится в записи, например даты начала / окончания, тогда сама подпись изменится, поскольку она вычисляется по ней. Можно ожидать, а можно и не ожидать увидеть разные отчеты RRSIG на разных серверах имен зоны, но это во многом зависит от настройки, и здесь это не описано достаточно подробно.
Но бывает, см. Следующее.
Тот же ключ (ключевой тег 34505), но каждый из 5 авторитетных серверов имен предоставляет разные RRSIG (если вы сравните время сна в течение 2 секунд с меткой времени начала подписи, вы увидите, что они вычисляются онлайн во время запроса):
$ for ns in `dig NS cloudflare.com. +short` ; do echo -n $ns " " ; dig @$ns cloudflare.com. A +dnssec +short|grep ' 34505 '; sleep 2s; done
ns4.cloudflare.com. A 13 2 600 20190412164722 20190410144722 34505 cloudflare.com. i7WphUbWNj+0sfA0Mp3gLueKvgDvTDF+p4HuD/x+Weu1Cuglp7Cmx/v/ b0icIaYNsUKzm6OCgDnGQNH27SD8lg==
ns5.cloudflare.com. A 13 2 600 20190412164724 20190410144724 34505 cloudflare.com. L9/aRuVFtDunNqowLBgYZzahiWhTw7Y82LeEdseBL0ZgJlQSZj8YjB36 Dj89ozZ4KK6zRxPbFmM5VRwwV/rI3Q==
ns7.cloudflare.com. A 13 2 600 20190412164726 20190410144726 34505 cloudflare.com. khYsYMwEwH/2obxbibonU0gYveHknrtU+pZ6CFr7sLhV2Xv7/DaTKwM7 ABI2mxApVKlEhEz3rQG6XKg/6MPKFg==
ns6.cloudflare.com. A 13 2 600 20190412164728 20190410144728 34505 cloudflare.com. gJZXNyYpTe7WqjJwaA08M/2ysFkoHze5GEV/XpoWU/y6pOLmt4DhzL4I e/PuEvWQ6agBvtdqzGzSb10p6DQx1A==
ns3.cloudflare.com. A 13 2 600 20190412164730 20190410144730 34505 cloudflare.com. N0DwRjQKkagAoWn4WuFekvKhPL/juxzGrrn/lOEOpX7Sqmmt+ibaZJf/ YTsSFPtuCgI2hdMBvr/+b9B6rjv4Bg==
В RRSIG подпись записи вычисляется по всему, что вы видите (кроме самой подписи, конечно), включая, следовательно, владельца (то есть доменное имя слева), а также типы записей (NS здесь), алгоритм (5 что называется «Эллиптическая кривая [ECC]»), номер метки (2 так как example.com имеет 2 метки), оригинальный TTL (600), срок действия подписи (20181225193928) и начало подписи (20181125191401), теги (47985) и имя подписавшего (example.com). Плюс данные в подписываемой записи (то есть все содержимое example.com. NS набор записей ресурсов)
Видеть RFC 4034 который определяет запись RRSIG.
В разделе 3.1 показано:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Covered | Algorithm | Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
и 3.1.8 говорит:
Поле Подпись содержит криптографическую подпись, которая покрывает
RRSIG RDATA (за исключением поля подписи) и RRset
указывается именем владельца RRSIG, классом RRSIG и типом RRSIG
Крытое поле. Формат этого поля зависит от алгоритма в
использование, и эти форматы описаны в отдельных сопутствующих документах.