На 11 октября 2026 года запланировано изменение корневого ключа подписи зоны (KSK) DNS — всего лишь во второй раз за всю историю. Этот ключ является основой цепочки доверия DNSSEC, которая позволяет резолверам DNS аутентифицировать ответы с помощью криптографических подписей. Данная процедура называется ротацией KSK. Резолверы с поддержкой проверки должны начать доверять новому ключу до этого перехода, иначе работоспособные веб-сайты могут стать недоступными.
Когда мы писали о первой ротации корневого KSK в 2018 году, мы сталкивались с тем, что резолверы теряли усвоенное доверие к новому ключу во время обновления программного обеспечения или при переносе между машинами. Публикация ключа задолго до события была лишь частью дела. Нам также было необходимо знать, сохранили ли резолверы этот ключ, и у нас не было возможности предоставить пользователям простой способ проверки.
Большинству владельцев сайтов не нужно предпринимать никаких действий в связи с этой ротацией. Если вы управляете резолвером с поддержкой DNSSEC, убедитесь, что он доверяет новому корневому ключу KSK-2024, и следуйте инструкциям производителя программного обеспечения для обновления якорей доверия, если ключ отсутствует. Если вы используете Cloudflare для DNS вашего домена или полагаетесь на 1.1.1.1 и Gateway DNS, вам не нужно предпринимать никаких действий — наши системы уже доверяют KSK-2024.
Чтобы проверить заранее, посетите наш тест готовности к ротации. Он запрашивает у резолвера, используемого вашим браузером, доверяет ли тот новому ключу. В тесте используется RFC 8509: A Root Key Trust Anchor Sentinel for DNSSEC, который мы внедрили в 1.1.1.1 в преддверии ротации.
Где начинается доверие DNSSEC
Резолвер DNS ищет адреса веб-сайтов и других служб для вашего устройства. DNSSEC позволяет ему проверять цифровые подписи в записях DNS, чтобы убедиться в их подлинности и отсутствии изменений. Резолверу также необходимо проверить, что открытые ключи, используемые для проверки этих подписей, принадлежат правильным доменам.
Для cloudflare.com это работает через цепочку доверия от корня DNS к .com, а затем к cloudflare.com. Каждая родительская зона публикует запись подписанта делегирования (DS), содержащую отпечаток открытого ключа дочерней зоны. Например, .com публикует запись DS для cloudflare.com, позволяя резолверу проверить ключ этого домена.
Этой цепочке нужна отправная точка. Однако у корня нет родительской зоны, которая могла бы подтвердить, какие ключи ему принадлежат. Вместо этого резолвер, проверяющий DNSSEC, начинает с корневого открытого ключа или его отпечатка, которому он уже доверяет. Это называется якорем доверия.
У ключей подписи корневой зоны есть две разные задачи. Ключ подписи зоны (ZSK) подписывает записи DNS корня, включая записи DS для доменов верхнего уровня, таких как .com. Ключ подписи ключа (KSK) подписывает список открытых ключей, опубликованных корнем, который называется набором записей DNSKEY. Резолвер использует свой доверенный KSK для проверки этого списка, а затем использует ZSK из этого списка для проверки остальных записей корня.
На диаграмме ниже показана структура для типичной подписанной зоны. Для корня доверие исходит из якоря доверия резолвера, а не из записи DS в родительской зоне.
Наши публикации о сбоях ротации в зонах .de и .al показали последствия неудачных проверок DNSSEC: веб-сайты могут работать нормально, но при этом оставаться недоступными. Ротация корневого KSK меняет отправную точку этих проверок. Если резолвер не доверяет заменяющему ключу, его пользователи могут потерять доступ к сайтам в любых доменах верхнего уровня.
Новый ключ — KSK-2024, идентифицируемый по идентификатору ключа (tag) 38696. Он заменит KSK-2017 с идентификатором 20326 в качестве подписанта набора DNSKEY корневой зоны. Резолверы с поддержкой проверки должны начать доверять новому ключу до этого переключения.
Как резолверы получают новый корневой ключ
RFC 5011 позволяет резолверам автоматически узнавать новый корневой якорь доверия. Корень публикует новый KSK вместе с существующим в своем наборе DNSKEY. Существующий KSK продолжает подписывать этот набор, поэтому резолвер может использовать уже доверенный ключ для проверки записей, содержащих замену.
Прежде чем принять новый ключ в качестве якоря доверия, резолвер ждет не менее 30 дней и продолжает проверять подписанные записи DNSKEY корневой зоны. Новый ключ должен оставаться в проверяемых записях в течение этого периода. После периода ожидания резолвер должен снова успешно проверить записи, содержащие новый ключ, прежде чем принять его.
Для этой ротации KSK-2024 has been published in the root’s DNSKEY set since January 11, 2025. Это дало резолверам с автоматическим обновлением якорей доверия время обнаружить и принять его до запланированного на 11 октября 2026 года изменения подписи. Период ожидания каждого резолвера начинается тогда, когда он впервые видит и проверяет новый ключ.
Что касается нашего резолвера, мы добавили KSK-2024 непосредственно в встроенные якоря доверия программного обеспечения в июле 2024 года, наряду с KSK-2017. Таким образом, резолвер под управлением обновленного ПО имеет новый якорь доступным с самого запуска.
Мы выбрали этот подход из-за опыта, полученного при подготовке к первой ротации. Как описано в нашей статье за 2018 год, обновления программного обеспечения и перенос между машинами приводили к тому, что некоторые резолверы теряли состояние усвоенного якоря доверия. Мы исправили это, обновив программное обеспечение так, чтобы оно включало новый якорь по умолчанию. Включение KSK-2024 в состав ПО также позволяет избежать зависимости от того, сохранит ли каждый резолвер ключ, полученный автоматически.
Несмотря на то, что мы добавили KSK-2024 во встроенные якоря доверия нашего резолвера еще в июле 2024 года, у пользователей 1.1.1.1 и Gateway DNS не было прямого способа проверить, доверяет ли резолвер, отвечающий на их запросы, новому ключу.
На этот раз спросите резолвер
определяет страж якоря корневого ключа (root key trust anchor sentinel) — способ узнать у поддерживающего эту функцию резолвера, доверяет ли он конкретному корневому ключу. Для этого используются обычные DNS-запросы со специально названными доменами.
Наш сайт теста готовности использует этот протокол для проверки KSK-2024. Два имени задают противоположные вопросы: is-ta-38696 спрашивает, доверен ли ключ, а not-ta-38696 спрашивает, не доверен ли он.
Оба имени имеют действительные адресные записи, подписанные DNSSEC. Резолвер с поддержкой стража сначала проверяет эти записи, а затем либо возвращает ответ напрямую, либо заменяет его на SERVFAIL, в зависимости от того, доверяет ли он ключу.
Для резолвера с поддержкой проверки и функции стража ожидаются следующие результаты:
Запрос
KSK-2024 доверяют
KSK-2024 не доверяют
is-ta-38696
Возвращает корректный ответ
Возвращает SERVFAIL
not-ta-38696
Возвращает SERVFAIL
Возвращает корректный ответ
Для проверяющего резолвера с поддержкой стража ответ SERVFAIL для not-ta-38696 является ожидаемым, когда KSK-2024 доверен. Резолвер намеренно отклоняет запрос «не доверен».
Метки стража, такие как root-key-sentinel-is-ta-38696, можно использовать под любым доменом, подписанным DNSSEC. Для наших тестов мы используем dnstest.dev. Вы можете отправить эти два запроса напрямую на 1.1.1.1:
Сайт также проверяет, что обычное подписанное имя разрешается, что намеренно недействительное имя DNSSEC отклоняется, и что резолвер отвечает на запрос стража для текущего корневого ключа. Эти проверки помогают отличить значимый результат от неудачного поиска или неподдерживаемого протокола. Если поддержку стража установить не удается, результат считается неопределенным; это не означает, что новый ключ отсутствует.
Браузерный тест проверяет резолвер, используемый вашим браузером, на который могут влиять Безопасный DNS или VPN. Команды dig выше явно отправляют запросы к 1.1.1.1. Оба варианта предоставляют снимок пути резолвера, отвечающего на эти запросы.
Новый ключ, тот же алгоритм
И KSK-2017, и KSK-2024 используют RSA/SHA-256. В ходе смены ключа заменяется пара ключей, при этом сохраняется тот же метод создания и проверки подписей.
В нашей публикации 2018 года мы писали, что успешная смена ключа откроет путь к обсуждению изменения алгоритма. Восемь лет спустя корневая зона все еще использует RSA.
Замена ключа остается полезной. Это ограничивает время использования одного закрытого ключа и отрабатывает процесс распространения новых якорей доверия, обновления резолверов и вывода из эксплуатации старых ключей. Как показала первая смена ключа, эти шаги могут завершиться сбоем, даже если сама криптография работает корректно.
, соблюдая баланс между регулярной практикой и объемами работы и риском слишком частой смены корневого ключа. Перерыв с 2018 года оказался дольше. The Internet Corporation for Assigned Names and Numbers (ICANN) attributes the delay из-за сбоев, вызванных пандемией, и обновлений оборудования, защищающего закрытые ключи подписи.
Изменение алгоритмов означает, что резолверам нужны как новый якорь доверия, так и программное обеспечение, способное проверять новые подписи. Регулярная смена ключей позволяет операторам тестировать обновление якорей доверия, оставляя алгоритм прежним.
Что будет после октября
Переключение 11 октября изменяет то, какой KSK подписывает набор DNSKEY корневой зоны. Смена ключей продолжается и в 2027 году, когда ICANN plans to revoke KSK-2017, remove it from the root zone, and delete its private key. Прекращение подписания ключом и отзыв доверия к этому ключу — это два разных шага.
ICANN также proposed a future root algorithm rollover to ECDSA P-256. ECDSA создает ключи и подписи меньшего размера, чем используемый сегодня алгоритм RSA. Это предложение не связано с октябрьской заменой ключей, а ECDSA не является постквантовым алгоритмом.
1.1.1.1 теперь проверяет подписи ML-DSA-44, которые разработаны так, чтобы оставаться защищенными от атак с использованием квантовых компьютеров. Чтобы вся цепочка доверия DNSSEC стала постквантово-безопасной, подписанные домены, их родительские зоны и корневая зона также должны перейти на постквантовую криптографию. На уровне корневой зоны это означает внедрение постквантового KSK и обеспечение доверия к нему со стороны резолверов.
Для этого потребуется еще одна смена корневого ключа. Проводимые нами сейчас смены ключей позволяют операторам протестировать распространение сменных якорей доверия, проверить, приняли ли их резолверы, и вывести из эксплуатации старые ключи. Октябрьская смена ключа сохраняет RSA, но отрабатывает обновления якорей доверия, которые понадобятся нам при переходе корневой зоны на постквантовую криптографию. Sentinel предоставляет нам способ проверить, выполнили ли резолверы эти обновления.
Мы призываем DNS-провайдеров и разработчиков резолверов поддерживать . Если ваш резолвер их не поддерживает, попросите своего провайдера или вендора программного обеспечения добавить эту поддержку. Пользователи должны иметь возможность проверить, доверяет ли их резолвер следующему корневому ключу до смены.
На данный момент следующий рубеж — 11 октября. Вы можете проверить готовность вашего резолвера по адресу https://dnstest.dev/ksk-2024. Если вы обслуживаете резолвер с поддержкой проверки DNSSEC, убедитесь, что он доверяет KSK-2024 (идентификатор ключа 38696), и следуйте рекомендациям ICANN и инструкциям вашего вендора ПО, если ключ отсутствует.
