DNSSEC ロールオーバー失敗で .AL ドメインが停止、Cloudflare は検証バイパスを検知して通知

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 データを常時追跡できます。