「.al」のDNSSECロールオーバー失敗を受け、Cloudflareが検証バイパスを通知する拡張DNSエラーを実装

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

元記事は一次情報へのリンクです元記事を読む

5行でつかむ要点

2026年7月3日、アルバニアの通信当局によるDNSSEC鍵ロールオーバーの失敗で「.al」ドメイン全体が名前解決できなくなった。

Cloudflareは1.1.1.1リゾルバにNegative Trust Anchor(NTA)を適用し復旧させたが、検証がバイパスされていることは利用者に伝わらなかった。

この課題を解決するため、Cloudflareは新しい拡張DNSエラー「EDE 33」を実装した。

国レベルのTLDでDNSSEC障害が起きた際、復旧のために検証を迂回していることが利用者側からも見えるようになる点は、DNS運用担当者にとって見過ごせない変化である。

同種の障害は過去にも他のTLDで起きており、今回のEDE 33が他のリゾルバ実装にも広がるかは今後の動向として追っておきたい。

7月3日、アルバニアの通信当局が「.al」ドメインのDNSSEC鍵ロールオーバーを行った際、DNSKEYレコードは更新したもののルートゾーンのDS(Delegation Signer)レコードの更新を怠った。この結果、信頼の連鎖が途切れ、検証を行う全リゾルバが「.al」ドメイン全体を無効と判定し、名前解決できなくなった。

復旧の判断

Cloudflareは1.1.1.1リゾルバに、RFC 7646に基づくNegative Trust Anchor(NTA)を適用し、DNSSEC検証を一時的に停止させることで、障害発生から約3時間後の17:15 UTCに復旧させた。国レベルのドメインが丸ごと引けなくなる事態は、影響範囲・復旧までの緊張感ともに大きかったはずだ。

見えなかった問題を可視化する

ここで浮かび上がったのが、NTAには「検証をバイパスしている」ことをクライアント側に伝える手段がないという課題だ。ユーザーやアプリケーションからは、正規に検証された応答なのか、緊急避難的に迂回された応答なのかが区別できない。Cloudflareは、Quad9のBabak Farrokhi氏が提案するIETFドラフトを踏まえ、拡張DNSエラー(EDE)コード33を実装し、NTA適用中である旨をDNS応答に明示するようにした。

過去の教訓の延長線上

Cloudflareは今回の対応にあたり、過去に起きた「.de」障害の経験を踏まえたとしている。TLDレベルのDNSSEC障害は繰り返し起きており、そのたびに復旧手段は磨かれてきたが、「復旧させたこと自体を透明化する」という今回の一手は、監視ツールやアプリケーション側が異常を検知しやすくする地味だが重要な改善だ。同種の障害は今後も避けられないだけに、他のリゾルバ実装への波及を期待したい。詳しい経緯はThe Cloudflare Blogの記事(https://blog.cloudflare.com/dnssec-nta-ede-33/)にまとめられている。