DNSSEC検証が「静かに無効化」される問題に終止符 — CloudflareがEDE 33で実現したNTAの可視化

はじめに：DNSSECが壊れると何が起きるのか

2026年7月3日、アルバニアの国別コードTLD .al を運用するAKEPがDNSSECキーロールオーバーを試みました。結果は深刻でした。ルートゾーンのDSレコードは依然として旧DNSKEY（id=26319）を指しているにもかかわらず、.al のネームサーバーは新しいキーのみを配信し始めたのです。DNSSEC仕様に準拠するすべての検証リゾルバはこの署名を拒否する必要があり、Cloudflareの1.1.1.1も例外ではありませんでした。

問題は、.al がアルバニア政府サービス、銀行、メディアのオンライン拠点であることです。検証リゾルバを利用するユーザーにとって、これらのドメインはすべて「到達不能」となりました。ホスティング場所や権威ネームサーバーに関係なく、.al 配下のすべてのドメインが影響を受けました。

わずか2か月前には、ドイツの .de TLDでも同様のインシデントが発生していました。当時の対応は Negative Trust Anchor（NTA） を設置し、DNSSEC検証を一時的に停止するものでした。今回の .al インシデントでも同じ措置が取られましたが、Cloudflareはさらに一歩踏み込みました。応答にEDE 33コードを付与し、「この回答は検証されていない」ことを明示的に通知したのです。これが本記事の核心です。

なお、本記事はCloudflareの根拠資料を基に再構成しています。

Part 2: NTAはなぜ「静かな危険」なのか

DNSSEC信頼チェーンの構造

DNSSECはルートゾーンから個別ドメインまで 信頼チェーン（chain of trust） を構築します。ルートゾーンは各署名済みTLDのDNSKEY指紋であるDSレコードを保持しています。リゾルバが .al を検証する際、.al ネームサーバーが配信するDNSKEYがルートのDSレコードと一致するかを確認します。一致すれば、.al ネームサーバーの応答を信頼する仕組みです。

今回のインシデントのタイムラインを整理すると以下の通りです。

NTAのトレードオフ

NTAはRFC 7646で定義された概念で、リゾルバに対して「このゾーンを未署名として扱い、検証をスキップせよ」と指示します。ドメインが再び到達可能になる代わりに、DNSSECによるスプーフィング防御が失われます。

ここで本当の問題は 透明性 でした。NTA下で配信された応答は、正常に検証された応答と 見た目上まったく同じ でした。RFC 7646は運用者に対しNTA適用の公開を推奨していますが、それはout-of-band（ステータスページ等）の方法であり、ユーザーが自ら探しに行く必要がある構造でした。アプリケーションや監視ツールの立場からは、応答だけを見て検証バイパスの有無を判断する方法がなかったのです。

Part 3: EDE 33が解決したもの — 応答そのものに語らせる

EDE（Extended DNS Error）とは

RFC 8914で定義されたEDEコードは、リゾルバがDNS応答に追加コンテキストを付与できる仕組みです。Quad9のBabak Farrokhi氏がNTAの存在を応答に直接シグナリングするInternet-Draftを提案し、Cloudflareが共同著者として参加して1.1.1.1に実装しました。それが EDE 33（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 で正常なAレコードを含んでいます。google.al は解決されます。しかし、2つのEDEコードが付随します。

• EDE 9（DNSKEY Missing）: 根本原因であるDNSSEC失敗を露出。信頼チェーンが壊れ、検証が失敗したこと。
• EDE 33（Negative Trust Anchor）: 1.1.1.1がNTAを適用し、応答をそのまま配信したことを通知。

両コードを組み合わせることで、クライアントと運用者の双方に完全な可視性を提供します。「回答は本物だが、DNSSEC検証はされていない」 という事実を応答自体が語ってくれるのです。

注意点：EDE 33は「ゾーン全体」に適用される

1.1.1.1はNTAが有効な間、生成される すべての 応答にEDE 33を付与します。DNSSECをまったく使用しないドメインでも、NTAの範囲に入ればEDE 33が付いてきます。これは意図された動作です。NTAはゾーン全体をカバーし、透明性はその下で配信されるすべての応答に等しく適用されるべきだからです。

これは以前の .de インシデントでCloudflareが指摘していた問題も解決します。当時、1.1.1.1は根本原因であるDNSSECエラーの代わりにEDE 22（No Reachable Authority）を誤って返していましたが、今回の .al インシデントではEDE 9とEDE 33を正確に同時返却しました。

Part 4: 日本の開発エコシステムへの示唆

国内環境における意味

日本の金融機関や公共系システムでもDNSSEC導入は進んでいますが、TLDレベルの障害対応ランブック を整備している組織はほとんどありません。多くの運用チームは「DNSSECを有効にすればセキュリティが向上する」という理解に留まり、ロールオーバー失敗時の対応手順が未整備なケースが目立ちます。

今回の事例から学ぶべき点は3つです。

1. NTAは最後の手段であり、デフォルトではない。 検証を切った瞬間にスプーフィング防御が失われる事実を明確に認識すべきです。
2. 監視ツールはEDEコードをパースすべき。 応答だけを見てNOERRORと判断すると、実際には検証がバイパスされた応答を正常と誤認する可能性があります。
3. リゾルバの選択が可観測性そのもの。 Cloudflare 1.1.1.1、Quad9、Google DNSなどがEDE対応範囲をどこまで広げるか注視する必要があります。

限界と注意事項

• EDE 33は Internet-Draft段階 です。IANAがコードは割り当てましたが、まだ標準ではありません。UnboundはPRレビュー中、Knotの kdig は既に対応済みです。他のリゾルバ実装がどの程度迅速に追随するかは不透明です。
• NTA自体は依然として ゾーン全体の検証を切る強硬な措置 です。細分化された例外処理ではありません。
• .al は本記事執筆時点で 依然unsigned状態 です。DSレコードが復元されておらず、すべての .al ドメインがDNSSEC保護を受けられていません。

次のステップ学習方向

• RFC 7646（Negative Trust Anchors）: NTAの定義と運用ガイドラインを原文で確認してください。
• RFC 8914（Extended DNS Errors）: EDEコードの全リストと活用事例を確認すると、監視ツール設計に役立ちます。
• RFC 4033〜4035（DNSSEC基本仕様）: 信頼チェーンの構成を根本から理解したい場合はここから始めてください。
• Cloudflare Radar: リアルタイムのTLDトレンドとDNSSEC署名状態を確認できます。

あわせて読みたい

• メタが公開したBOxCrete AIでコンクリート配合を最適化するオープンソースモデル — オープンソースモデルが特定産業ドメインにどう適用されるかの事例に興味があれば。
• 90日かかっていたインフラ構築を数時間に短縮したサンタンデールのプラットフォームエンジニアリング戦略 — 大規模インフラ運用自動化の観点で参考になるケースです。

DNSは見えないときにもっとも良く機能します。しかしその「見えなさ」がリスクになるとき、EDE 33のように応答自体が語ってくれる構造が必要です。今回の事例はインフラ透明性の良い手本と言えるでしょう。