要約

  • EDE 33 が示すのは、リゾルバーが応答を生成した時点で対象を覆う negative trust anchor が有効だったという事実だけであり、その例外が応答を変えたことやデータが真正であることではない。
  • 経営判断では、設定、適用範囲、開示、検証、通信路、アプリケーション結果という六つの記録を分け、診断コードを安全判定へ昇格させないことが重要だ。

見えなかった例外に証人が付く

DNSSEC 検証失敗は難しい選択を生む。保護を維持すれば、単なる署名設定ミスのドメインへ利用者が到達できないかもしれない。検証を止めればアクセスは戻り得るが、リゾルバーは DNSSEC の中核的な確認を意図的に外す。RFC 7646 は、この妥協を negative trust anchor（NTA）として定義した。検証型再帰リゾルバーが限定した名前に置く、ローカルかつ一時的な例外である。

従来、応答の受信者からこの例外は見えにくかった。運用者はウェブサイトで NTA 一覧を公開できたが、DNS メッセージ自体には「有効な例外の下で生成された応答だ」と示す専用の印がなかった。DNSOP working group の新しい草案 Disclosure of Negative Trust Anchors in DNS Responses は、Extended DNS Error code 33 “Negative Trust Anchor” を提案する。revision 00 は 2026 年 9 月 23 日付の work in progress であり、RFC でも最終合意でもない。

コードが表す事実は狭い。EDE 33 を含む応答は、それを覆う NTA が有効な状態で生成された。送信主体は NTA を設定した再帰リゾルバーであり、検証を行わない authoritative-only server が付けるべきではない。NTA を適用した運用者は影響対象の応答にコードを返し、DNSSEC 検証されていない可能性を利用者やアプリケーションに知らせるべきだ。

可観測性は確実に増す。しかし、最も難しい問いはその先に残る。

開示と認証は別物

草案本文 は EDE 33 を診断情報と位置づける。クライアントはコードの存在だけで protocol processing を変えてはならず、Authenticated Data bit の扱いも変わらない。これは RFC 8914 の設計そのものだ。EDE は応答へ文脈を加えるが、RCODE を置き換えず、新しい命令チャネルにもならない。

さらに、コードは因果関係を証明しない。NTA が有効なら、例外が応答内容へ実質的な影響を与えなかった場合でも、リゾルバーは EDE 33 を付けられる。「NTA がなければこの query は検証失敗したか」という反実仮想には、validator log または例外を外した隔離 replay が必要である。

コードは DNS data も認証しない。NTA は、通常の検証を限定範囲で止めるために存在する。RFC 4035 が定める validator の処理と security state を、EDE 33 が再構築することはない。示すのは、その停止判断が有効だったことだけだ。

開示自体にも固有の署名はない。草案は、on-path attacker が EDE を追加、削除、変更できると警告する。TSIG、SIG(0)、DNS over TLS、DNS over HTTPS は関係する message や hop を保護できるが、完全な EDE が届いても、識別されたリゾルバーが何を報告したかを示すにすぎない。設定ミスが善意だったこと、調査が十分だったこと、返された address が意図した service へ通じることは証明しない。

一つの青信号ではなく、六つの記録

第一は設定記録である。NTA の正確な owner name、設定した運用者、incident evidence、承認者、開始時刻、予定失効時刻を残す。RFC 7646 は期間制限を求める。広すぎる例外や無期限の例外は、仕組み自体の失敗だ。

第二は適用範囲記録である。この QNAME と応答が当時その NTA に覆われていたことを示す。ancestor の NTA が subordinate query に及ぶことも、複数 NTA が同時適用されることもある。見えている answer だけから範囲を再構成してはならない。

第三は開示記録である。raw response、resolver identity、観測時刻、すべての EDE 33 instance を保存する。複数 instance の場合は各 EXTRA-TEXT が必須となる。structured field d は NTA 設定 domain、t は想定継続時刻を表せるが、t は保証された removal event ではない。

第四は検証記録である。AD/CD flag、validator log、例外を外した controlled result を分ける。EDE は AD processing を変えず、通常 validator の判断を単独では説明しない。

第五は通信路記録である。client と resolver の間で EDE の除去や改変が防がれたかを確認する。保護された範囲で message provenance は得られても、運用判断が暗号学的事実になるわけではない。

第六はアプリケーション記録である。stub resolver と application が実際に受信、表示、利用したものを残す。DNS response が届いても、application は失敗し、別 address を選び、content を拒み、誤った endpoint へ接続し得る。名前解決と service outcome は別の出来事だ。

六つを一文に畳むと、「resolver が NTA と言ったから応答は安全だ」という危険な結論になる。正確なのは「この resolver は、この時刻にこの応答を NTA が覆っていたと報告した」までである。

metadata にも privacy boundary がある

EDE 33 は accountability を高める一方、incident detail を漏らし得る。EXTRA-TEXT には name、reason、reference、expected duration を入れられるが、人が読める簡潔さを保ち、private または sensitive information を避けるべきだ。helpdesk ticket、customer identifier、internal hostname、未公表の response plan は DNS option に入れたから安全になるのではない。

d と t は machine visibility を上げるが、証拠境界を変えない。d は運用者が主張する設定点であって domain ownership の証明ではない。t は見込みであって、自動削除や期限内 review の証明ではない。良い metadata は drift を見つけやすくするだけで、drift を消しはしない。

最小の共通信号であり、中央許可証ではない

IETF が担うべきなのは、ローカル例外を見えるようにする共通 code の定義までだ。NTA を置く判断は incident と利用者と security consequence に接する resolver operator が負う。domain operator は authoritative DNSSEC を直す責任を持ち続ける。client は diagnostics の見せ方を選べるが、code を「この data を信頼せよ」という命令へ変えてはならない。

これは Heng Lu の最小初期仕様、ローカルな将来判断、自発的採用という分業に合う。共通層は最小の interoperable fact を運び、例外を裁く世界的 tribunal にはならない。authority と belief の区別も同じだ。標準 label は誰が何を述べたかを示しても、その内容を真実にはしない。Running-Code Primacy に従えば、revision 00 の公開だけで deployment を主張できない。packet、version、forwarding path、client behavior、removal evidence が必要だ。

草案の状態と限界

revision 00 の public resolver 例は有用な demonstration だが、support の census ではない。forwarder は EDE を捨てたり作り直したりでき、UDP size pressure で supplemental option が落ちることもある。stub resolver や application が表示しない場合もある。今後の revision で semantics や structured field が変わる可能性もある。

それでも、提案は evidence surface を改善する。見えなかった validation weakening に標準化された証人を置くからだ。leadership の仕事は、その証人を判決へ昇格させないことである。

情報源