Сбой DNSSEC обрушил домен .AL: 1.1.1.1 теперь предупреждает об отключении проверки

3 июля 2026 года албанский орган связи (AKEP), оператор национального домена верхнего уровня (TLD) .AL Албании, предпринял попытку ротации ключей DNSSEC. Что-то пошло не так, что привело к сбоям валидации DNSSEC. Любой валидирующий DNS-резолвер, получающий эти подписи, был обязан по спецификации DNSSEC отклонять их и возвращать ошибки клиентам. Это включает 1.1.1.1, публичный DNS-резолвер, эксплуатируемый Cloudflare.

Домен .AL является онлайн-доменом для правительственных служб, банков и СМИ Албании; он занимает #191 в рейтинге TLD Cloudflare Radar. Любой, кто пытался посетить эти сайты, используя валидирующий резолвер, обнаруживал, что они недоступны во время инцидента. Сбой потенциально мог затронуть каждый домен .AL, независимо от того, где он размещён или какие авторитетные серверы имён его обслуживают.

Всего двумя месяцами ранее аналогичный инцидент произошёл с .DE, доменом верхнего уровня Германии. Как мы описали в нашем блог-посте об этом инциденте, нашей реакцией стала установка Negative Trust Anchor (NTA) для .DE, временно приостановив валидацию DNSSEC в 1.1.1.1, чтобы сохранить доступность доменов, пока регистратор решал проблему. Мы сделали то же самое для .AL.

NTA восстанавливают разрешение имён, но незаметно. Клиент, получающий ответ, обслуживаемый под NTA, не может по самому ответу определить, что валидация DNSSEC была обойдена, и не может отличить легитимный ответ от поддельного. В случае инцидента с .AL 1.1.1.1 впервые устранил этот пробел, возвращая новый код Extended DNS Error (EDE) вместе с каждым затронутым ответом, чтобы сигнализировать, что ответ не был проверен DNSSEC из-за наличия NTA.

График ниже показывает частоту ответов SERVFAIL и NOERROR для запросов .AL на 1.1.1.1 в течение 3 июля. Частота SERVFAIL растёт по мере истечения кэшированных записей и вынужденной повторной валидации резолверами. Она резко падает, когда в 17:15 UTC применяется NTA, восстанавливая разрешение имён.

Мы обсуждали, как работает DNSSEC, более подробно в нашем предыдущем блог-посте. Краткое резюме:

DNSSEC строит цепочку доверия от корневой зоны вниз до отдельных доменных имён. Корневая зона содержит запись Delegation Signer (DS) для каждого подписанного TLD, которая представляет собой отпечаток DNSKEY этого TLD. Резолвер, проверяющий .AL, проверяет, что DNSKEY, предоставленный серверами имён .AL, соответствует DS-записи в корне. Если это так, резолвер доверяет, что DNS-ответы от серверов имён .AL являются подлинными. Та же схема повторяется на один уровень ниже: .AL содержит DS-записи для своих подписанных дочерних зон, каждая из которых имеет соответствующий DNSKEY. Разрыв в любом месте этой цепочки, например, DS-запись, указывающая на ключ, который больше не существует, вызывает сбой валидации для всего, что находится ниже.

До инцидента корневая зона содержала DS-запись, соответствующую DNSKEY, предоставляемому серверами имён .AL, как показано ниже.

Примерно в 14:15 UTC оператор .AL опубликовал новый DNSKEY и перестал обслуживать старый. DS-запись в корневой зоне всё ещё указывала на старый DNSKEY (id=26319), поэтому любой резолвер, пытавшийся проверить ответы .AL, не находил соответствующего ключа и терпел неудачу.

Примерно в 17:00 UTC оператор .AL удалил новый DNSKEY, не восстановив старый. Теперь в зоне вообще не было записей DNSKEY, в то время как DS-запись в корне всё ещё указывала на id=26319, и разрешение имён продолжало давать сбой.

Примерно в 19:15 UTC оператор .AL удалил DS-запись из корневой зоны. Без DS-записи резолверы больше не ожидали валидации DNSSEC для .AL, и разрешение имён было восстановлено, хотя весь TLD теперь стал неподписанным.

На момент публикации .AL остаётся неподписанным. DS-запись не была восстановлена в корневой зоне операторами .AL. Без DS-записи каждый домен .AL не может использовать защиту DNSSEC.

Наличие сломанной конфигурации DNSSEC может быть болезненным, особенно когда она затрагивает целый TLD одновременно. Как мы рассказывали в нашем блоге об инциденте с .DE, операторы рекурсивных DNS могут установить Negative Trust Anchor (NTA), как определено в RFC 7646, что указывает резолверу обрабатывать зону как неподписанную и пропустить валидацию.

Перед установкой NTA мы попытались связаться напрямую с оператором .AL и опубликовали сообщение в DNS-OARC Mattermost, чтобы предупредить сообщество. Мы не получили ответа, отчасти потому, что контактные адреса оператора сами находились в домене .AL, что делало их недоступными во время сбоя.

Мы применили NTA для .AL и развернули его для всех пользователей 1.1.1.1 к 17:15 UTC, примерно через три часа после разрыва цепочки.

Компромисс тот же, что и для .DE: Negative Trust Anchor приостанавливает валидацию DNSSEC, что означает, что домены .AL на время перестали быть защищены от подмены DNS. Мы сочли это приемлемым по той же причине: сбой был публичным, подтверждённым и затрагивал одинаково все валидирующие резолверы.

Negative Trust Anchor был удалён на следующий день, после того как оператор .AL удалил DS-запись из корневой зоны. При отсутствии DS-записи резолверы больше не ожидали DNSSEC для .AL, и NTA больше не требовался.

Установка Negative Trust Anchor — это агрессивная мера. Мы приостанавливаем валидацию DNSSEC, чтобы сохранить доступность доменов, принимая тот факт, что ответы больше не проверяются криптографически в течение этого времени. Пользователи получают ответы вместо SERVFAIL, но эти ответы не несут гарантии DNSSEC.

Что делает это ещё сложнее, так это то, что до сих пор ничто в DNS-ответе не сигнализировало об этом клиенту; ответ, обслуживаемый под NTA, выглядел идентично полностью проверенному. RFC 7646 признаёт этот пробел и рекомендует операторам публично раскрывать, какие NTA у них установлены, но это раскрытие происходит внеполосно. Как для инцидента с .DE, так и для .AL мы публиковали страницы статуса, но страница статуса требует, чтобы пользователь сам её искал. Приложение, инструмент мониторинга или пользователь, запрашивающий 1.1.1.1, не могли по самому ответу определить, что валидация DNSSEC была обойдена.

Коды Extended DNS Error (EDE), определённые в RFC 8914, позволяют резолверам включать дополнительный контекст вместе с любым DNS-ответом, будь то ошибка или успешный ответ. Babak Farrokhi из Quad9 предложил Интернет-черновик для сигнализации о наличии Negative Trust Anchor непосредственно в DNS-ответе, используя новый код EDE: Disclosure of Negative Trust Anchors in DNS Responses. Мы присоединились в качестве соавторов, и 1.1.1.1 теперь реализует его.

Во время инцидента с .AL любой запрос имени в домене .AL возвращал как ответ, так и новый код EDE, пока был установлен Negative Trust Anchor. Вот как это выглядело:

$ kdig @1.1.1.1 google.al
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 32848
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; EDE: 9 (DNSKEY Missing): 'no SEP matching the DS found for al.'
;; EDE: 33 (Negative Trust Anchor): 'a Negative Trust Anchor has been applied for this query (see RFC 7646)'

;; ANSWER SECTION:
google.al.              300    IN    A    142.251.142.196

Ответ — NOERROR с действительным ответом: google.al разрешается, но сопровождается двумя кодами EDE. EDE 9 (DNSKEY Missing) раскрывает основную причину сбоя DNSSEC: цепочка доверия была нарушена, и валидация не удалась. EDE 33 (Negative Trust Anchor) сигнализирует, что 1.1.1.1 применил Negative Trust Anchor и всё равно предоставил ответ. Вместе они дают клиентам и операторам полное представление о том, что произошло: ответ настоящий, но не был проверен DNSSEC.

1.1.1.1 возвращает EDE 33 для любого ответа, сгенерированного, пока активен NTA, независимо от того, провалил бы запрос сам по себе валидацию DNSSEC. Запрос домена, который вообще не использует DNSSEC, всё равно будет содержать EDE 33, если он подпадает под активный NTA. Это сделано намеренно: NTA покрывает всю зону, и прозрачность применяется одинаково ко всем ответам, обслуживаемым под ним.

Это также решает проблему, которую мы отметили в нашем блоге о .DE, где 1.1.1.1 ошибочно возвращал EDE 22 (No Reachable Authority) вместо отображения основной ошибки DNSSEC. Во время инцидента с .AL 1.1.1.1 корректно возвращал EDE 9 (DNSKEY Missing) вместе с EDE 33.

Интернет-черновик является индивидуальной заявкой, и EDE 33 был назначен Управлением по присвоению номеров в Интернете (IANA). Благодаря нашему соавтору Бабаку Фаррохи из Quad9, инструмент kdig из проекта Knot теперь распознает EDE 33 по имени, и запрос на включение для Unbound находится на рассмотрении. Мы надеемся, что другие реализации резолверов последуют этому примеру. Интернет-черновик был представлен Рабочей группе DNSOP Инженерного совета Интернета (IETF) и будет обсуждаться на встрече IETF, которая пройдет в Вене с 18 по 24 июля.

Сбои DNSSEC на уровне TLD редки, но когда они происходят, они затрагивают каждый домен в соответствующем TLD одновременно и каждый проверяющий резолвер в равной степени. Инцидент с .AL, последовавший вскоре за .DE, показывает, что Negative Trust Anchors (отрицательные якоря доверия) являются необходимым операционным инструментом, но до сих пор они были невидимы для пользователей, которых затрагивают.

EDE 33 закрывает пробел, который RFC 7646 оставил открытым. Ответ, предоставленный под Negative Trust Anchor, теперь прямо говорит об этом, предоставляя операторам, инструментам мониторинга и пользователям информацию, необходимую для понимания того, что сделал резолвер и почему.

Интернет-черновик доступен в трекере IETF. Если у вас есть мысли по этому поводу, список рассылки IETF DNSOP — правильное место для их обсуждения.