Перейти к содержанию

ГОСТ в DNSSEC: новые алгоритмы и вывод исторического ECC-GOST

Что опубликовано к 2026 году

В апреле 2024 года опубликован RFC 9558: представление подписей ГОСТ Р 34.10-2012 и хэшей ГОСТ Р 34.11-2012 в DNSKEY, RRSIG и DS для DNSSEC. RFC относится к Independent Submission / Informational; сама публикация не делает ГОСТ-2012 обязательным для всех DNS-серверов и резолверов.

В ноябре 2025 года опубликован RFC 9906 категории Proposed Standard: прекращается использование старого ECC-GOST, основанного на ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94, в DNSSEC. В документе прямо указано, что профиль ГОСТ-2012 из RFC 9558 — отдельный алгоритм, требования к которому данным запретом не меняются.

Почему эта тема важна

В DNSSEC зашифрованного DNS-трафика нет: электронные подписи удостоверяют целостность и происхождение DNS-записей. Не следует писать «ГОСТ-шифрование DNSSEC» — корректно говорить о ГОСТ-подписях и хэшах. Для шифрования DNS-запросов существуют другие транспортные механизмы, например DoT/DoH, где нужно отдельно согласовывать TLS.

Этап Данные Цель
Публикация DNSKEY Открытый ключ зоны Проверка подписи
Создание RRSIG Подпись набора DNS-записей Целостность зоны
Публикация DS Делегирование доверия к ключу Цепочка доверия
Проверка валидатором Подпись, ключ и DS Доверенный DNS-ответ

Статус и совместимость

Валидатор должен понимать идентификатор алгоритма и формат ключа; одного наличия EC-RDSA в ядре недостаточно. Возможности BIND, Knot DNS, PowerDNS, Unbound, системных библиотек и DNSSEC-валидаторов проверяются отдельно и по версиям.

Не переносите старые конфигурации с ECC-GOST на ГОСТ-2012 простым переименованием алгоритма: изменяются алгоритмический профиль и представление ключей. Обновление зоны DNSSEC требует управляемой смены ключей и совместимости всех участвующих валидаторов.

Разница между идентификатором алгоритма и самой проверкой

DNSSEC — это подписи RRset и делегирование доверия. Документ RFC 9558 определяет, как открытый ГОСТ-2012 ключ помещается в DNSKEY, как формируется/проверяется подпись в RRSIG и какие значения используются в DS. Система должна интерпретировать идентификаторы, формат подписи, сериализацию исходных DNS-данных и состояние доверенных якорей одновременно.

Подписанная зона: DNSKEY + RRSIG + DS (родительская зона)
             |
      [DNSSEC validator]
             |
       идентификатор ГОСТ-2012 → алгоритм ГОСТ Р 34.10
             |                              |
        проверка подписи <── canonical RRset + параметр ключа
             |
       secure / insecure / bogus

secure означает построенную доверенную цепочку; insecure может быть допустимым результатом политики при отсутствии подписанной делегации; bogus отражает ошибку требуемой проверки. Нельзя автоматически интерпретировать любую ошибку DNS как криптографическое неподтверждение ГОСТ.

Миграция с прежнего ECC-GOST

RFC 9906 — нормативный Standards Track об отказе от старого ECC-GOST в DNSSEC. Он не удаляет и не отменяет профиль ГОСТ-2012 RFC 9558. План миграции должен охватывать имена DNSKEY/RRSIG/DS, распространение DS через родительскую зону, TTL и фазу совместимости валидаторов; простая подмена номера алгоритма без перенастройки ключей недопустима.

Проверяемое состояние НАЙС.ОС

Для systemd-resolved ранее испытана поддержка RFC 9558 через два криптографических backend (libgcrypt и OpenSSL/GOST Engine), однако в эксплуатационной инструкции необходимо различать версию RPM, фактически установленный backend, наличие доверенного якоря и полный DNSSEC-путь. Обзор DNSSEC ГОСТ, пошаговая проверка, матрица стандарта.

Что проверить при внедрении

  • Публичный DNSKEY опубликован корректно; номер алгоритма и длина ключа соответствуют профилю.
  • RRSIG создаётся для корректно канонизированного RRset, временные интервалы подписи действительны.
  • DS согласован с родительской зоной и корректно связывает зону с цепочкой доверия.
  • Отрицательные тесты: испорченная подпись, неверный DS, просроченный RRSIG, неподдерживаемый алгоритм и отсутствие сетевого доступа.
  • Не смешивать с защитой конфиденциальности запросов по DoT/DoH.

Источники: RFC 4033, RFC 4034, RFC 4035, RFC 9558, RFC 9906.

Источники