Cloudflareの1.1.1.1、.AL大混乱後にDNSSEC迂回を通知

2026年7月3日、アルバニアのTLD事業者AKEPがDNSSECキーロールオーバーを失敗し、すべての.ALドメインのトラストチェーンが断絶した。1.1.1.1などの検証リゾルバはすべての.AL応答を拒否せざるを得ず、政府、銀行、メディアのサイトが数時間にわたり到達不能となった。CloudflareはNegative Trust Anchor（NTA）を適用して解決を復旧したが、今回は新たなExtended DNS Error（EDE）コードを追加し、迂回をクライアントに可視化した。

何が問題だったのか

DNSSECはルートゾーンから下位へとトラストを連鎖させる。ルートはTLDのDNSKEYを指し示すDSレコードを保持する。.ALの事業者がDSレコードを更新せずに新しいDNSKEYを公開したため、ルートは依然として古いキーを指していた。リゾルバは一致するDNSKEYを見つけられず、検証に失敗した。その後、事業者は新しいキーを完全に削除し、ゾーンにはDNSKEYが一切ない状態となり、DSレコードは依然として古いキーを参照していた。数時間後、ルートからDSレコードが削除され、.ALは未署名となった。

同じパターンが2か月前の.DEでも発生した。当時のCloudflareの対応はNTA（RFC 7646）を導入することだった。これはリゾルバにゾーンを未署名として扱うよう指示する。機能はするが、静かに動作する——クライアントはDNSSEC保護が迂回されたことを示す兆候なしに応答を得る。

EDE 33：Negative Trust Anchorの透明性

Cloudflareは現在、NTAのもとで提供されるすべての応答にEDEコード33を付加している。このコードはNegative Trust Anchorが有効であったこと、つまり応答が暗号的に検証されていないことを示す。.ALインシデントでは、クエリはさらにEDE 9（DNSKEY欠落）を返し、根本的な障害を説明した。

両方のコードを含むdig応答は以下のようになる：

$ 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

EDE 33コードは、アクティブなNTAのもとでのすべてのクエリに対して返される。DNSSECを使用していないドメインであっても同様だ。これは意図的である：NTAはゾーン全体をカバーし、透明性は均一であるべきだからだ。

なぜこれが重要なのか

NTAは鈍器である。可用性を回復する代わりにセキュリティを犠牲にする。これまで、クライアントは検証済みの応答とNTAのもとで提供された応答を区別する方法がなかった。ステータスページはユーザーが自ら確認する必要がある。EDE 33はその情報をDNS応答自体に組み込み、監視ツールやアプリケーションが適切に反応できるようにする。

CloudflareはQuad9のBabak Farrokhiとともにこのドラフトを共同執筆した。実装は.ALインシデント時点で1.1.1.1にて稼働中である。これはDNSSECの障害モードをより透明にするための小さくとも意味のある一歩だ。