.ALドメインのDNSSEC障害、CloudflareがEDE 33で透明性を向上
2026年7月3日、アルバニアの国別コードトップレベルドメイン「.AL」でDNSSECの鍵ロールオーバーに失敗する障害が発生した。この影響で、.ALドメインを使用する政府機関や銀行、メディアサイトが一時的にアクセス不能となった。
Cloudflareが運用するパブリックDNSリゾルバ「1.1.1.1」は、この障害に対してネガティブトラストアンカー（NTA）を適用して暫定対応を実施。同時に、新しい拡張DNSエラー（EDE）コード「EDE 33」を初めて導入し、NTAが適用されていることをクライアントに明示した。
この記事では、.AL障害の経緯と、DNS運用におけるNTAの透明性を高めるEDE 33の技術的意義を解説する。TLDレベルのDNSSEC障害がもたらす影響と、再発防止に向けた課題を考察する。
.ALドメインで何が起きたのか
2026年7月3日14時15分（UTC）ごろ、アルバニアの通信規制当局AKEPが.AL TLDのDNSSEC鍵を更新しようとした際に設定ミスが発生した。新しいDNSKEYを公開したが、ルートゾーンに登録されていたDSレコードは古い鍵のままであり、DNSSECの信頼チェーンが切断された。
その結果、1.1.1.1を含む世界中の検証対応DNSリゾルバは、.ALドメインのDNS応答を検証エラー（SERVFAIL）として拒否するようになった。障害発生から約3時間後の17時15分、Cloudflareは1.1.1.1に.AL向けのNTAを適用し、検証を一時的にバイパスして名前解決を回復させた。
AKEPはその後、新しいDNSKEYも削除してしまい、ゾーンからDNSKEYが存在しない状態に陥った。最終的に19時15分ごろ、ルートゾーンからDSレコードが削除され、.AL全体がDNSSEC未署名の状態で名前解決が再開された。記事公開現在も、.ALは未署名のままである。
.DEに続くTLD障害の連鎖
この障害は、わずか2ヶ月前にドイツの.DE TLDで発生した同様のDNSSEC障害を想起させる。.DEの事例でも、1.1.1.1はNTAを適用して暫定対処を行い、事業者の対応を待つ形となった。
TLDレベルのDNSSEC障害は頻発するものではないが、一度発生すると配下の全ドメインに影響が波及する。.ALはCloudflare RadarのTLDランキングで191位に位置し、アルバニアの政府サービスや金融機関、報道機関などが集まる重要なドメイン空間だ。
この比較からわかるように、DNSSECの信頼チェーンはルートゾーンのDSレコードとTLDゾーンのDNSKEYが一致して初めて成立する。ロールオーバーの手順を誤ると、連鎖的に全下位ドメインの検証が失敗する仕組みだ。
NTA適用の判断基準
CloudflareはNTAを適用する前に、AKEPへの直接連絡とDNS-OARC Mattermostへの投稿を通じてコミュニティに注意喚起を行った。しかし、AKEPの連絡先アドレス自体が.ALドメインだったため、障害発生中は連絡が取れないという悪循環に陥った。
NTAの適用は、DNSSEC検証を停止するという強い措置だ。Cloudflareの著者によれば、.DEの事例と同様に「障害が公共に確認されており、すべての検証リゾルバに等しく影響する」という点を重視して判断したという。検証を停止しても名前解決を維持する方を優先した格好だ。
NTAの抱える透明性の課題
NTAはDNSSECの緊急回避手段として有効だが、一つ大きな欠点がある。それは、クライアント側からNTAの適用を検知できないことだ。NTA配下で返されたDNS応答は、通常の検証済み応答と見分けがつかない。
RFC 7646でもこの問題は認識されており、NTAの適用状況を運用者が公開することが推奨されている。Cloudflareは.DEや.ALの際にステータスページで情報を公開したが、それでも利用者が自発的に確認しなければ気づけない。監視ツールやアプリケーションがDNS応答だけで状況を把握する手段がなかった。
ANSWER: google.al → 142.251.142.196
EDE: 9 (DNSKEY Missing)
EDE: 33 (Negative Trust Anchor)
ANSWER: google.al → 142.251.142.196
● EDE 9で根本的なDNSSECエラーも同時に通知
この「見えないNTA」は、なりすましDNS応答と正当な応答を区別するDNSSECの根幹を揺るがす。NTAが適用されている間、利用者は保護されていない状態で通信していることになるが、それを知る術がなかったのだ。
EDE 33がもたらす透明性
拡張DNSエラー（EDE）コードはRFC 8914で定義されており、DNSリゾルバがエラー時だけでなく成功応答にも追加のコンテキスト情報を付加できる仕組みだ。Quad9のBabak Farrokhi氏が提案し、Cloudflareも共同執筆者として参加したインターネットドラフトで、NTAの適用を示す新しいEDEコード「EDE 33」が定義された。
1.1.1.1は.AL障害において、このEDE 33を初めて実運用に投入した。NTAが適用されている間、.ALドメインへのすべてのDNSクエリに対して、EDE 33が付加された応答が返されている。これにより、クライアントや監視ツールはDNS応答だけで「この応答はDNSSEC未検証である」と判断できるようになった。
EDE 33の実装と応答例
以下は、1.1.1.1にgoogle.alの名前解決を問い合わせた際の応答だ。ステータスはNOERRORで正しい回答が返されているが、2つの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.196EDE 9（DNSKEY Missing）は、DNSSECの信頼チェーンが切断された根本原因を示している。EDE 33（Negative Trust Anchor）は、1.1.1.1がNTAを適用して応答を返したことを示す。この2つの情報が揃うことで、運用者は「本来は検証エラーになる状況だが、NTAによって暫定的に解決された」という全体像を把握できる。
このフローは、1.1.1.1内部でNTAがどのように処理されるかを示している。EDE 33は、NTAが有効な間、DNSSECを使っていないドメインへのクエリにも付加される。NTAはゾーン全体に適用されるため、透明性もゾーン全体に対して一律に提供される設計だ。
.DE障害で生じた問題も解決
.DE障害の際、1.1.1.1はDNSSECの根本エラーではなく「EDE 22（No Reachable Authority）」を誤って返していた。これは、NTA配下で権威サーバーに到達できない場合に発生するエラーであり、真の原因を隠蔽してしまう問題があった。
.AL障害ではこの点が改善され、EDE 9（DNSKEY Missing）が正しく返されている。EDE 33と組み合わせることで、「なぜ検証に失敗したのか」と「なぜ応答が返されたのか」の両方をクライアントが把握できるようになった。
今後の標準化と運用への影響
EDE 33はIANA（Internet Assigned Numbers Authority）によって正式に割り当てられており、Knot DNSプロジェクトのkdigツールはすでにEDE 33を名前で認識するようになっている。また、Unbound向けのプルリクエストもレビュー段階にある。他のDNSリゾルバ実装も追随することが期待される。
このインターネットドラフトはIETFのDNSOPワーキンググループに提出済みで、2026年7月18日から24日にウィーンで開催されるIETF会合で議論される予定だ。標準化が進めば、EDE 33はすべての主要DNSリゾルバで実装される可能性が高い。
国内DNS運用者への示唆
国内のISPや企業が運用するDNSリゾルバでも、DNSSEC検証を有効にしているケースが増えている。.ALのようなTLDレベルの障害は稀だが、.JPや他のccTLDで発生しないとは限らない。EDE 33に対応したリゾルバ実装を採用することで、障害時の透明性を確保できる。
また、NTAの運用には慎重さが求められる。Cloudflareは.DEと.ALの両方で、コミュニティへの通知後にNTAを適用し、問題解決後に速やかに解除している。このバランス感覚は、他のDNS運用者にとっても参考になる対応だ。
残された課題
記事公開現在、.ALはDNSSEC未署名のままだ。DSレコードがルートゾーンに再登録されない限り、.AL配下のすべてのドメインはDNSSECの保護を受けられない。AKEPがいつ復旧作業を完了させるかは不透明である。
より根本的な問題として、TLD事業者のDNSSEC運用スキル不足が浮き彫りになった。鍵ロールオーバーは手順を誤ると広範囲に影響を及ぼす重要なオペレーションだ。ICANNやレジストリコミュニティによるガイドラインの整備や訓練の機会提供が求められる。
この記事のポイント
- .AL TLDのDNSSEC鍵ロールオーバー失敗により、2026年7月3日に全.ALドメインが一時的に解決不能となった
- Cloudflareの1.1.1.1はNTAを適用して暫定対処を行い、同時に新しいEDEコード「EDE 33」を初めて実運用に投入した
- EDE 33はNTAの適用をDNS応答内で明示し、従来の「見えないNTA」問題を解決する
- .DEに続くTLDレベルのDNSSEC障害は、TLD事業者の運用スキル向上とNTAの標準化の必要性を浮き彫りにした
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
de TLD障害の全容 DNSSEC署名破損でSERVFAIL多発 Cloudflareの一時的緩和策を解説
2026年5月5日、およそ19時30分（UTC）、ドイツの国別コードトップレベルドメインである .de を管理するレジストリ DENIC が、同ゾーンのDNSSEC署名を誤って公開し始めた。この誤った署名は、DNSSEC検証を行うすべてのDNSリゾルバにSERVFAILを返させる結果となり、Cloudflareの公開リゾルバ1.1.1.1も例外ではなかった。
.de はインターネット上で最もクエリ数の多いTLDのひとつで、Cloudflare Radarのデータでも常に上位にランクインする。このレベルのDNS階層で障害が発生すると、数百万のドメインが到達不能になる可能性がある。本記事では、Cloudflareが観測した現象、影響の範囲、さらにDENICが問題を解決するまでの間に1.1.1.1が適用した一時的緩和策について解説する。
.de TLD障害の原因と発覚の経緯
DNSSEC署名が破損したことで、リゾルバは応答を信用せずSERVFAILを返す。この仕組みは正しいが、大規模な影響を引き起こした。19時30分の直後からSERVFAILが急増し、キャッシュの期限切れに伴って3時間にわたって増え続けた。クエリのリトライにより通信量も増大し、SERVFAILの件数は実際のユーザー影響以上に見える。
DENICは後の声明で「定例の鍵ローテーション中に、検証できない署名が生成・配布された」と説明しており、今後のローテーションは原因特定まで停止されている。
DNSSECの仕組みと署名検証の役割
DSレコード
検証失敗
DNSSEC（Domain Name System Security Extensions）は、DNS応答にデジタル署名を付与して改ざんを防ぐ仕組みだ。各ゾーンのレコードセットにはRRSIGレコードが付随し、リゾルバはこれを用いて原本性を確認する。署名は保護対象のレコードと一緒に運ばれるため、キャッシュを経由しても検証可能だ。
信頼の連鎖はルートゾーンから始まり、親ゾーンがDSレコードで子ゾーンの公開鍵を証明する。.deの上位にはルートがあり、.deの下に個々のドメインがぶらさがる。どこか一か所で署名が破綻すると、その先の全ドメインが検証に失敗する。今回のようにTLDで署名ミスが起きれば、配下のすべての .de ドメインがSERVFAILになる。
DNSSECでは、ゾーン署名鍵（ZSK）と鍵署名鍵（KSK）を使い分ける。ZSKはレコードそのものに署名し、KSKはZSKに署名する。KSKの公開鍵が親ゾーンのDSレコードと結びつき、信頼の基点となる。鍵のローテーション時に新しい鍵が正しく配布されなかったり、署名生成に失敗すると、今回のような大規模障害につながる。
キャッシュとserve staleが被害を軽減
クエリ → キャッシュから応答（NOERROR）
DENICへ問い合わせ → SERVFAIL
キャッシュ期限切れでも古いデータを返し続ける
リゾルバはTTL（生存時間）の間、権威サーバーから受け取ったレコードをキャッシュする。TTLが切れると、新しい情報を取りに行く。ところが障害発生中は、新たに取得しようとするとSERVFAILに終わる。そこでCloudflareの1.1.1.1はRFC 8767に従い、キャッシュの期限が切れた後も古いレコードを応答し続ける「serve stale」を実施した。
このおかげで、キャッシュに残っていた .de ドメインの多くは引き続き解決され、ユーザーへの影響は大幅に和らげられた。グラフからも、incident中にNOERRORが一定数維持されたことが分かる。serve staleがなければ、故障が始まった瞬間から全クエリが失敗していた。
Cloudflare 1.1.1.1が講じた一時的緩和策
serve staleだけではカバーできないクエリもあったため、Cloudflareは22時17分（UTC）に .de ゾーンに対して一時的なNTA（Negative Trust Anchor）に相当する措置を適用した。具体的には、内部のオーバーライドルールを使って .de 全体を「DNSSEC未対応ゾーン」のように扱い、署名検証をスキップさせた。
RFC 7646はまさにこうした状況のためにNTAを定義している。TLD運営者が破損した署名を公開した場合、正しいドメインまで巻き添えでSERVFAILになるより、一時的に検証を外す方がユーザーにとって有益だという判断だ。Cloudflareの内部議論でも「1.1.1.1を使っているユーザーで、検証失敗よりも未検証の応答の方を望まない者はいない」と結論づけられている。
同時に、CDNサービスを利用する顧客向けの内部リゾルバにも同様の対応を施し、 .de をオリジンとするサイトの接続性を回復させた。また、対策を即座にDNS-OARCのチャットで共有し、他の事業者との連携も行った。
なお、1.1.1.1が返していたSERVFAILにはEDEコード22（到達可能な権威サーバーなし）が付与されていたが、本来はEDE 6（DNSSEC無効）が適切だ。Cloudflareはこのバグを認識しており、今後DNSSECエラーを正しく表面化させる修正を予定している。
インシデントから学ぶ教訓と今後の改善点
この障害は、DNSの階層構造がもつ脆弱性を改めて浮き彫りにした。TLDレベルで発生した問題は、その下にあるすべてのドメインに等しく波及する。これはDNSSECに限った話ではなく、権威サーバー自体が到達不能になれば同じことが起こる。
根本的な回避策は存在しないが、迅速な連携と運用上の工夫で被害を抑えられる。今回、多くのリゾルバ事業者が1時間以内にNTAを適用し、解決までの間ユーザーの影響を緩和した。DNS-OARCのような業界コミュニティの存在も、こうした危機対応のスピードを支えている。
技術面では、serve staleのような仕組みがTier-1レベルの障害時に有効に機能することが改めて示された。また、EDEエラーコードの適切な実装は、トラブルシューティングを容易にし、運用者間の情報共有を効率化する。Cloudflareもこの点の改善に着手する。
この記事のポイント
- 2026年5月5日、.de TLDのDNSSEC鍵ローテーション中に不正な署名が生じ、全DNSSEC検証リゾルバがSERVFAILを返した
- DNSの階層構造上、TLDの障害は配下のドメインすべてに影響する
- Cloudflareの1.1.1.1はserve staleでキャッシュを延命し、さらに一時的にDNSSEC検証を無効化するNTA相当の対策を22時17分に適用
- RFC 7646に定義されたNTAは、事業者間の迅速な合意形成があれば被害を大幅に軽減できる
- EDEエラーコードの不備など、リゾルバ側の改善点も事例から明らかになった
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験