DNSSEC и синхронизация времени : рекомендации и реальная жизнь

Павел Храмцов

Расширение безопасности DNS, или DNSSEC, призвано детектировать подмену ответов авторитетных DNS-серверов и тем самым предотвратить атаки типа «отравление кеша».

Концепция DNSSEC позволяет DNS-резолверу (серверу, который обслуживает приложения конечного клиента) принимать ответы от любого DNS-сервера, где бы он ни был расположен и под чьим бы управлением ни находился. При этом за счёт построения цепочки доверия на основе криптографии с открытым ключом ответы проверяются на корректность и истинность. На основе этой проверки DNS-резолвер принимает решение об их трансляции и соответствующим образом отвечает приложениям конечного клиента.

При таком раскладе поломка механизма DNSSEC может привести к полному прекращению процедуры резолвинга. Такие сервисы, как, например, веб или электронная почта, станут недоступны. Вообще говоря, недоступными станут любые сервисы, в которых используются доменные имена.

Наиболее наглядно это видно, когда поломка случается в критически важных точках, например, на серверах корня DNS (m.root-servers.net – 2010, j.root-servers.net – 2013), в национальных зонах (например, зона .ru — 2024) или в зонах домена in-addr.arpa (зоны под управлением APNIC — 2016).

В настоящее время по технологии DNSSEC подписано примерно 25 миллионов доменов (столько DS размещено в файлах зон доменов разных уровней) [1]. При этом доменов второго уровня в доменах верхнего уровня (Top Level Domains – TLD) всего насчитывается чуть меньше 387 миллионов. Если учесть, что среди подписанных доменов доля доменов третьего уровня и ниже исчезающе мала, то DNSSEC используется примерно для 6,5% доменных имён.

Однако следует иметь в виду, что на 30 марта 2026 года из 1594 TLD подписаны 1486 (93%) [2]. Это все домены общего назначения и подавляющая часть национальных доменов. В национальной доменной зоне .ru на 30 марта 2026 года из 6 115 946 доменов подписано только 9793 (0,16%) [3].

В целом статистика применения DNSSEC на 30 марта 2026 года представлена на рисунке 1 [4].

Рис.1. Статистика внедрения DNSSEC в доменах верхнего уровня.

Цепочка доверия в DNSSEC выстраивается от корня системы DNS. Следовательно, поломка DNSSEC в TLD приведёт к «отключению» всего TLD, даже если домены второго и ниже уровней подписаны не будут.

Самая частая причина таких поломок – это ротация ключей DNSSEC. Как показывает статистика [4], до 30% подписанных доменов, главным образом национальных, имели те или иные проблемы с применением DNSSEC. Большая часть «поломок» приходится на NSEC3 (70%).

При использовании DNSSEC администратор DNS-зоны встречается с последовательностью действий (последовательность изменения набора ключей/подписей, например) и установками времени в полях записей описания ресурсов DNSSEC.

Следующие поля определяют временные параметры и временные интервалы:

А) TTL – время кеширования записей описания ресурсов на DNS-резолверах. Это стандартное поле для любой записи описания ресурсов (resource record — RR), которая имеет формат:

[Name] [TTL] [Class] [Type] [RDATA]

Где:

[Name] – доменное имя;

[TTL] – время кеширования на DNS-резолвере;

[Class] – IN/CH/CS/HS;

[Type] – тип записи (например, А – задает IP-адрес формата IPv4);

[RDATA] – содержание данного поля зависит от типа записи.

Записи, определённые в стандартах DNSSEC, как и прочие RR имеют поле TTL.

Б) Поля времени в записи RRSIG (подпись набора однотипных RR-записей) в поле [RDATA]:

Original TTL – установленное на авторитетном сервере время TTL для набора RR (RR Set). Данное поле необходимо указывать, т.к. в ответах DNS-резолверов время TTL всё время уменьшается, фактически показывая, сколько времени осталось записи существовать в кеше резолвера.

Signature inception – дата и время начала действия подписи. Указывается с точностью до секунды в секундах от 1 января 1970 года.

Signature expiration — дата и время окончания действия подписи. Указывается с точностью до секунды в секундах от 1 января 1970 года.

Два этих последних параметра абсолютного времени определяют время жизни (валидности) подписи (RRSIG). Максимальный период, который можно задать этими двумя параметрами, равен примерно 136 годам. Поскольку данные поля задают десятичные числа без знака и имеют ограниченную размерность, то возможна ситуация wrap-around, когда время окончания действия подписи выходит за максимально возможное десятичное число (32-битовое целое без знака). В этом случае число, определяющее начало периода действия подписи, будет больше числа, задающего конец периода действия подписи.

Числа эти могу быть заданы либо в формате целого десятичного числа, либо в виде «YYYYMMDDHHMMSS». Форматы легко различимы: 32-битное целое – это десятичное числоне более 10 цифр, а во втором случае всегда будет ровно 14 цифр.

Собственно, вокруг этих параметров и происходят «пляски с бубнами», которые возникают при ротации ключей.

Ротация ключей определяется требованиями безопасности. Ключ можно подобрать или сломать, хоть это и сложно. Следовательно, ключ нужно регулярно менять, т.е. ключ действителен в течение ограниченного промежутка времени. Соответственно, и подписи наборов RR-записей тоже надо менять в порядке замены ключей.

Таким образом, понятие времени жизни ключа, процедура его замены и синхронизация по времени ключей и других записей DNS становится критически важной для работы всего Интернета.

А ещё важна последовательность действий – «чтобы всё не случилось одновременно» или в неправильном порядке.

Переподписывание зоны и ротация ключей (это, вообще говоря, не одно и то же) выглядит следующим образом:

1. Выбор алгоритмов (например, RSA/SHA-256, ECDSAP256SHA256) и политики ротации ключей (ZSK — ключ подписи RR-сетов, KSK — ключ подписи ключей).
2. Создание пары новых ключей (публичный и приватный).
3. Подписи всех записей зоны новыми ключами. В результате создаётся подписанный файл зоны.
4. Временное хранение старых и новых ключей (pub-переход) для обеспечения плавного перехода без перерыва в обслуживании.
5. Если ротируется KSK, хеш нового публичного ключа (DS-запись) отправляется в корневую зону (ICANN для gTLD) для проверки.
6. Переподписанный файл зоны загружается на DNS-серверы, обновляется серийный номер зоны (SOA) для инициации передачи зон (AXFR/IXFR).

Первый пункт в этом списке имеет косвенное отношение ко времени – типа, «всё течет, всё изменяется», и алгоритмы тоже меняются.

Так какие же временные интервалы и значения параметров времени рекомендовано устанавливать? Ниже приведены две основные рекомендации:

• частоту ротации ключа ZSK разумно взять в интервале от одного до трёх месяцев (в национальных доменах Российской Федерации – три месяца);
• частоту ротации ключа KSK рекомендуют выбрать в 1-3 года.

Толстовское «гладко было на бумаге…» справедливо и к исполнению данных рекомендаций.

Согласно данным IANIX [5], c 2009 года в TLD зафиксирована 221 поломка DNSSEC.

Чаще всего проблемы связаны с ротацией ключей.

Во-первых, встречается ситуация, когда новый KSK уже опубликован, а в старшей зоне остаётся старая запись DS. Таким образом, проблема вызвана неправильной последовательностью действий во времени.

Во-вторых, DNS-резолверы кешируют записи описания ресурсов на время TTL. Кешируют в том числе ключи и подписи DNSSEC. Если ключ будет удалён из зоны раньше, чем истекает время его кеширования (TTL), то резолверы будут выдавать ошибки.

В-третьих, ротация ключей KSK требует координации с размещением DS-записи в старшей зоне. Данная процедура неавтоматическая и требует участия персонала. Как показывает практика, на этом этапе возникает много несогласованности, что приводит к «поломкам».

В-четвертых, критической ошибкой является удаление ключа из файла зоны, который связан DS-записью в кеше. Здесь возможно неправильно выбрать соотношения времени жизни записи/ключа и TTL.

В-пятых, к ошибкам может приводить наличие старых ключей в зонах.

А ещё к ошибкам может приводить процедура генерации ключей в различном специализированном ПО. Так, например, в зоне .ru 16 августа 2019 года резолверы не могли найти подписи RR-сетов [6]. Или можно вспомнить другой сбой в зоне .ru 30 января 2024 года, о причине которого Координационный центр национального домена сети Интернет написал – «главной причиной сбоя стало несовершенство программного обеспечения, используемого при создании ключей шифрования» [7].

А сами по себе поломки DNSSEC могут привести к недоступности серверов времени, как это случилось с NTP-серверами NIST 12 сентября 2016 года, когда произошёл сбой DNSSEC на nist.gov. Надо отметить, что это был не первый сбой DNSSEC на nist.gov и даже не первый сбой DNSSEC на nist.gov за период в 30 дней. Это был полный сбой DNSSEC, затронувший все имена на nist.gov, включая веб-сайты, службу NTP (time.nist.gov) и все другие интернет-сервисы nist.gov, требующие функционирующей службы DNS [9].

Но на этом тема DNS/time не исчерпана. Есть ещё DNS over TLS и DNS over HTTPS. TLS-сертификаты, как известно, тоже «живут» не вечно. Часто встречаются рекомендации включить на своих сетях/компьютерах NTP, чтобы время не мешало DNS-резолвингу [11]. Но, как мы видим из приведённого выше примера с NIST, проблемы с DNSSEC могут породить «замкнутый круг».

В общем, если говорить коротко, то DNSSEC решил одну проблему, а породил массу других. В том числе и организационных. Гидра, одним словом.
И самое главное – если нужно будет подменить национальную зону, то PTI [12] всегда это сможет сделать, т.к. контролирует корень доверия. Но там, во-первых, как я надеюсь, работают честные люди, а во-вторых, со стороны независимого мониторинга это можно обнаружить вовремя и принять меры.

Источники:

[1] Proceedings of the 2025 ACM Internet Measurement Conference, https://dl.acm.org/doi/proceedings/10.1145/3730567?tocHeading=heading4
[2] https://www.iana.org/domains/root/db
[3] https://statdom.ru/tld/ru/report/domainsdnsseccount/#31
[4] https://stats.dnssec-tools.org/#/?top=tlds&tld_tab=0
[5] Proceedings of the 2025 ACM Internet Measurement Conference, https://dl.acm.org/doi/proceedings/10.1145/3730567?tocHeading=heading4
[6] https://ianix.com/pub/dnssec-outages.html
[7] https://ianix.com/pub/dnssec-outages/20190816-ru/
[8] https://cctld.ru/media/news/kc/35566/
[9] https://ianix.com/pub/dnssec-outages/20160912-nist.gov/
[10] https://ianix.com/pub/dnssec-outages/20141203-fbi.gov/
[11] https://cyounkins.medium.com/encrypted-dns-ntp-deadlock9e378940b79f
[12] https://pti.icann.org/

Об авторе:

Храмцов Павел Брониславович, к.т.н., доцент, руководитель проектов DNS АО «ЦВКС МСК-IX», научный руководитель учебных проектов Фонда развития сетевых технологий «ИнДата», лауреат награды Virtuti Interneti 2025
© Павел Храмцов 2026