Ключи от интернета сменятся 11 октября. Вы готовы?06.10.2026 20:50

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

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

Большинству операторов сайтов не нужно ничего менять в связи с этой ротацией. Если вы используете DNSSEC-валидирующий резолвер, проверьте, доверяет ли он новому корневому ключу KSK-2024. Если ключ отсутствует, следуйте инструкциям поставщика программного обеспечения по обновлению доверенных якорей. Если вы используете Cloudflare для DNS своего домена или полагаетесь на 1.1.1.1 и Gateway DNS, никаких действий предпринимать не нужно — наши системы уже доверяют KSK-2024.

Чтобы проверить готовность заранее, посетите наш тест готовности к ротации. Он проверяет, доверяет ли новый ключ резолвер, которым пользуется ваш браузер. Тест использует RFC 8509: маркер доверенного якоря корневого ключа для DNSSEC. Мы реализовали его в 1.1.1.1 до начала ротации.

С чего начинается доверие в DNSSEC

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

Для cloudflare.com это работает как цепочка доверия от корня DNS к .com, а затем к cloudflare.com. Каждый родительский домен публикует запись Delegation Signer (DS), содержащую отпечаток открытого ключа дочернего домена. Например, .com публикует запись DS для cloudflare.com, позволяя резолверу проверить ключ этого домена.

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

Ключи подписи корневой зоны выполняют две разные задачи. Ключ подписи зоны (ZSK) подписывает DNS-записи корневой зоны, в том числе записи DS доменов верхнего уровня, таких как .com. Ключ подписи ключей (KSK) подписывает список открытых ключей, опубликованных корнем, — набор записей DNSKEY. Резолвер использует доверенный KSK, чтобы проверить этот список, а затем — ZSK из списка, чтобы проверить остальные записи корневой зоны.

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

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

Новый ключ — KSK-2024, его тег ключа — 38696. Он заменит KSK-2017 с тегом ключа 20326 при подписании набора DNSKEY корневой зоны. Валидирующие резолверы должны начать доверять новому ключу до переключения.

Как резолверы получают новый корневой ключ

RFC 5011 позволяет резолверам автоматически получать новый доверенный якорь корневой зоны. Корень публикует новый KSK в наборе DNSKEY наряду с существующим. Существующий KSK продолжает подписывать этот набор, поэтому резолвер может использовать уже доверенный ключ, чтобы проверить записи с заменяющим ключом.

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

В ходе этой ротации KSK-2024 опубликован в наборе DNSKEY корневой зоны с 11 января 2025 года. У резолверов с автоматическим обновлением доверенных якорей было время обнаружить и принять его до запланированной смены ключа подписи 11 октября 2026 года. Период ожидания для каждого резолвера начинается, когда он впервые обнаруживает и проверяет новый ключ.

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

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

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

На этот раз можно спросить резолвер

RFC 8509 описывает маркер доверенного якоря корневого ключа — способ узнать у поддерживающего его резолвера, доверяет ли он определённому корневому ключу. Для этого используются обычные DNS-запросы к доменам со специальными именами.

Наш сайт для проверки готовности использует этот протокол, чтобы проверить наличие доверия к KSK-2024. Два имени задают противоположные вопросы: is-ta-38696 проверяет, доверяет ли резолвер ключу, а not-ta-38696 — не доверяет ли он ему.

Для обоих имён существуют действительные записи адресов, подписанные DNSSEC. Резолвер с поддержкой маркера сначала проверяет эти записи, а затем либо возвращает ответ без изменений, либо подменяет его на SERVFAIL — в зависимости от того, доверяет ли он ключу.

Для валидирующего резолвера с поддержкой маркера ожидаются следующие результаты:

Для валидирующего резолвера с поддержкой маркера при доверии к KSK-2024 ожидается SERVFAIL для not-ta-38696. Запрос «не доверяет» резолвер намеренно отклоняет.

Метки маркера, такие как root-key-sentinel-is-ta-38696, можно использовать в любом домене с подписью DNSSEC. Для наших тестов мы используем dnstest.dev. Вы можете выполнить оба запроса напрямую к 1.1.1.1:

$ dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer

; <<>> DiG 9.10.6 <<>> @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44476
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; ANSWER SECTION:
root-key-sentinel-is-ta-38696.dnstest.dev. 300 IN A 104.18.6.197
root-key-sentinel-is-ta-38696.dnstest.dev. 300 IN A 104.18.7.197

$ dig @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer

; <<>> DiG 9.10.6 <<>> @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3285
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232

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

Тест в браузере проверяет резолвер, которым пользуется ваш браузер; на результат могут влиять Secure DNS или VPN. Приведённые выше команды dig напрямую отправляют запросы к 1.1.1.1. Оба способа позволяют получить снимок состояния резолвера, отвечающего на эти запросы.

Новый ключ, тот же алгоритм

В KSK-2017 и KSK-2024 используется RSA/SHA-256. При ротации меняется пара ключей, но метод создания и проверки подписей остаётся прежним.

В публикации 2018 года мы писали, что успешная ротация позволит начать обсуждение смены алгоритма. Восемь лет спустя корневая зона по-прежнему использует RSA.

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

Управление по присвоению номеров в Интернете (IANA) планирует проводить ротацию в идеале каждые три года, чтобы соблюдать баланс между регулярной практикой и затратами и рисками слишком частой смены корневого ключа. Перерыв с 2018 года оказался длиннее. Корпорация по управлению доменными именами и IP-адресами (ICANN) объясняет задержку сбоями, вызванными пандемией, и модернизацией оборудования, которое защищает закрытые ключи подписи.

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

Что будет после октября

Переключение 11 октября изменит KSK, которым подписывается набор DNSKEY корневой зоны. Ротация продолжится в 2027 году: ICANN планирует отозвать KSK-2017, удалить его из корневой зоны и уничтожить его закрытый ключ. Прекращение подписания ключом и отзыв доверия к нему — это отдельные этапы.

Кроме того, ICANN предложила в будущем перевести корневую зону на алгоритм ECDSA P-256. ECDSA создаёт ключи и подписи меньшего размера, чем используемый сейчас алгоритм RSA. Это предложение не связано с октябрьской заменой ключа, а ECDSA не является постквантовым алгоритмом.

1.1.1.1 теперь проверяет подписи ML-DSA-44, разработанные с расчётом на устойчивость к атакам с использованием квантовых компьютеров. Чтобы вся цепочка доверия DNSSEC стала постквантово защищённой, постквантовую криптографию должны внедрить также подписанные домены, их родительские зоны и корневая зона. Для корня это означает внедрение постквантового KSK и получение доверия к нему со стороны резолверов.

Для этого потребуется ещё одна ротация корневого ключа. Нынешние ротации позволяют операторам отработать распространение заменяющих доверенных якорей, проверить, приняли ли их резолверы, и вывести старые ключи из эксплуатации. Октябрьская ротация сохранит RSA, но позволит проверить обновление доверенных якорей, которое понадобится при переходе корневой зоны на постквантовую криптографию. Маркер даёт возможность узнать, применили ли резолверы эти обновления.

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

Пока ближайший крайний срок — 11 октября. Проверить готовность резолвера можно на сайте https://dnstest.dev/ksk-2024. Если вы управляете DNSSEC-валидирующим резолвером, убедитесь, что он доверяет KSK-2024 с тегом ключа 38696. Если ключ отсутствует, следуйте рекомендациям ICANN и инструкциям поставщика программного обеспечения.

© Cloudflare Blog