DNSSEC ロールオーバー失敗で .AL ドメインが停止、Cloudflare は検証バイパスを検知して通知
Cloudflare は、アルバニアの .AL ドメインにおける DNSSEC キーローリング失敗によるサービス停止を教訓に、検証バイパス時に拡張 DNS エラー（EDE）コードを返す新機能を導入し、セキュリティと可用性のバランスを改善した。
キーポイント
.AL ドメインにおける DNSSEC 障害の実態
2026 年 7 月 3 日、アルバニア通信当局（AKEP）によるキーローリングの失敗により、.AL ドメイン全体の DNSSEC 検証が破綻し、Cloudflare の 1.1.1.1 など検証レスォルバを使用するユーザーがサービスにアクセスできなくなった。
NTA 導入と透明性の欠如
Cloudflare は .DE ドメインの事例と同様に、一時的に Negative Trust Anchor (NTA) を設定して復旧を図ったが、これによりユーザーは DNSSEC 検証がバイパスされていることに気づかず、偽装攻撃との区別ができなくなるリスクがあった。
拡張 DNS エラー（EDE）による可視化
今回の .AL 件を契機に、Cloudflare は NTA 適用時に新しい EDE コードを返す機能を導入し、検証がバイパスされていることをクライアント側に明示的に通知する仕組みを実現した。
.AL ドメインの DNSSEC ロールオーバー失敗とダウンタイム
キーローテーション中に古い DNSKEY が削除され、ルートゾーンの DS レコードとの整合性が失われたことで検証に失敗し、TLD 全体が利用不能になりました。
ネガティブトラストアンカー（NTA）による復旧
運営者への連絡が取れなかったため、Cloudflare は RFC 7646 に基づく NTA を設定して .AL の検証をバイパスし、1.1.1.1 ユーザーに対して約3時間で復旧措置を講じました。
現在もドメインは署名なしの状態
DS レコードがルートゾーンから削除された結果、サービスは復旧しましたが、現在は .AL 全体が DNSSEC 保護のない未署名状態のままとなっています。
NTA のリスクと透明性の欠如
Negative Trust Anchor (NTA) はドメインの到達可能性を維持するが、DNSSEC 検証を一時的に無効化し、ユーザーは暗号化された保証のない応答を受け取る。従来の仕組みでは、この状態が起きたことをクライアント側で検知する方法が存在せず、応答自体には何のシグナルも含まれていなかった。
重要な引用
A client receiving a response served under an NTA has no way to tell, from the response alone, that DNSSEC validation was bypassed
For the .AL incident, 1.1.1.1 addressed that gap for the first time, returning a new Extended DNS Error (EDE) code alongside every affected response
Having a broken DNSSEC configuration can be painful, especially when it impacts an entire TLD at once.
We received no response, in part because the operator's contact addresses were themselves under .AL, making them unreachable during the outage.
"Installing a Negative Trust Anchor is an aggressive measure. We suspend DNSSEC validation to keep domains reachable, accepting that responses are no longer cryptographically verified for the duration."
"Up until now, nothing in the DNS response signalled this to the client; a response served under an NTA looked identical to a fully validated one."
影響分析・編集コメントを表示
影響分析
このニュースは、ネットワークインフラのセキュリティプロトコルである DNSSEC の運用リスクと、その可視化の重要性を浮き彫りにしています。Cloudflare が実装した EDE コードによる通知機能は、単なる復旧措置を超え、将来同様の障害が発生した際に管理者やユーザーが即座に状況を把握し、適切な対応（例：セキュリティ監査の実施）を取るための重要な標準化された手段となります。
編集コメント
セキュリティと可用性のトレードオフをどう解決するかが問われる事例であり、運用上の失敗を可視化する仕組みの重要性が再認識される重要な記事です。
2026 年 7 月 3 日、アルバニアの通信当局（AKEP）は、同国の国別コードトップレベルドメイン（TLD）である .AL の DNSSEC キーローリングを試みました。しかし何らかの原因で失敗し、DNSSEC 検証エラーが発生しました。
DNSSEC 仕様に従えば、署名を検証するすべての DNS リゾルバーはこれらの署名を拒否し、クライアントにエラーを返す必要があります。Cloudflare が運営するパブリック DNS リゾルバー「1.1.1.1」も例外ではありませんでした。
.AL ドメインはアルバニアの政府サービス、銀行、メディアのオンライン拠点であり、Cloudflare Radar の TLD ランキングでは 191 位にランクされています。検証機能を持つリゾルバーを使用しているユーザーは、このインシデント発生中にこれらのサイトにアクセスできなくなりました。
この障害は、ホスト先や権威ネームサーバーがどこであっても、.AL ドメイン全体に影響を及ぼす可能性がありました。
ちょうど 2 ヶ月前にもドイツの TLD である .DE で同様のインシデントが発生しています。当時のブログ記事で私たちが説明した通り、対応策として .DE に対して「ネガティブ・トラスト・アンカー（NTA）」を設定し、レジストリが問題を解決するまでの間、1.1.1.1 での DNSSEC 検証を一時的に停止してドメインの到達性を確保しました。.AL の件でも同じ対応を行いました。
NTA（No-Trust Anchor）は解決を復元しますが、その過程は静かに行われます。NTA によって提供された応答を受け取ったクライアントは、応答単体からは DNSSEC の検証がバイパスされたことを知る術がありません。そのため、正当な回答と偽装された回答を見分けることができません。
今回の .AL インシデントにおいて、1.1.1.1 はこの欠陥を初めて解消しました。影響を受けたすべての応答に、新しい拡張 DNS エラー（EDE）コードを付与し、「NTA の存在により DNSSEC 検証が行われていない」ことを示すようにしたのです。
下のグラフは、7 月 3 日一日を通じて 1.1.1.1 で処理された .AL 関連クエリの SERVFAIL レートと NOERROR レートの推移を示しています。キャッシュされたレコードが期限切れになると解決を再検証する必要が生じるため、SERVFAIL の割合は上昇します。一方、UTC 時間 17:15 に NTA が適用されると、解決が復元されるため、SERVFAIL レートは急激に低下します。
.AL で何が起こったのか
DNSSEC の仕組みについては、以前のブログ記事でより詳しく解説しました。ここでは簡単に復習しておきましょう。
DNSSEC は、ルートゾーンから個別のドメイン名まで続く「信頼の連鎖」を構築します。ルートゾーンには、署名済み TLD ごとに DS（Delegation Signer）レコードが保持されており、これはその TLD の DNSKEY の指紋情報です。.AL の検証を行うリゾルバは、.AL のネームサーバーから提供される DNSKEY が、ルートにある DS レコードと一致しているかを確認します。もし一致すれば、リゾルバは .AL のネームサーバーからの DNS 応答が真正なものと信頼します。
このパターンは一つ下のレベルでも繰り返されます。.AL は、署名済みの子ドメインごとに DS レコードを保持しており、それぞれに対応する DNSKEY が存在します。この連鎖のどこかで破綻が生じると（例えば、DS レコードが存在しない古いキーを指している場合など）、その下位にあるすべてのドメインで検証が失敗します。
今回のインシデント発生前、ルートゾーンには .AL のネームサーバーが提供していた DNSKEY と一致する DS レコードが存在していました。これは以下の図の通りです。
UTC 時刻 14:15 頃、.AL の運用担当者は新しい DNSKEY を公開し、古いキーの提供を停止しました。しかし、ルートゾーンにある DS レコードは依然として古い DNSKEY（ID=26319）を指したままだったため、.AL の応答を検証しようとするリゾルバはどこも一致するキーを見つけられず、検証に失敗しました。
UTC 17 時頃、.AL の運用担当者は新しい DNSKEY を削除しましたが、古い方の復元には失敗しました。その結果、ゾーン内から DNSKEY レコードが完全に消え去り、ルートサーバー側では依然として DS レコードが id=26319 を指し続ける状態となりました。この不整合により、ドメイン名の解決は継続して失敗し続けました。
UTC 19 時 15 分頃、.AL の運用担当者はルートゾーンから DS レコードの削除を行いました。DS レコードが存在しなくなったことで、リゾルバは .AL に対する DNSSEC 検証を不再要とみなすようになりました。その結果、ドメイン名の解決は復旧しましたが、この時点で .AL というトップレベルドメイン全体が署名なし（unsigned）の状態に陥ってしまいました。
記事公開時点でも、.AL は依然として署名なしの状態が続いています。運用担当者がルートゾーンに DS レコードを復元していないからです。DS レコードがない限り、.AL 内のすべてのドメインは DNSSEC の保護機能を利用できなくなります。
ネガティブ・トラスト・アンカーが用いられる理由
DNSSEC の設定に不具合が生じると、特に全 TLD（トップレベルドメイン）に同時に影響が及ぶ場合、対応は非常に困難になります。先ほどの .DE 事例のブログでも触れた通り、再帰 DNS オペレーターは RFC 7646 で定義されている「ネガティブ・トラスト・アンカー（NTA）」を設定できます。これにより、リゾルバーは特定のゾーンを署名なしとみなし、検証プロセスをバイパスして処理を進めるようになります。
NTA を設定する前に、私たちは .AL の運営者に直接連絡を試み、DNS-OARC の Mattermost でコミュニティへ警告を発しました。しかし、運営者からの反応はありませんでした。その一因として、運営者の連絡先アドレス自体が .AL ドメイン内にあり、障害発生時にそれらへのアクセスも不可能になっていたことが挙げられます。
私たちは .AL に対して NTA を適用し、チェーンが切断されてから約 3 時間後の UTC 17:15 までに、すべての 1.1.1.1 ユーザーへ展開を完了しました。
この判断のトレードオフは .DE の場合と同じです。ネガティブ・トラスト・アンカーを設定すると DNSSEC 検証が一時停止するため、その間 .AL ドメインは DNS スプーフィング攻撃に対する保護を受けられなくなります。しかし、今回の障害は公に知られており、確認済みであり、すべての検証リゾルバーに均等に被害が及んでいたという点から、このリスクは許容できると判断しました。
翌日、.AL の運営者がルートゾーンからの DS レコードを削除したことで、NTA は解除されました。DS レコードが存在しなくなったため、リゾルバーは .AL に対して DNSSEC を期待しなくなり、もはや NTA が必要ではなくなりました。
ネガティブ・トラスト・アンカーが抱える問題
ネガティブ・トラストアンカー（NTA）の導入は、非常に積極的な措置です。ドメインへの到達性を維持するために DNSSEC 検証を一時停止し、その間、応答が暗号学的に検証されていないことを受け入れます。ユーザーは SERVFAIL エラーではなく回答を得られますが、その回答には DNSSEC の保証はありません。
これをさらに難しくしているのが、これまで DNS 応答自体に、この状態であることをクライアントに示す仕組みが存在しなかった点です。NTA 下で提供された応答は、完全に検証済みの応答と見分けがつきませんでした。RFC 7646 はこの欠陥を認識しており、運用者がどの NTA を導入しているかを公的に開示するよう推奨していますが、その開示は DNS 応答とは別の手段（アウトオブバンド）で行う必要があります。.DE や .AL の事例ではステータスページを公開しましたが、ユーザーが自ら確認に行く必要があるため、不十分です。1.1.1.1 にクエリを送るアプリケーションや監視ツール、あるいはユーザー自身にとって、応答だけを見ても DNSSEC 検証がバイパスされているかどうかを知る術はありませんでした。
ネガティブ・トラストアンカーの透明性向上
RFC 8914 で定義された拡張 DNS エラー（Extended DNS Error: EDE）コードを使えば、エラーでも成功した回答でも、DNS 応答に追加の文脈情報を付与できます。Quad9 の Babak Farrokhi 氏が提案したインターネットドラフト「Disclosure of Negative Trust Anchors in DNS Responses」では、新しい EDE コードを用いて、ネガティブ・トラストアンカーが存在することを DNS 応答内で直接シグナルする仕組みを提唱しました。私たちは共同執筆者として参加し、1.1.1.1 ではすでにこの機能を実装しています。
.AL のインシデント発生時、.AL ドメインへのクエリはすべて、ネガティブ・トラスト・アンカー（NTA）が設定された状態で、回答結果と新しい EDE コードの両方を返しました。実際の様子はこの通りです。
$ 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 は確かに解決されましたが、そこには 2 つの EDE コードが付随しています。
EDE 9（DNSKEY Missing）は、根本的な DNSSEC の失敗を浮き彫りにします。信頼チェーンが分断され、検証に失敗したことを示しています。一方、EDE 33（Negative Trust Anchor）は、1.1.1.1 がネガティブ・トラスト・アンカーを適用して、本来なら拒否すべきところをあえて回答を返したことを意味します。
この 2 つのコードが組み合わさることで、クライアントや運用担当者は何が起きたのかを完全に把握できます。回答自体は正しいものですが、DNSSEC の検証は通過していないのです。
1.1.1.1 は、NTA（Not Trusted for Anchors）が有効な間に生成された応答であれば、クエリ自体が DNSSEC 検証に失敗するかどうかに関わらず、常に EDE 33 を返します。DNSSEC を全く使用していないドメインへの問い合わせであっても、それが有効な NTA の対象範囲に含まれていれば、結果には EDE 33 が付与されます。これは意図的な仕様です。NTA はゾーン全体をカバーするため、その下で提供されるすべての応答に対して透明性を保つ必要があります。
また、これは以前 .DE ブログで指摘した問題の解決にもつながります。1.1.1.1 は従来、DNSSEC エラーの根本原因を示す代わりに、誤って EDE 22（No Reachable Authority）を返していました。しかし、.AL のインシデント時には、1.1.1.1 は正しく EDE 9（DNSKEY Missing）と EDE 33 を併せて返しています。
このインターネットドラフトは個人による提出であり、EDE 33 というコードはインターネット番号管理機関（IANA）によって割り当てられました。共同執筆者である Quad9 の Babak Farrokhi 氏のおかげで、Knot プロジェクトの kdig ツールが EDE 33 を名称として認識できるようになりました。また、Unbound 向けのプルリクエストも審査中です。他の解決実装でも同様の対応が進むことを願っています。
インターネットドラフトはすでに IETF（Internet Engineering Task Force）の DNSOP ワーキンググループに提出されており、7 月 18 日から 24 日にウィーンで開催される IETF 会議で議論されます。
課題の解消
TLD レベルの DNSSEC 障害は稀ですが、発生するとその TLD に属するすべてのドメインと、検証を行うすべてのリゾルバーが同時に影響を受けます。.DE の事例に続く .AL の件は、「ネガティブ・トラスト・アンカー（Negative Trust Anchor）」が運用上の必須ツールであることを示しましたが、これまでこの機能は、実際に影響を受けるユーザーには見えていませんでした。
EDE 33 は RFC 7646 が残した隙間を埋めるものです。ネガティブ・トラスト・アンカーの下で提供される応答に、その旨が直接明記されるようになりました。これにより、運用者や監視ツール、そしてユーザーは、リゾルバーが何を行い、なぜそう判断したのかを理解するために必要な情報を得ることができます。
インターネットドラフトは IETF datatracker で公開されています。ご意見がある場合は、IETF DNSOP メーリングリストで共有してください。
DNSSEC の仕組みについてさらに詳しく知りたい方は、「How does DNSSEC work?」のページをご覧ください。また、Cloudflare Radar では DNS のリアルタイム動向や TLD データを常時追跡できます。
原文を表示
On July 3, 2026, the Albanian communications authority (AKEP), the operator of the .AL country-code top-level domain (TLD) of Albania, attempted a DNSSEC key rollover. Something went wrong, resulting in DNSSEC validation failures. Any validating DNS resolver receiving these signatures was required by the DNSSEC specification to reject them and return errors to clients. That includes 1.1.1.1, the public DNS resolver operated by Cloudflare.
The .AL TLD is the online home of Albanian government services, banks, and media; it ranks #191 on Cloudflare Radar's TLD ranking. Anyone trying to visit those sites, using a validating resolver, found them unreachable during the incident. The failure had the potential to affect every .AL domain, regardless of where it was hosted or which authoritative nameservers served it.
Just two months earlier, a similar incident struck .DE, the TLD of Germany. As we described in our blog post on the incident, our response was to install a Negative Trust Anchor (NTA) for .DE, temporarily suspending DNSSEC validation in 1.1.1.1 to keep domains reachable while the registry resolved the issue. We did the same for .AL.
NTAs restore resolution, but silently. A client receiving a response served under an NTA has no way to tell, from the response alone, that DNSSEC validation was bypassed, leaving it unable to distinguish a legitimate answer from a spoofed one. For the .AL incident, 1.1.1.1 addressed that gap for the first time, returning a new Extended DNS Error (EDE) code alongside every affected response to signal that the answer was not DNSSEC-validated due to the presence of an NTA.
The graph below shows the SERVFAIL and NOERROR rates for .AL queries on 1.1.1.1 throughout July 3. The SERVFAIL rate climbs as cached records expire and resolvers are forced to revalidate. It drops sharply when the NTA is applied at 17:15 UTC, restoring resolution.
image
What happened to .AL
We discussed how DNSSEC works in more detail in our prior blog post. A brief recap:
DNSSEC builds a chain of trust from the root zone down to individual domain names. The root zone holds a Delegation Signer (DS) record for each signed TLD, a fingerprint of that TLD's DNSKEY. A resolver verifying .AL checks that the DNSKEY served by .AL's nameservers matches the DS record in the root. If it does, the resolver trusts that DNS responses from .AL's nameservers are authentic. The same pattern repeats one level down: .AL holds DS records for its signed child zones, each with a matching DNSKEY. A break anywhere in that chain, such as a DS record pointing to a key that no longer exists, causes validation to fail for everything below it.
Before the incident, the root zone held a DS record matching the DNSKEY served by the .AL nameservers, as illustrated below.
image
At around 14:15 UTC, the .AL operator published a new DNSKEY and stopped serving the old one. The DS record in the root zone still pointed to the old DNSKEY (id=26319), so any resolver attempting to validate .AL responses found no matching key and failed.
image
At roughly 17:00 UTC, the .AL operator removed the new DNSKEY without restoring the old one. The zone now had no DNSKEY records at all, while the DS record in the root still pointed to id=26319, and resolution continued to fail.
image
At roughly 19:15 UTC, the .AL operator removed the DS record from the root zone. Without a DS record, resolvers no longer expected DNSSEC validation for .AL, and resolution was restored, though the entire TLD was now unsigned.
image
As of publishing, .AL remains unsigned. The DS record has not been restored to the root zone by the .AL operators. Without a DS record, every .AL domain is unable to use DNSSEC protections.
Why Negative Trust Anchors are used
Having a broken DNSSEC configuration can be painful, especially when it impacts an entire TLD at once. As we covered in our .DE incident blog, recursive DNS operators can install a Negative Trust Anchor (NTA) as defined in RFC 7646, which tells a resolver to treat a zone as unsigned and bypass validation.
Before installing the NTA, we attempted to reach the .AL operator directly and posted on the DNS-OARC Mattermost to alert the community. We received no response, in part because the operator's contact addresses were themselves under .AL, making them unreachable during the outage.
We applied the NTA for .AL and rolled it out to all 1.1.1.1 users by 17:15 UTC, roughly three hours after the chain broke.
The tradeoff is the same as it was for .DE: a Negative Trust Anchor suspends DNSSEC validation, which means .AL domains were no longer protected against DNS spoofing for the duration. We judged this acceptable for the same reason: the failure was public, confirmed, and affecting every validating resolver equally.
The Negative Trust Anchor was removed the following day, once the .AL operator had removed the DS record from the root zone. With no DS record present, resolvers no longer expected DNSSEC for .AL and the NTA was no longer needed.
The problem with Negative Trust Anchors
Installing a Negative Trust Anchor is an aggressive measure. We suspend DNSSEC validation to keep domains reachable, accepting that responses are no longer cryptographically verified for the duration. Users get answers instead of SERVFAIL, but those answers carry no DNSSEC guarantee.
What makes this harder is that, up until now, nothing in the DNS response signalled this to the client; a response served under an NTA looked identical to a fully validated one. RFC 7646 acknowledges this gap and recommends that operators publicly disclose which NTAs they have in place, but that disclosure is out-of-band. For both the .DE and .AL incidents we published status pages, but a status page requires the user to go looking. An application, a monitoring tool, or a user querying 1.1.1.1 had no way to tell, from the response alone, that DNSSEC validation was bypassed.
Bringing transparency to Negative Trust Anchors
Extended DNS Error (EDE) codes, defined in RFC 8914, allow resolvers to include additional context alongside any DNS response, whether that is an error or a successful answer. Babak Farrokhi at Quad9 proposed an Internet-Draft to signal the presence of a Negative Trust Anchor directly in the DNS response, using a new EDE code: Disclosure of Negative Trust Anchors in DNS Responses. We joined as co-authors, and 1.1.1.1 now implements it.
During the .AL incident, any query for a .AL name returned both the answer and the new EDE code while the Negative Trust Anchor was installed. Here is what that looked like:
$ 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
The response is a NOERROR with a valid answer: google.al resolves, but two EDE codes accompany it. EDE 9 (DNSKEY Missing) surfaces the underlying DNSSEC failure: the chain of trust was broken and validation failed. EDE 33 (Negative Trust Anchor) signals that 1.1.1.1 applied a Negative Trust Anchor and served the response anyway. Together they give clients and operators full visibility into what happened: the answer is real, but it was not DNSSEC-validated.
1.1.1.1 returns EDE 33 on any response generated while an NTA is active, regardless of whether the query itself would have failed DNSSEC validation. A query for a domain that does not use DNSSEC at all will still carry EDE 33 if it falls under an active NTA. This is intentional: the NTA covers the entire zone, and transparency applies equally to every response served under it.
This also resolves an issue we flagged in our .DE blog, where 1.1.1.1 incorrectly returned EDE 22 (No Reachable Authority) instead of surfacing the underlying DNSSEC error. During the .AL incident, 1.1.1.1 correctly returned EDE 9 (DNSKEY Missing) alongside EDE 33.
The Internet-Draft is an individual submission and EDE 33 has been assigned by the Internet Assigned Numbers Authority (IANA). Thanks to our co-author, Babak Farrokhi at Quad9, the kdig tool from the Knot project now recognizes EDE 33 by name, and a pull request for Unbound is under review. We hope other resolver implementations will follow. The Internet-Draft has been submitted to the Internet Engineering Task Force (IETF) DNSOP Working Group, and will be discussed at the IETF meeting taking place in Vienna from July 18 to July 24.
Closing the gap
TLD-level DNSSEC failures are rare, but when they happen they affect every domain underneath the affected TLD simultaneously, and every validating resolver equally. The .AL incident, following closely behind .DE, shows that Negative Trust Anchors are a necessary operational tool, but one that has, until now, been invisible to the users they affect.
EDE 33 closes a gap that RFC 7646 left open. A response served under a Negative Trust Anchor now says so directly, giving operators, monitoring tools, and users the information they need to understand what the resolver did and why.
The Internet-Draft is available at the IETF datatracker. If you have thoughts on it, the IETF DNSOP mailing list is the right place to share them.
If you want to learn more about how DNSSEC works, visit our page How does DNSSEC work? And you can always follow real-time DNS trends and TLD data on Cloudflare Radar.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み