Смена корневого ключа KSK в октябре 2026 года: действительно ли ваша служба DNS готова?

• Что произойдет 11 октября 2026 года? Когда подготовка — или ее отсутствие — станет очевидной
• Когда подготовка — или ее отсутствие — станет очевидной
• Почему общая готовность интернета не гарантирует вашу готовность Резолвер пропустил период ожидания (hold-down period) Не удалось обновить хранилище ключей «Золотой образ» (golden image) восстановил устаревший якорь доверия Встроенный резолвер никогда не включался в инвентаризацию Предполагалось, что отношения пересылки (forwarding) отменяют это требование
• Резолвер пропустил период ожидания (hold-down period)
• Не удалось обновить хранилище ключей
• «Золотой образ» (golden image) восстановил устаревший якорь доверия
• Встроенный резолвер никогда не включался в инвентаризацию
• Предполагалось, что отношения пересылки (forwarding) отменяют это требование
• В эпоху автономного ИИ ставки возрастают
• 3 способа проверить готовность вашего DNSSEC сегодня Проверьте файлы якорей доверия Проверить запущенный процесс резолвера Выполните тестирование из сетей, которые зависят от каждого резолвера
• Проверьте файлы якорей доверия
• Проверить запущенный процесс резолвера
• Выполните тестирование из сетей, которые зависят от каждого резолвера
• Если ключевой тег 38696 отсутствует
• Самой сложной проблемой может оказаться вовсе не ротация Просроченные записи RRSIG Запись DS больше не соответствует дочернему DNSKEY Отсутствующая запись DS Изменение алгоритмов или ключей во время миграции провайдера
• Просроченные записи RRSIG
• Запись DS больше не соответствует дочернему DNSKEY
• Отсутствующая запись DS
• Изменение алгоритмов или ключей во время миграции провайдера
• В чем заключается ценность Akamai DNS Posture Management
• Не позволяйте ошибке SERVFAIL быть вашей проверкой готовности
• Наибольший риск уже может существовать в вашей среде

Основные выводы

11 октября 2026 года корневая зона DNS перейдет на новый ключ подписи зоны (KSK-2024, ключевой тег 38696). Любой проверяющий резолвер, у которого отсутствует этот якорь доверия, не сможет разрешать как подписанные, так и неподписанные домены, что приведет к массовым ошибкам SERVFAIL.

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

Перед ротацией убедитесь, что ключевой тег 38696 присутствует в файлах конфигурации вашего резолвера, проверьте, что активный демон загрузил его в память, и выполните тестовые запросы (sentinel tests) согласно RFC 8509 из сетей, зависящих от этих резолверов.

Отсутствие корневого якоря доверия приводит к масштабным сбоям DNS во всем резолвере, в то время как проблемы, специфичные для зоны (например, истекшие подписи Resource Record Set [RRSIG], несоответствия записей DS/DNSKEY или ошибки миграции), затрагивают отдельные домены.

Вы должны обеспечить полную видимость вашего DNS-инвентаря и состояния DNSSEC до 11 октября 2026 года. Знание вашей штатной базы (healthy baseline) гарантирует, что во время устранения неполадок вы сможете быстро отличить локальные проблемы конфигурации DNS от сбоев из-за ротации корневых ключей.

11 октября 2026 года корневая зона DNS начнет подписание с помощью нового криптографического ключа. Организации, которые не проверили свои якоря доверия DNSSEC, могут обнаружить проблему по лавине ошибок SERVFAIL — и получить минимум немедленных указаний на то, что вызвало эти ошибки.

Представьте себе следующее: ваша служба поддержки начинает получать тикеты, в которых говорится примерно одно и то же.

• Веб-сайт не загружается.

Веб-сайт не загружается.

• Приложение не может подключиться.

Приложение не может подключиться.

• DNS возвращает SERVFAIL.

DNS возвращает SERVFAIL.

Некоторые сбои могут быть связаны с ротацией корневого KSK. Другие могут быть вызваны истекшими подписями, несоответствием записей DNSSEC или миграцией провайдера, из-за которой была нарушена цепочка доверия.

Симптомы могут выглядеть одинаково, но способы устранения различаются.

Этот пример сценария делает ротацию в октябре 2026 года чем-то большим, чем просто плановое обслуживание DNS. Это также станет проверкой того, понимаете ли вы состояние собственной среды DNS.

Что произойдет 11 октября 2026 года?

DNSSEC помогает защитить ответы DNS от несанкционированного изменения, позволяя резолверам проверять подлинность получаемой информации.

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

Официальный график ротации IANA подтверждает, что на 11 октября 2026 года запланировано начало подписания корневого набора записей DNSKEY новым корневым ключом — KSK-2024, ключевой тег 38696. Текущий ключ подписания — KSK-2017, ключевой тег 20326 — больше не будет его подписывать. Отзыв KSK-2017 запланирован на I квартал 2027 года, поэтому 11 октября является критической вехой, но не финальной.

Когда подготовка — или ее отсутствие — станет очевидной

Для проверяющих резолверов это четкий операционный рубеж. Если во время ротации резолвер не доверяет KSK-2024, он может оказаться не в состоянии проверить корневую зону. Поскольку любая цепочка доверия начинается с корня, последствия не ограничиваются доменами с поддержкой DNSSEC: резолвер, который не может проверить корень, также не может безопасно установить, что неподписанный домен действительно неподписан.

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

Этот процесс начался не в октябре 2026 года. Администрация адресного пространства сети Интернет (IANA) внедрила KSK-2024 в корневую зону 11 января 2025 года. Резолверы, использующие автоматический процесс, определенный в RFC 5011, должны были начать доверять новому ключу по истечении обязательного 30-дневного периода ожидания.

11 октября 2026 года — это просто момент, когда подготовка — или ее отсутствие — становится видимой.

Почему общая готовность интернета не гарантирует вашу готовность

Большинство современных резолверов спроектированы так, чтобы автоматически обновлять свои якоря доверия. Это обнадеживает, но это не то же самое, что проверка того, что каждый резолвер в вашей среде завершил обновление.

Автоматические обновления якорей доверия могут завершиться неудачно по нескольким причинам, среди которых:

• Резолвер пропустил период ожидания (hold-down period)

Резолвер пропустил период ожидания (hold-down period)

• Не удалось обновить хранилище ключей

Не удалось обновить хранилище ключей

• «Золотой образ» (golden image) восстановил устаревший якорь доверия

«Золотой образ» (golden image) восстановил устаревший якорь доверия

• Встроенный резолвер никогда не включался в инвентаризацию

Встроенный резолвер никогда не включался в инвентаризацию

• Предполагалось, что отношения пересылки (forwarding) отменяют это требование

Предполагалось, что отношения пересылки (forwarding) отменяют это требование

Резолвер пропустил период ожидания (hold-down period)

RFC 5011 требует, чтобы резолвер непрерывно отслеживал новый ключ в течение 30-дневного периода ожидания, прежде чем принять его как доверенный. Резолвер, который был отключен, изолирован, пересоздан или восстановлен в течение соответствующего периода, мог не завершить этот процесс должным образом.

Не удалось обновить хранилище ключей

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

«Золотой образ» (golden image) восстановил устаревший якорь доверия

Восстановление резолвера из старого образа виртуальной машины, контейнера или бэкапа программно-аппаратного комплекса может вернуть якорь доверия, существовавший на момент создания образа. Система может выглядеть актуальной, но при этом продолжать использовать устаревшую конфигурацию DNSSEC.

Встроенный резолвер никогда не учитывался в инвентаризации

Брандмауэры, балансировщики нагрузки, устройства безопасности, офисные шлюзы и другая инфраструктура могут выполнять валидацию DNSSEC независимо. Такие системы легко упустить из виду, если организация не ведет полный учет своей резолвящей инфраструктуры.

Считалось, что отношения пересылки исключают это требование

Пересылка запросов восходящему провайдеру не освобождает от ответственности резолвер, который сам выполняет валидацию DNSSEC. Если ваш резолвер производит валидацию на этом пути запроса, ему требуется KSK-2024 независимо от того, куда он пересылает запросы.

Поэтому вопрос заключается не в том, обновилась ли большая часть интернета. Вопрос в том, доверяет ли каждый резолвер, от которого зависят ваши пользователи и приложения, тегу ключа 38696.

В эпоху агентного ИИ ставки высоки как никогда

В эпоху агентного ИИ операционные ставки ошибки SERVFAIL возрастают экспоненциально. Если человек-пользователь может просто обновить сломанную страницу в браузере, то автономный ИИ-агент, выполняющий многоэтапные вызовы функций или оркестрацию микросервисов, столкнется с мгновенным сбоем в выполнении рабочих процессов.

Единственный невалидированный корневой якорь доверия может запустить каскадные циклы сбоев в межмашинных интеграциях, остановив инференс в реальном времени и автоматизированные корпоративные операции.

3 способа проверить готовность к DNSSEC уже сегодня

ICANN настоятельно рекомендует операторам резолверов не рассчитывать на то, что автоматические обновления пройдут успешно. Эти три проверки готовности помогут выявить уязвимости до проведения ротации:

• Проверьте файлы якоря доверия

Проверьте файлы якоря доверия

• Проверьте запущенный процесс резолвера

Проверьте запущенный процесс резолвера

• Проведите тестирование из сетей, которые зависят от каждого резолвера

Проведите тестирование из сетей, которые зависят от каждого резолвера

Проверьте файлы якоря доверия

Убедитесь, что тег ключа 38696 присутствует в соответствующей конфигурации якоря доверия для каждой реализации резолвера.

Распространенные пути или файлы включают:

• bind.keys для BIND

bind.keys для BIND

• root.key для Unbound и некоторых конфигураций PowerDNS Recursor

root.key для Unbound и некоторых конфигураций PowerDNS Recursor

• root.keys для Knot Resolver

root.keys для Knot Resolver

Расположение файлов и поведение при обновлении различаются, поэтому командам также следует следовать текущим рекомендациям производителя резолвера.

Проверьте запущенный процесс резолвера

Правильный файл не всегда означает, что запущенный демон загрузил правильный ключ.

Например, операторы BIND могут проверить управляемые ключи и корни безопасности с помощью таких инструментов, как rndc managed-keys status и, где это поддерживается, rndc secroots. Операторы Unbound могут проверить информацию о якоре доверия с помощью unbound-anchor.

Цель состоит в том, чтобы проверить состояние активного резолвера, а не просто конфигурацию, сохраненную на диске.

Проведите тестирование из сетей, которые зависят от каждого резолвера

Root Key Trust Anchor Sentinel defined in RFC 8509 предоставляет способ проверить, доверяет ли валидирующий резолвер конкретному корневому ключу.

Используя подходящий домен, подписанный DNSSEC, команды должны протестировать метки на основе:

• root-key-sentinel-is-ta-38696

root-key-sentinel-is-ta-38696

• root-key-sentinel-not-ta-38696

root-key-sentinel-not-ta-38696

При тестировании через совместимый валидирующий резолвер запрос is-ta должен завершиться успешно, если резолвер доверяет тегу ключа 38696. Соответствующий запрос not-ta должен выдать SERVFAIL, когда этому ключу доверяют.

Одно предостережение: механизм сентенела работает только на резолверах, реализующих RFC 8509. Если оба запроса разрешаются успешно, результат неопределен (это не прохождение теста). Резолвер не поддерживает этот тест, и вам следует напрямую проверить состояние его якоря доверия с помощью проверок, описанных выше.

Запустите тест из реальных сетей, с тех локаций и приложений, которые зависят от резолвера. Успешный тест одного корпоративного резолвера не доказывает, что филиал, облачная среда или устройство используют такое же состояние якоря доверия.

Страница ICANN Root Zone KSK Rollover содержит актуальные рекомендации для операторов, а RFC 8509 объясняет механизм сентенела.

Если тег ключа 38696 отсутствует

Обнаружить проблему сейчас — это хороший результат. Обнаружить ее 11 октября — плохой.

Если у резолвера нет KSK-2024, проверьте, включены ли автоматические обновления якоря доверия, и убедитесь, что процесс резолвера имеет права на запись в свою директорию якоря доверия.

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

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

Самая сложная проблема может быть не в ротации

11 октября породит сильное предположение при устранении неполадок: если валидация DNSSEC не удалась, значит, в этом виновата ротация.

Однако некоторые сбои будут иметь совершенно другие причины, в том числе:

• Истекшие записи RRSIG

Истекшие записи RRSIG

• Запись DS больше не соответствует DNSKEY дочерней зоны

Запись DS больше не соответствует DNSKEY дочерней зоны

• Отсутствующая запись DS

Отсутствующая запись DS

• Изменения алгоритмов или ключей во время миграции провайдера

Изменения алгоритмов или ключей во время миграции провайдера

Истекшие записи RRSIG

Подписи DNSSEC имеют определенные периоды действия. Если зона не подписывается заново до истечения срока действия ее записей RRSIG, валидирующие резолверы будут отклонять ее ответы.

Запись DS больше не соответствует DNSKEY дочерней зоны

Если DNSKEY ротируется, но соответствующая запись DS не обновляется у регистратора или в родительской зоне, это нарушает цепочку доверия. Валидирующие резолверы могут выдавать SERVFAIL, даже если домен продолжает отвечать авторитетно.

Отсутствующая запись DS

Отсутствующая запись DS сама по себе обычно не приводит к SERVFAIL. Вместо этого она создает незащищенное делегирование: родительская зона не предоставляет аутентифицированной ссылки на дочернюю зону. Домен может продолжать разрешаться, но защита DNSSEC больше не установлена.

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

Изменения алгоритмов или ключей во время миграции провайдера

Миграция провайдера DNS может привести к несоответствиям между алгоритмами, записями DNSKEY, подписями и записями DS родительской зоны. Возникающая в результате ошибка может проявиться только тогда, когда валидирующий резолвер оценивает всю цепочку целиком.

Одно различие помогает быстро отделить эти проблемы от проблемы с корневым якорем доверия: отсутствие корневого якоря доверия нарушает разрешение широко для всей совокупности резолверов, в то время как вышеуказанные сбои затрагивают отдельные зоны. Если некоторые домены разрешаются нормально, а другие нет, маловероятно, что причиной является корневой ключ.

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

В чем заключается польза Akamai DNS Posture Management

Смена ключей — это конкретное событие, но лежащая в его основе проблема носит более масштабный характер: большинство предприятий не управляют DNS через единого провайдера, команду или авторитетный источник достоверных данных.

Когда 11 октября произойдет смена ключей, команды неизбежно потратят часы на поиски фантомных проблем с корневыми ключами всякий раз, когда возникает ошибка SERVFAIL. Хотя конфигурации внутренних рекурсивных резолверов требуют прямой проверки, Akamai DNS Posture Management устраняет лишний шум, гарантируя, что все принадлежащие вашему предприятию зоны, DS-записи и RRSIG исправны, поэтому вы мгновенно узнаете, является ли сбой внутренним или внешним.

Благодаря аналитическим данным Akamai DNS Posture Management в реальном времени вы получаете:

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

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

• Непрерывная проверка цепочки доверия: проверка соответствия DS-записей родительской зоны записям DNSKEY дочерней зоны, а также выявление разорванных или небезопасных делегирований до того, как с ними столкнутся пользователи.

Непрерывная проверка цепочки доверия: проверка соответствия DS-записей родительской зоны записям DNSKEY дочерней зоны, а также выявление разорванных или небезопасных делегирований до того, как с ними столкнутся пользователи.

• Мониторинг истечения срока действия подписей: выявление проблем с DNSSEC, таких как отсутствующие DS-записи, несоответствия DS/DNSKEY, разорванные цепочки доверия и истекающие сроки действия записей RRSIG, которые могут привести к сбоям проверки и нарушениям работы сервисов.

Мониторинг истечения срока действия подписей: выявление проблем с DNSSEC, таких как отсутствующие DS-записи, несоответствия DS/DNSKEY, разорванные цепочки доверия и истекающие сроки действия записей RRSIG, которые могут привести к сбоям проверки и нарушениям работа сервисов.

• Конфигурация и обнаружение отклонений: выявление несанкционированных или необъяснимых изменений в записях DNSKEY, DS и других записях, чувствительных к безопасности. Изменение без утвержденного тикета может указывать на неполную ротацию, операционную ошибку или несанкционированную активность.

Конфигурация и обнаружение отклонений: выявление несанкционированных или необъяснимых изменений в записях DNSKEY, DS и других записях, чувствительных к безопасности. Изменение без утвержденного тикета может указывать на неполную ротацию, операционную ошибку или несанкционированную активность.

• Базовый уровень до смены ключей: документирование того, как выглядело корректное разрешение DNS до 11 октября 2026 года. При появлении SERVFAIL команды могут быстро сравнить текущие условия с базовым уровнем и ответить на первый вопрос при реагировании на инцидент: влияет ли на нас смена корневого ключа или что-то изменилось в нашей собственной среде?

Базовый уровень до смены ключей: документирование того, как выглядело корректное разрешение DNS до 11 октября 2026 года. При появлении SERVFAIL команды могут быстро сравнить текущие условия с базовым уровнем и ответить на первый вопрос при реагировании на инцидент: влияет ли на нас смена корневого ключа или что-то изменилось в нашей собственной среде?

Не позволяйте ошибке SERVFAIL стать вашей проверкой на готовность

Для организаций, которые заранее проверяют свои якоря доверия, тестируют резолверы и проверяют цепочки DNSSEC, смена KSK в октябре 2026 года, вероятно, будет представлять собой не более чем рутинную операцию по безопасности.

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

• Убедитесь, что присутствует метка ключа 38696.

Убедитесь, что присутствует метка ключа 38696.

• Проверьте конфигурацию и запущенный процесс.

Проверьте конфигурацию и запущенный процесс.

• Протестируйте из сетей, которые зависят от каждого резолвера.

Протестируйте из сетей, которые зависят от каждого резолвера.

Затем выйдите за рамки корневого ключа и проверьте состояние DNSSEC зон, принадлежащих вашей организации.

Наибольший риск уже может существовать в вашей среде

Сама смена ключей не является наибольшим риском.

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

Готовы проверить состояние вашей DNS до 11 октября 2026 года? Изучите возможности Akamai DNS Posture Management или свяжитесь с нашими экспертами по безопасности DNS, чтобы запланировать комплексную оценку состояния DNS.

Об авторе (авторах)

Понит Аттили (Ponith Attili)

Понит Аттили — старший инженер-программист в компании CheckRed, специализирующийся на безопасности DNS, облачной безопасности и крупномасштабных распределенных системах. Он увлечен созданием безопасных, масштабируемых и высокопроизводительных платформ, которые повышают надежность и видимость инфраструктуры DNS, облаков и SaaS. Ему нравится исследовать новые технологии и инновационные подходы, уделяя особое внимание преобразованию сложных требований в понятные и интуитивные решения. Обладая большой страстью к безопасности DNS и облаков, он постоянно стремится повышать устойчивость и доверие к современным системам.

Теги