Как мы спасали .de домены: разбор масштабного сбоя DNSSEC и наши действия

5 мая 2026 года примерно в 19:30 UTC компания DENIC, оператор реестра национального домена верхнего уровня (ccTLD) .de, начала публиковать неверные подписи DNSSEC для зоны .de. Любой проверяющий DNS-резолвер, получающий эти подписи, в соответствии со спецификацией DNSSEC должен был отклонить их и вернуть клиентам ответ SERVFAIL, включая 1.1.1.1, общедоступный DNS-резолвер, управляемый Cloudflare.

Национальный домен верхнего уровня Германии .de является одним из крупнейших в интернете. На Cloudflare Radar он стабильно входит в число наиболее запрашиваемых TLD в мире. Сбой на этом уровне иерархии DNS может сделать миллионы доменов недоступными.

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

DNSSEC (расширения безопасности системы доменных имен) добавляет криптографическую аутентификацию в DNS. Когда зона подписана с помощью DNSSEC, каждый набор записей сопровождается цифровой подписью, известной как запись RRSIG, которая позволяет резолверу проверить, что записи не были изменены. В отличие от зашифрованных DNS-протоколов, таких как DNS over TLS (DoT) и DNS over HTTPs (DoH), DNSSEC обеспечивает целостность, а не конфиденциальность. Записи видны, но их подлинность может быть доказана.

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

DNSSEC построен на цепочке доверия. Начиная с корневой зоны, чей якорь доверия жестко запрограммирован в резолверах, каждая зона делегирует доверие дочерним зонам через записи Delegation Signer (DS). Запись DS в родительской зоне содержит криптографический хэш открытого ключа в дочерней зоне. Когда резолвер проверяет example.de, он проверяет цепочку: корень доверяет .de, .de доверяет example.de. Разрыв в любом месте этой цепочки приводит к сбою проверки для всего, что находится ниже, поэтому неправильная конфигурация на уровне TLD, такого как .de, влияет на каждый домен под ним.

Зоны обычно используют два типа ключей: ключ подписи зоны (ZSK), используемый для подписи записей зоны, и ключ подписи ключа (KSK), используемый для подписи самого ZSK. Открытый ключ KSK — это то, на что указывает запись DS родительской зоны, закрепляя цепочку доверия. Ротация ZSK относительно проста: сгенерировать новый ключ, переподписать записи зоны и дождаться истечения срока действия кэша. Ротация KSK более сложна, поскольку запись DS родительской зоны также должна быть обновлена, что часто требует координации с регистратором или реестром.

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

5 мая 2026 года примерно в 19:30 UTC компания DENIC, оператор TLD .de, начала публиковать неверные подписи DNSSEC для зоны .de. Любой проверяющий резолвер, получающий эти записи, в соответствии со спецификацией DNSSEC должен был отклонить их и вернуть SERVFAIL. 1.1.1.1 не был исключением.

На графике ниже показаны коды ответов, которые 1.1.1.1 возвращал на запросы .de во время инцидента.

После первоначального всплеска SERVFAIL в 19:30 UTC он неуклонно рос в течение следующих трех часов, поскольку кэшированные записи начали постепенно истекать. Когда кэшированные записи каждого домена истекали и резолверы обращались к DENIC за свежими копиями, они получали поврежденные подписи и начинали выдавать ошибки.

Что может удивить, так это то, что уровень NOERROR оставался относительно стабильным на протяжении всего инцидента. Это работает механизм «serve stale», который мы рассмотрим в следующем разделе.

Рекурсивные резолверы кэшируют записи, полученные от авторитетных серверов имен, на время жизни каждой записи (TTL). Пока запись кэширована, резолвер обслуживает ее напрямую, не обращаясь к авторитетному серверу имен. Когда TTL истекает, резолвер получает свежую копию и повторно кэширует ее.

Во время сбоя свежезапрошенные записи в конечном итоге разрешались в SERVFAIL. Подписи DNSSEC были повреждены, и резолвер корректно отклонял их. Но многие записи .de все еще находились в кэше с момента до начала инцидента. Вместо того чтобы немедленно отбрасывать их и возвращать пользователям SERVFAIL, 1.1.1.1 продолжал обслуживать их после истечения TTL. Это называется «обслуживание устаревших записей» (serving stale).

1.1.1.1 реализует RFC 8767, который формализует это поведение. Когда вышестоящее разрешение не удается, резолвер может продолжать обслуживать устаревшие кэшированные записи вместо возврата ошибки. Это значительно смягчает последствия сбоя вышестоящего сервера, давая операторам время на реагирование.

Результат виден на графике ниже, который показывает коды ответов для запросов .de во время инцидента, исключая ответы, обслуженные из устаревшего кэша. Без учета устаревших ответов уровень NOERROR неуклонно снижается с 19:30. Это запросы, на которые пользователи получили хорошие ответы только потому, что их запись все еще была в кэше.

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

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

NTA существуют именно для таких типов инцидентов. Когда оператор TLD публикует поврежденные подписи, каждый проверяющий DNSSEC резолвер вынужден возвращать SERVFAIL для каждого домена в этом TLD. Не из-за каких-либо проблем с самими доменами, а из-за неправильной конфигурации их родительской зоны. Продолжение возврата SERVFAIL в такой ситуации не дает никакой пользы для безопасности: сбой уже известен, публичен и устраняется. RFC 7646 явно называет неправильную конфигурацию TLD основным случаем использования NTA.

Для 1.1.1.1 у нас есть собственный резолвер, называемый Big Pineapple, который также обеспечивает работу 1.1.1.1 для Families, Gateway DNS, DNS Firewall и других сервисов. На данный момент мы не реализовали собственный механизм NTA. Вместо этого мы использовали существующий механизм правил переопределения, чтобы пометить .de как небезопасную зону, что приводит к разрешению всех запросов .de так, как если бы DNSSEC не был включен. Это функционально эквивалентно NTA, хотя формально не определено ни в одном RFC.

Решение обойти DNSSEC является осознанным компромиссом. Без проверки DNSSEC домены .de становятся уязвимыми для реальных атак на время инцидента. Во время подобных инцидентов мы сочли это приемлемым, поскольку сбой подписи был широко распространен, публично подтвержден и в равной степени затрагивал все проверяющие резолверы в интернете. Как было сказано в нашей комнате реагирования на инциденты: «Ни один пользователь 1.1.1.1, который сейчас разрешает имя .de, не предпочтет SERVFAIL непроверенному ответу».

Мы развернули наши меры в 22:17 UTC, что ознаменовало конец влияния на 1.1.1.1. Мы сообщили об этом коллегам-операторам DNS в DNS-OARC Mattermost.

Хотя все пользователи Интернета могут обращаться к нашему резолверу 1.1.1.1, у нас есть особая ответственность перед клиентами, использующими услуги нашей платформы CDN. Те из них, у кого исходные имена содержали .de, также пострадали от этого сбоя.

Cloudflare управляет отдельным внутренним резолвером для разрешения источников, отличным от нашего общедоступного сервиса 1.1.1.1. Чтобы уменьшить последствия, мы применили аналогичный NTA для .de во внутреннем резолвере, восстановив связь с источниками для пострадавших клиентов.

До наших мер смягчения запросы, которые не могли быть обслужены из кэша, получали ответ SERVFAIL от 1.1.1.1. Каждый SERVFAIL включал код расширенной DNS-ошибки (EDE), определённый в RFC 8914, который предоставляет клиентам больше деталей о том, что пошло не так.

Некоторые резолверы возвращали EDE 6 (DNSSEC Bogus) с описательным сообщением, прямо указывающим на повреждённую подпись. Это корректное поведение:

EDE: 6 (DNSSEC Bogus): RRSIG with malformed signature found for example.de/nsec3 (keytag=33834)

С другой стороны, 1.1.1.1 возвращал EDE 22 (No Reachable Authority), что на первый взгляд указывает на проблему связи с вышестоящими серверами имён, а не на ошибку валидации DNSSEC.

Причина — ошибка в том, как мы передаём коды EDE DNSSEC вверх от нашего верификатора цепочки доверия. Когда верификатор обнаруживает поддельную подпись, он создаёт код EDE DNSSEC Bogus, но он никогда не вставляется в ответ. Вместо этого внешний слой резолвера видит проблему с рекурсивным разрешением без кода ошибки и возвращается к сообщению "No Reachable Authority". Это скрывает основную причину DNSSEC.

Мы понимаем, что это не полезно для пользователей 1.1.1.1, и исправим наши ответы, чтобы отображать ошибки DNSSEC.

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

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

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

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

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

Этот инцидент подчёркивает структурную реальность иерархии DNS: когда реестр на уровне TLD выходит из строя, все домены под этим TLD оказываются затронуты одновременно, независимо от того, где они размещены и какой резолвер используется. Это не уникально для DNSSEC; то же самое происходит, если серверы имён TLD становятся недоступными. Иерархия, обеспечивающая работу глобального DNS, также приводит к тому, что сбои на верхнем уровне распространяются вниз.

Простого исправления здесь нет. Что может сделать индустрия — это быстро и последовательно реагировать, когда такое происходит. В этом инциденте операторы резолверов по всему Интернету независимо применили Negative Trust Anchors в течение часа, восстановив разрешение, пока DENIC работала над исправлением зоны. Операционные практики, отраслевые каналы связи, такие как DNS-OARC, и функции, такие как serve stale, снижают последствия, даже если они не могут полностью устранить базовую зависимость.

Мы также вынесли для себя несколько моментов для улучшения. Мы будем работать над нашими ошибками EDE, чтобы лучше отображать ошибки DNSSEC.

Мы с нетерпением ждём отчёта DENIC после инцидента и ценим прозрачность, которую они проявили на протяжении всего процесса.