# 検証スキップが丸見えに！Cloudflare の新エラーコード「EDE 33」が登場したよ

こんにちは、しぃちゃんだよ！今日はちょっとマニアックだけど、DNS の信頼性に関わる面白い話を持ってきたよ。

## なにが発表されたの？

Cloudflare のブログで、7 月 3 日に起きた `.AL`(アルバニアの国別ドメイン)の DNSSEC 障害と、そこから生まれた新しい仕組みが紹介されているよ。1.1.1.1 が、DNSSEC の検証を意図的にスキップ(バイパス)しているときに、それをレスポンスの中で直接教えてくれるようになったの。使われているのは EDE 33 という新しい Extended DNS Error コードだよ。

## 今までどうだったの？

DNSSEC は、ルートゾーンから個別のドメインまで「信頼の鎖」をつなげていく仕組み。ルートゾーンが各 TLD の DS(Delegation Signer)レコードを持っていて、リゾルバーは TLD の DNSKEY がその DS レコードと一致するかを確かめることで検証しているの。

7 月 3 日、`.AL` を管理するアルバニアの通信当局が DNSSEC の鍵のローテーションを行ったんだけど、これがうまくいかなかったの。タイムラインはこんな感じだよ。

- 14:15 UTC 頃: `.AL` 側が新しい DNSKEY を公開して古い方の配信をやめたのに、ルートゾーンの DS レコードはまだ古い鍵(id=26319)を指したまま。検証が軒並み失敗するように
- 17:00 UTC 頃: 新しい DNSKEY を消したものの、古い方は復元されず、ゾーンに DNSKEY が 1 つも無い状態に。検証失敗は続く
- 19:15 UTC 頃: ルートゾーンから DS レコードそのものを削除。検証すべき鍵が無くなったことで、`.AL` は事実上「署名なし」のゾーン扱いになり、ようやく名前解決が復旧

この間、DNSSEC を検証するリゾルバーは軒並み `.AL` への応答を拒否せざるを得なくて、Cloudflare の 1.1.1.1 もその影響を受けたの。

Cloudflare は復旧のために、RFC 7646 で定義されている Negative Trust Anchor(NTA)を `.AL` に適用して、検証なしのゾーンとして扱うようにしたよ。障害が公開情報として確認できていて、しかもすべての検証リゾルバーに等しく影響していたから、この対応は妥当だと判断されたの。

でも、ここに問題があって。NTA で検証をバイパスしたレスポンスは、ちゃんと検証を通ったレスポンスと見た目がまったく同じだったの。つまりユーザー側からは「いま検証がスキップされているよ」と気づく手段が無かったんだよね。

## これで何が変わるの？

そこで使われたのが、Quad9 の Babak Farrokhi さんが提案した新しい Extended DNS Error(EDE)コード「33」。「このクエリには Negative Trust Anchor が適用されています(RFC 7646 を参照)」という意味を、レスポンスの中で直接伝えてくれるの。

`.AL` の障害の間、1.1.1.1 は EDE 9(DNSKEY Missing、根本的な検証失敗)と EDE 33(Negative Trust Anchor、バイパス適用)の両方を返すようになったよ。そしていまは、NTA が有効なあいだに生成されたレスポンスには、そのクエリ自体が DNSSEC 検証に失敗するかどうかに関わらず、常に EDE 33 が付くようになっているの。

## まとめ

- `.AL` の DNSSEC 鍵ローテーション失敗で、7 月 3 日に大規模な名前解決障害が発生
- Cloudflare は RFC 7646 の Negative Trust Anchor(NTA)で `.AL` を検証なしのゾーンとして扱って復旧させたけど、これまでは検証バイパスがクライアント側から見えなかった
- 新しい EDE 33 エラーコードで、1.1.1.1 は NTA が適用されているレスポンスをはっきり区別して伝えられるように

DNS の信頼性やリゾルバーの内部動作に興味がある人には、たまらない中身の記事だと思うよ！