DocsDigest
一覧へLanguage: EN
OpenAICloudflare2026/07/14 13:00

A broken DNSSEC rollover took down .AL. Now 1.1.1.1 tells you when validation is bypassed

要点だけを先に読めるように短く再構成したセクションです。

元記事
OpenAIClaude

Quick Digest

要約

要点だけを先に読めるように短く再構成したセクションです。

openaijamodel: gpt-5-mini-2025-08-07

DNSSECロールオーバー失敗で .AL が停止 — 1.1.1.1 が NTA 適用を EDE で通知

dnssecntaederesolverdnsdnsop

Key Points

  • .ALのDNSSECロールオーバー失敗
  • .1.1.1.1がEDE33でNTAを通知
  • NTA適用中はDNSSEC保護が一時消失

Summary

2026年7月3日、.AL の DNSSEC キーロールオーバーが失敗し、ルートの DS レコードと .AL の DNSKEY が不整合になったため、検証を行うリゾルバで広範な SERVFAIL が発生しました。Cloudflare の 1.1.1.1 は一時的に Negative Trust Anchor (NTA) を導入して解決しましたが、NTA 適用中は DNSSEC 検証が無効化されるため偽装リスクが残ります。今回、1.1.1.1 は EDE（Extended DNS Error）コード 33 を追加して、NTA によって検証がバイパスされた旨をレスポンスで通知するようになりました。

Key Points

  • 発生と影響
    • .AL のオペレーターが新しい DNSKEY を公開して旧キーを停止、ルートの DS は旧キーを指し続けたため検証に失敗。
    • 全 TLD 下の名前が影響を受け、検証リゾルバはSERVFAILを返す事態に。
  • 対応とトレードオフ
    • 1.1.1.1 は約3時間後に NTA を適用して解決（応答を復旧）が、DNSSEC 保護は一時的に無効化。
    • NTA 適用中の応答に EDE 9（DNSKEY Missing）と新しい EDE 33（Negative Trust Anchor）を付与して透明性を確保。
  • 実務上の推奨（エンジニア向け）
    • リゾルバと監視ツールで EDE を収集・解析する（EDE 33 を認識するようにツールを更新）。
    • キーロールオーバー前にルートの DS と TLD の DNSKEY の一致を確認し、ロールバック手順と連絡先を TLD 外に用意する。
    • NTA は最終手段：可用性確保と検証保証のトレードオフを理解して運用方針に明記する。
    • kdig や Unbound 等のツールが EDE 33 をサポートしているか確認し、監視アラートに組み込む。

短く言えば、NTA は可用性を取り戻す有効な手段だが透明性が重要で、EDE 33 によってクライアントや監視系が "検証がバイパスされた" 事実を受け取れるようになったため、運用側はこれを監視・通知フローに組み込むべきです。

Full Translation

翻訳

原文の流れを保ったまま読める翻訳セクションです。

openaijamodel: gpt-5-mini-2025-08-07

壊れたDNSSECロールオーバーが .AL をダウンさせた。1.1.1.1 は検証がバイパスされたときに通知する

壊れたDNSSECロールオーバーが .AL をダウンさせた。1.1.1.1 は検証がバイパスされたときに通知する

2026-07-14 — Sebastiaan Neuteboom 6分読了

2026年7月3日、アルバニアの通信当局であり .AL（アルバニアのccTLD）の運営者である AKEP が DNSSEC のキー・ロールオーバーを試みました。何かがうまくいかず、DNSSEC 検証の失敗が発生しました。DNSSEC 仕様に従い、これらの署名を受け取った検証対応の再帰的リゾルバはそれらを拒否し、クライアントにエラーを返す必要がありました。これには Cloudflare が運営するパブリック DNS リゾルバ 1.1.1.1 も含まれます。

.AL TLD はアルバニアの政府サービス、銀行、メディアのオンライン上の居場所であり、Cloudflare Radar の TLD ランキングでは #191 にランクされています。検証対応のリゾルバを利用していたユーザーは、インシデントの間これらのサイトにアクセスできませんでした。この障害は、ホスティング先や権威ネームサーバーに関係なく、.AL の全てのドメインに影響を及ぼす可能性がありました。

ほんの2か月前に、同様のインシデントがドイツの TLD である .DE でも発生しました。我々がそのときに行った対応（ブログ投稿参照）は、.DE に対して Negative Trust Anchor（NTA）を設置し、問題解決中に 1.1.1.1 の DNSSEC 検証を一時的に停止してドメインの到達性を保つことでした。今回、同じ対応を .AL に対しても実施しました。

NTAs は解決を復元しますが、サイレントに行われます。NTA 下で返されたレスポンスから、クライアントは DNSSEC 検証がバイパスされたことをレスポンスだけで判断できません。そのため、本件では 1.1.1.1 が初めてギャップを埋め、NTA が適用された影響下のレスポンスに対して新しい Extended DNS Error（EDE）コードを返し、回答が DNSSEC 検証されていないことを通知しました。

以下のグラフは、7月3日を通じた 1.1.1.1 に対する .AL クエリの SERVFAIL と NOERROR の割合を示しています。キャッシュされたレコードの有効期限が切れてリゾルバが再検証を強いられるにつれて SERVFAIL が増加し、17:15 UTC に NTA が適用され解決が復元されると急激に低下しています。

何が起きたか

DNSSEC の仕組みについては以前のブログ投稿でも詳述しましたが、簡単に振り返ります。

  • DNSSEC はルートゾーンから個々のドメイン名までの信頼の連鎖を構築します。
  • ルートゾーンは署名された各TLD に対して Delegation Signer（DS）レコードを保持します。これはその TLD が提供する DNSKEY のフィンガープリントです。
  • .AL を検証するリゾルバは、.AL のネームサーバが返す DNSKEY がルートにある DS レコードと一致するかを確認します。一致すれば .AL のネームサーバからの応答は真正であると信頼します。
  • このパターンは階層下のレベルでも繰り返されます。つまり、どこかでチェーンが途切れる（たとえば DS が存在しないキーを指している）と、その下位のすべてに対して検証は失敗します。

インシデント前、ルートゾーンは .AL のネームサーバが提供する DNSKEY と一致する DS レコードを保持していました。概略は以下の通りです：

  • 14:15 UTC 頃、.AL の運営者が新しい DNSKEY を公開し、古いキーの提供を停止しました。
  • ルートゾーンの DS レコードは依然として古い DNSKEY（id=26319）を指していたため、.AL を検証しようとしたリゾルバは一致するキーが見つからず検証失敗となりました。
  • 17:00 UTC 頃、運営者は新しい DNSKEY を削除したが、古いキーも復元しませんでした。ゾーンに DNSKEY が全く存在しない状態になり、ルートの DS は依然 id=26319 を指したままでした。解決は引き続き失敗しました。
  • 19:15 UTC 頃、運営者がルートゾーンから DS レコードを削除しました。DS レコードがないため、リゾルバは .AL に対して DNSSEC を期待しなくなり、解決は復元されましたが、その時点で TLD 全体が無署名になりました。

公開時点で、.AL は依然として無署名のままです。運営者によってルートゾーンに DS レコードは復元されていません。DS レコードがない限り、すべての .AL ドメインは DNSSEC の保護を利用できません。

なぜ Negative Trust Anchors を使うのか

DNSSEC 設定の破損は痛手であり、とくにTLD全体に一度に影響する場合は非常に深刻です。前回の .DE インシデントで説明したように、再帰的 DNS オペレータは RFC 7646 で定義されている Negative Trust Anchor をインストールしてゾーンを無署名扱いにし、検証をバイパスできます。

NTA を設置する前に、我々は .AL の運営者に直接連絡を試み、DNS-OARC の Mattermost に投稿してコミュニティにアラートを出しましたが応答は得られませんでした。これは連絡先のアドレス自体が .AL の下にあり、障害中に到達不能になっていたことが一因です。

我々は .AL に対する NTA を適用し、約3時間後の 17:15 UTC までに全 1.1.1.1 ユーザにロールアウトしました。

トレードオフは .DE のときと同じです：Negative Trust Anchor は DNSSEC 検証を停止するため、NTA の適用期間中は .AL ドメインは DNS スプーフィングに対して保護されません。我々はこの判断を次の理由で受け入れました：失敗は公に確認されており、すべての検証対応リゾルバに同等に影響していました。

NTA は翌日に削除されました。運営者がルートゾーンから DS レコードを削除したため、リゾルバは .AL に対する DNSSEC を期待しなくなり、NTA は不要になりました。

Negative Trust Anchors の問題点

NTA をインストールすることは攻めの手段です。ゾーンを到達可能に保つために DNSSEC 検証を停止し、その間レスポンスは暗号的に検証されなくなります。ユーザーは SERVFAIL の代わりに回答を得ますが、その回答には DNSSEC の保証がありません。

これをさらに難しくしているのは、これまでレスポンス内にそれをクライアントに伝える仕組みがなかったことです。NTA 下で提供されたレスポンスは、完全に検証されたものと見た目は同一でした。RFC 7646 はこのギャップを認め、オペレータが設置している NTA を公開することを推奨していますが、その公開はアウト・オブ・バンド（別経路）で行われます。

.DE と .AL の両方のインシデントで我々はステータスページを公開しましたが、ステータスページはユーザーが探しに行かなければなりません。アプリケーション、監視ツール、あるいは 1.1.1.1 をクエリするユーザーは、レスポンスだけから DNSSEC 検証がバイパスされたかどうかを判別できませんでした。

Negative Trust Anchors に透明性を与える

Extended DNS Error（EDE）コード（RFC 8914 で定義）は、リゾルバがエラーでも成功した回答でも追加コンテキストを DNS レスポンスに添えて返すことを可能にします。Quad9 の Babak Farrokhi は、DNS レスポンス内で直接 Negative Trust Anchor の存在を知らせるための Internet-Draft（Disclosure of Negative Trust Anchors in DNS Responses）を提案しました。我々は共著者として参加し、1.1.1.1 はこれを実装しました。

.AL インシデントの間、NTA がインストールされている間に .AL 名のクエリを行うと、回答とともに新しい 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 で有効な回答を含みますが、2つの EDE コードが付随しています。EDE 9（DNSKEY Missing）は根本的な DNSSEC 失敗を示します：信頼の連鎖が途切れ、検証が失敗したことを示します。EDE 33（Negative Trust Anchor）は 1.1.1.1 が NTA を適用し、それにもかかわらずレスポンスを返していることを示します。

これらは合わせてクライアントやオペレータに何が起きたかを可視化します：回答は実際に存在するが、DNSSEC による検証はされていません。

1.1.1.1 は NTA がアクティブな間に生成される任意のレスポンスに対して EDE 33 を返します。クエリ自体が DNSSEC 検証に失敗したかどうかに関係なく、そのゾーンに対して NTA が有効であれば EDE 33 は付加されます。NTA はゾーン全体をカバーするため、NTA 下で提供されるすべてのレスポンスに透明性が均等に適用されます。

また、これは我々が .DE のブログで指摘した問題も解決します。以前は 1.1.1.1 が本来表面化すべき DNSSEC エラーではなく、誤って EDE 22（No Reachable Authority）を返していました。.AL インシデント中は 1.1.1.1 は EDE 9（DNSKEY Missing）を正しく EDE 33 と共に返しました。

この Internet-Draft は個人提出であり、EDE 33 は IANA によって割り当てられています。共同著者である Quad9 の Babak Farrokhi によって、Knot プロジェクトの kdig ツールは EDE 33 を名前付きで認識するようになり、Unbound へのプルリクエストもレビュー中です。他のリゾルバ実装も追随することを期待しています。

Internet-Draft は IETF DNSOP Working Group に提出されており、2026年7月18日から24日にウィーンで開催される IETF 会合で議論される予定です。

ギャップを埋める

TLD レベルの DNSSEC 障害は稀ですが、発生した場合は影響下の TLD 配下の全ドメインに同時に影響し、すべての検証対応リゾルバに同等に影響します。.AL のインシデントは .DE に続き、Negative Trust Anchors が運用上必要なツールである一方で、それが影響するユーザーに対してこれまで見えなかったことを示しました。

EDE 33 は RFC 7646 が残したギャップを埋めます。NTA 下で提供されるレスポンスは直接その旨を示すようになり、オペレータ、監視ツール、ユーザーはリゾルバが何を行い、なぜ行ったかを理解するための情報を得られます。

  • Internet-Draft は IETF datatracker で入手できます。
  • フィードバックは IETF DNSOP メーリングリストで共有してください。
  • DNSSEC の仕組みについて詳しく知りたい場合は「How does DNSSEC work?」のページをご覧ください。
  • リアルタイムの DNS トレンドや TLD データは Cloudflare Radar で確認できます。

カテゴリ: DNS, DNSSEC, Post Mortem, 1.1.1.1, Reliability, Standards