Раз в несколько лет в интернете происходит событие, которое в кругах технических специалистов ждут как парад планет. 11 октября 2026 года корневая зона DNS поменяет ключ подписи. Для корректно настроенных систем ротация пройдет незаметно. А вот если DNS настроен для галочки, в этот день резолвер может начать выдавать ошибки.

Разбираем с аналитиками BI.ZONE Secure DNS, что это значит, почему произойдет в воскресенье и как за 5 минут проверить, что все в порядке.

Что изменится

DNSSEC — это цепочка доверия: корень подписывает домены верхнего уровня (.com, .ru), те — свои зоны, зоны — конкретные записи. Чтобы подделать адрес сайта условного банка на уровне DNS, злоумышленнику пришлось бы подделать подпись, а для этого нужен ключ. В корне за подпись отвечает отдельный ключ — KSK (key signing key), у которого тоже есть срок годности.

С 11 октября 2026 года корень начнет подписывать зону новым ключом — KSK-2024, его порядковый номер (key tag) — 38696. Старый ключ, KSK-2017 (tag 20326), перестанет использоваться для подписи.

Ключ меняется редко и торжественно, за этим следит агентство по выделению имен и уникальных параметров IANA и некоммерческая организация ICANN. По их планам, хронология такая:

  • 26 апреля 2024 года — новый ключ сгенерировали на церемонии, в присутствии независимых свидетелей.

  • 11 января 2025 года — его выложили в корневую зону для общего доступа, чтобы автоматические резолверы по всему миру успели его скачать.

  • 10 февраля 2025 года — корректно настроенные резолверы стали считать ключ доверенным.

  • 11 октября 2026 года — новый ключ начнет подписывать корень, старый перестанет. Резолвер, не успевший принять новый ключ, потеряет возможность валидировать корневую зону и будет отдавать ошибки вместо ответов.

Жизнь ключа на этом не закончится: ICANN уже запланировала генерацию преемника (KSK-2027) на 30 апреля 2027 года, а удаление KSK-2017 — на 29 апреля 2027 года.

Почему это редкое событие

Частая смена ключа несет операционные риски, а слишком редкая — делает ключ «протухшим». Раньше корень менял ключ так:

  • Первое подписание корня — 15 июля 2010 года (четверг).

  • Первая ротация (KSK-2010 на KSK-2017) — 11 октября 2018 года (четверг), через 8 лет.

Дальше ICANN хочет держать ровный ритм: ориентир — три года. Два года ключ доступен публично и в течение третьего реально подписывает.

Почему воскресенье, а не четверг

ICANN не выбирает день недели — он получается сам.

Дату ротации определяют не календарем, а протоколом. Новый ключ должен «провисеть» в корневой зоне фиксированное время — hold-down period (RFC 5011, обычно несколько десятков дней), после чего правильно настроенные резолверы мира посчитают его доверенным. Если отсчитывать от даты предпубликации (11 января 2025 года) плановый standby-период, ротация приходится как раз на 11 октября 2026 года.

Воскресенье здесь получилось просто из-за календаря: между прошлой ротацией 11 октября 2018 года и новой прошло 2922 дня (ровно 8 лет). Если в вашей компании организовано дежурство специалистов, поставьте смену на выходные. Ближайшее воскресенье — фактор риска.

Что делать за 5 минут до 11 октября

Если DNSSEC у вас «живой», проверьте:

  • Видит ли ваш резолвер новый ключ. dig +dnssec DNSKEY . @<ваш-резолвер> — в ответе должны быть DNSKEY с key tag 38696. Нормально, если пока есть и старый — 20326: в переходное время ключи сосуществуют.

  • Проходит ли валидация целиком. Проверить можно независимым способом — с помощью delv, автономного валидатора из пакета ISC BIND. Ему не нужен запущенный сервер, и работает он с любым стеком. Тестовый домен берите тот, где DNSSEC точно есть, например delv iana.org A — ответ должен быть со статусом trusted, а не bogus или full validity failed. Если есть Unbound — то же самое делает unbound-host -D -v iana.org. Для сервера, который отвечает клиентам, показатель готовности — флаг AD в ответе: dig iana.org A +dnssec @<ваш-резолвер>. У BI.ZONE подписи пока нет, так что на нашем домене вы получите insecure, а не trusted. Это связано не с ошибкой резолвера, а с настройкой зоны. Тестируйте валидацию на подписанном домене, а к себе DNSSEC включайте отдельно.

  • Знаете ли вы, где лежит ваш якорь доверия. В Unbound это auto-trust-anchor-file: файл должен существовать и быть перезаписываемым, иначе резолвер не сможет зафиксировать новый ключ и не заметит смену. В BIND это trust-anchor-file / managed-key-store. В Windows DNS роль якоря играет встроенный набор, который обновляется вместе с обновлениями ОС, то есть критичен актуальный статус обновлений.

  • Прописан ли якорь вручную. Если статический trust-anchor-file, конфиг маршрутизатора, IoT, «вечный» резолвер из прошивки, заранее добавьте ключ 38696, не удаляя старый до конца перехода.

Для Unbound известен конкретный баг, связанный с ротацией ключа: он зафиксирован в changelog и воспроизводится на старых версиях. Для BIND, Windows DNS и встроенных резолверов типичный риск другой — устаревшая версия или несвоевременное обновление, из-за которого новый ключ не был принят вовремя.

Где встречаются проблемы

Вот что нужно проверить:

  • Зашитый якорь доверия (hardcoded trust anchor). Такой резолвер не подхватывает новый ключ автоматически, и после 11 октября все DNSSEC-подписанные зоны начинают отдавать ему SERVFAIL.

  • Автообновление. Старые версии Unbound и BIND, Windows DNS, DNS-стеки в роутерах и IoT либо не реализуют RFC 5011, либо реализуют с ошибками. Чтобы это исправить, обновитесь до версии, которую вендор еще поддерживает, и убедитесь, что файл якоря реально перезаписывается. Если обновление невозможно, заведите статический якорь вручную и заложите его обновление в план следующей ротации.

  • Наличие бага прошлой ротации. Перед ротацией 2017 года в Unbound до версии 1.6.5 была подтвержденная проблема: если файл якоря был создан между публикацией нового ключа и сменой подписи, в нем оказывались два якоря, второй не становился валидным. Починили патчем, который делает валидными оба.

  • Работу DNSSEC в проде. Если валидация фактически выключена, ротация может пройти незаметно, потому что DNSSEC-проверка не выполняется. При этом целостность DNS-ответов не проверяется.

Заключение

Для корректно настроенных систем парад ключей пройдет невидимо: резолвер заранее скачает новый якорь. Для систем с зашитым ключом или устаревшим стеком 11 октября будет выглядеть так, будто сломался не только DNS, но и весь интернет: браузер покажет ошибку вместо сайта, почта перестанет находить серверы. Проверьте DNSKEY . и валидацию заранее, чтобы в понедельник не пришлось разгребать тикеты.