Как проверить работу DNSSEC и ГОСТ-2012¶
Проверка делится на два вопроса: «Включён ли DNSSEC?» и «Проверяется ли конкретно подпись ГОСТ-2012 по RFC 9558?». Это разные результаты.
1. Проверьте состояние системной службы¶
Обратите внимание на действующий режим DNSSEC и его доступность для нужного сетевого интерфейса. Если указано, что функция выключена или сервер не поддерживает её, необходимо сначала устранить проблему конфигурации.
resolvectl statistics помогает оценивать результат запросов и проверок, но не доказывает сам по себе поддержку алгоритма 23.
2. Проверьте обычный домен с DNSSEC¶
Выберите публичный или собственный домен, про который вам достоверно известно, что его DNSSEC корректно настроен. Для примера можно использовать ietf.org, однако алгоритм его подписей может меняться и это не тест ГОСТ-2012.
Успешное получение адреса означает, что имя разрешилось, но не гарантирует, что этот конкретный запрос был аутентифицирован DNSSEC. Обратите внимание на сведения о результате: для действительно подтверждённого ответа resolvectl может показывать признак authenticated. Этот признак бывает также у данных из локальных доверенных источников (localhost, /etc/hosts), поэтому проверять следует именно сетевую подписанную зону.
3. Подтвердите RFC 9558 в контрольной зоне¶
Для испытания ГОСТ-2012 выберите DNS-зону, в которой владелец подтвердил подписи с алгоритмом 23 и корректную цепочку доверия до доверенной точки. Само наличие DNSKEY не гарантирует, что подпись RRSIG получена и проверена.
Вместо <домен-контрольной-зоны> подставьте реальный домен из вашего испытательного стенда:
resolvectl query --type=DNSKEY <домен-контрольной-зоны>
resolvectl query --validate=yes <домен-контрольной-зоны>
resolvectl statistics
Угловые скобки обозначают место для замены, а не часть команды. В действительном выводе DNSKEY администратор должен удостовериться, что ключ относится к алгоритму 23 (ECC-GOST12), а затем подтвердить успешную аутентифицированную проверку ответа именно этой зоны. Для полной проверки нужны также корректные DNSSEC-подписи RRSIG и делегирование доверия через DS либо специально настроенный доверенный ключ.
Не используйте обычный результат nslookup, ping или открытия браузера как доказательство успешной проверки RFC 9558. Эти действия показывают доступность, но не указывают алгоритм и факт проверки подписи.
4. Посмотрите сообщения службы¶
Если проверка не проходит:
Сопоставьте ошибку с текущим временем, используемыми DNS-серверами, VPN-профилем, наличием DNSSEC-записей и поддержкой алгоритма. При обращении в поддержку приложите обезличенный фрагмент журнала, версию RPM и описание ожидаемого результата.
5. Как понимать типичные результаты¶
| Ситуация | Что означает | Что проверить |
|---|---|---|
| Имя успешно разрешается | DNS отвечает | Не делает доказанным успешный DNSSEC |
Показано authenticated для сетевого подписанного имени |
Ответ прошёл локальную проверку доверия | Для RFC 9558 отдельно установите, что зона использует алгоритм 23 |
| Имя разрешается при выключенной проверке, но не при строгой | Возможна ошибка DNSSEC, времени, сервера или цепочки доверия | Подписи, DS, DNS-сервер, системное время |
| Отсутствуют подписи DNSSEC для зоны | Зона не подписана либо путь доверия отсутствует | Настройки владельца домена, DNSSEC у регистратора |
В браузере всё работает, но resolvectl показывает отключённый DNSSEC |
Подключение работает без строгой проверки systemd-resolved |
Конфигурацию и реальный путь DNS-запросов |
Сильное подтверждение
Для приёмочных испытаний используйте контрольную зону с действительной ГОСТ-2012-подписью и предусмотрите отрицательный сценарий: неверная или просроченная подпись должна отвергаться. Испытание лучше проводить на отдельном стенде, не изменяя рабочую зону организации.