はじめに：DNSSEC障害はなぜ特に深刻なのか
DNSSECはDNS応答の完全性を保証するために不可欠なセキュリティプロトコルです。しかし、このプロトコルには「単一障害点（Single Point of Failure）」という重大な弱点があります。ルートゾーンから始まる信頼の連鎖（Chain of Trust）の一部が途切れるだけで、該当TLD配下のすべてのドメインが同時に機能不全に陥る可能性があります。
2026年7月3日、アルバニアの国別トップレベルドメイン.alでDNSSECキーロールオーバーが失敗し、この最悪のシナリオが現実のものとなりました。政府サービス、銀行、メディアなどアルバニアのオンラインインフラの大部分が影響を受け、CloudflareのパブリックDNSリゾルバである1.1.1.1のユーザーも例外ではありませんでした。
本記事では、この事件を通じて明らかになったDNSSEC運用の暗部、特にNegative Trust Anchor（NTA） 適用時の「透明性の欠如」問題を解決するために導入されたExtended DNS Error（EDE）コード33について詳しく解説します。単なる障害報告ではなく、DNSエコシステムの信頼性と透明性を高めるための重要なアーキテクチャ改善プロセスを一緒に理解していただければ幸いです。
事件分析：.al DNSSECロールオーバー失敗の全容
1. 何が起こったのか
.alの運用機関（AKEP）がDNSSECキーロールオーバーを試みましたが、新しいキー（DNSKEY）を公開しながら古いキーを削除する過程で問題が発生しました。ルートゾーンのDSレコードが依然として古いキー（id=26319）を指していたため、検証を実行するすべてのリゾルバは.al応答の検証に失敗し、SERVFAILを返しました。
2. なぜ障害が長期化したのか
障害発生後約3時間、誰も問題を解決できませんでした。運用機関の連絡先アドレス自体が.alドメイン以下にあったため、連絡自体が不可能だったからです。結局Cloudflareは、ユーザー被害を最小限に抑えるためにRFC 7646で定義されたNegative Trust Anchor（NTA） を1.1.1.1に適用しました。
3. NTAとは何か、そして何が問題だったのか
NTAは、リゾルバが特定のゾーンを「署名されていないゾーン」として扱い、DNSSEC検証を一時的にスキップするようにするメカニズムです。これにより、ユーザーはSERVFAILの代わりに通常のDNS応答を受け取ることができます。
しかし、致命的な問題が一つありました。 NTAが適用された応答は、DNSSEC検証を通過した正常な応答とクライアント側で区別できませんでした。つまり、ユーザーは応答がスプーフィングされたものなのか、実際の正当な応答なのかを知ることができなかったのです。
# NTA適用前：検証失敗によりSERVFAILを返す
$ dig @1.1.1.1 google.al
;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 12345
;; QUESTION SECTION:
;google.al. IN A
# NTA適用後：応答は来るが、検証有無が分からない
$ dig @1.1.1.1 google.al
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 12346
;; ANSWER SECTION:
google.al. 300 IN A 142.251.142.196
上記のコードからわかるように、NTA適用後の応答は通常の正常応答と完全に同一です。これが問題の核心でした。
解決策：EDEコード33（Disclosure of Negative Trust Anchors）
RFC 8914で定義されたExtended DNS Error（EDE） コードは、DNS応答に追加のコンテキストを含めることを可能にします。CloudflareとQuad9のBabak Farrokhiは、このメカニズムを活用して、NTA適用事実を応答に直接明示する新しいEDEコードを提案しました。
実際の応答例
# .al障害期間中に1.1.1.1へ問い合わせた結果
$ 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
この応答では、2つの重要な情報を確認できます。
- EDE 9 (DNSKEY Missing)：根本的なDNSSEC検証失敗の原因を示します。
- EDE 33 (Negative Trust Anchor)：この応答がNTAによって提供され、DNSSEC検証を通過していないことを明示します。
この2つの情報を併せて提供することで、クライアントと運用ツールは応答の信頼性を正確に評価できるようになりました。
注意点と発展的なヒント
- NTA適用範囲：NTAは該当ゾーン全体に適用されるため、DNSSECを使用していないドメインへの応答にもEDE 33が含まれる可能性があります。これは意図された動作であり、透明性の原則に合致します。
- 既存EDEコードとの競合：以前の
.de事件では1.1.1.1がEDE 22（No Reachable Authority）を誤って返しましたが、今回はEDE 9と33を正確に返し、問題を改善しました。 - 導入状況：EDE 33はIANAに登録され、
kdigツールはすでに名前で認識します。UnboundへのPRもレビュー中です。他のリゾルバ実装の採用が期待されます。
結論：透明性こそが信頼性
今回の.al事件は、DNSSEC運用においてNTAがどれほど重要なツールであるか、そして同時にどれほど危険であり得るかを示しています。NTAは障害時にサービス継続性を維持するために不可欠ですが、ユーザーに検証が省略された事実を伝えなければ、セキュリティインシデントにつながる可能性があります。
EDE 33はこのギャップを埋める重要な第一歩です。これにより、DNS応答自体がNTA適用事実を伝え、運用者とモニタリングツールがより正確な判断を下せるようになりました。
日本における適用文脈
国内でDNSインフラを運用する企業にとっても、この事例は注目に値します。特に、高い可用性が求められる環境では、DNSSEC検証失敗時にNTAの適用を検討する必要がありますが、その過程で透明性を保証する仕組みを併せて整備することが重要です。EDE 33の導入は、単なる技術的改善にとどまらず、障害対応プロセスの信頼性を高める契機となるでしょう。
次のステップとしての学習方向
- RFC 7646とRFC 8914を直接読み、NTAとEDEの詳細な動作原理を理解しましょう。
- 実際のDNSリゾルバ（Unbound、Knot Resolverなど）でEDEコードがどのように処理されるか確認してみましょう。
- DNSSEC検証失敗の状況を再現し、NTA適用前後の応答の違いを実際に試してみましょう。
合わせて読みたい記事