要約

  • RFC 9824では、存在しない名前への応答がヘッダーではNOERROR、Answerセクションは空、署名済みNSEC/NSEC3のタイプビットマップにはNXNAMEという形を取れる。認証された不存在の主張は本文にあり、DNSヘッダー自体は暗号学的に保護されない。
  • オプションのEDNS Compact Answers OK（CO）フラグはNXDOMAINを復元できるが、効力は隣接区間ごとに限られる。リゾルバーは証拠とCO能力をキャッシュで一緒に保持し、次の問い合わせ元に応じて表示を変える必要がある。
  • コンパクト回答は他のオンライン署名方式より証拠量と署名作業を減らす一方、積極的ネガティブキャッシュによる広域合成を失う。検証、表示、負荷、キャッシュ、アプリケーション結果には別々の証跡が要る。

ロールバックは設定値ではなく経路で証明する

冒頭は仮想的な運用場面であり、実在の障害ではない。重要なのは、制御面の設定、利用者向けのRCODE、署名済み証拠の実行経路が別物だという点である。三つを一つの「DNS正常」に畳むと、復旧宣言だけが先に走る。

RFC 9824はDNSSECにおけるCompact Denial of Existenceを規定する。通常の否定証明では、正確な名前が存在しないことに加え、ワイルドカードからも応答が合成されないことを示す。オンライン署名では、そのために最大二つの署名済みNSEC、または三つの署名済みNSEC3が必要になり得る。

コンパクト回答は論理形を変える。ワイルドカードに一致しない不存在名に対し、権威サーバーはNODATAに似た応答を作る。ヘッダーのRCODEはNOERROR、Answerセクションは空、QNAMEに一致する最小被覆NSECまたはNSEC3を一つだけ署名してAuthorityセクションに置く。証拠上は「名前は存在するが、問い合わせた種別のデータがない」と主張する。

RFC Editor情報とDatatrackerは、RFC 9824を2025年9月発行のProposed Standardとし、RFC 4034と4035を更新すると記録する。履歴、参照文献、被参照情報は公開された標準化の文脈を示すが、製品実装や運用採用を証明しない。

NXNAMEは「空」を署名された意味へ変える

空のAnswerセクションだけでは名前の不存在は決まらない。名前は存在しても問い合わせた種別を持たない場合がある。子孫名があるため存在する空の非終端名は、自身のRRsetを持たないことがある。このため、タイプビットマップが空または疎であるだけでは十分に区別できない。

RFC 9824は値128の合成Meta-TYPE NXNAMEを定義する。NSEC方式の不存在名ではタイプビットマップにRRSIG、NSEC、NXNAMEが入り、NSEC3方式ではNXNAMEだけが入る。空の非終端名にはNXNAMEがない。不存在は沈黙から推測されるのではなく、署名済みデータの明示的主張になる。

IANA DNS ParametersはNXNAME、COフラグ、EDE 30を登録する。コードポイントは相互運用可能な名称を与えるが、有効化、検証、方針、結果を証明しない。

NXNAMEは通常のゾーンデータでも問い合わせ対象でもない。コンパクト回答のNSEC/NSEC3タイプビットマップ以外に現れるべきではない。NXNAMEをQTYPEとして明示的に問い合わせるとサーバーはFORMERRを返し、任意でEDE 30 Invalid Query Typeを付けられる。リゾルバーはその問い合わせを上流へ転送せず、反復名前解決も行わない。RFC 8914がEDE一般を定義し、RFC 9824がこの用途を定める。

便利なヘッダー値より署名済み本文が強い

RFC 9824は、DNSヘッダーが暗号学的に保護されないためRCODEを認証できないと明記する。署名済み本文から状態を推論する方が安全である。

それでもRCODEはアプリケーションやセキュリティツールが読む重要な接点である。NOERRORだけを見たツールはNODATAと分類し、RRSIGとNXNAMEを検証した検証器は不存在と判断できる。両方を観測点付きで保存すべきであり、扱いやすいヘッダー欄に強い証拠を上書きさせてはならない。

RFC 4034はNSECやRRSIGを含むDNSSEC RRを定義し、RFC 4035は認証否定の処理を規定する。RFC 9824は動的なコンパクト証拠のために両者を更新する。RFC 9364はDNSSEC概説、RFC 9499はDNS用語を与える。どの文書も未検証のヘッダー断片を署名済み事実にはしない。

証跡には問い合わせ名と種別、DO/CO、受信RCODE、NSEC/NSEC3形、NXNAME、公開アルゴリズムと鍵ID、検証結果、ソフトウェア版、時刻、証拠のフィンガープリントを残す。秘密署名鍵は残さない。

COは証拠ではなく表示権限を運ぶ

RFC 9824は可能な場合にNXDOMAINを維持するよう求め、DNSSEC応答向けにEDNS Compact Answers OKを定義する。COを送るリゾルバーは、署名済みNXNAMEとNXDOMAINに復元されたRCODEの組合せを受け入れると表明する。両機能を実装する権威サーバーは応答にもCOを付け、NXDOMAINを返せる。

RFC 6891のEDNSは隣接区間ごとに作用する。リゾルバーは上流COをキャッシュデータに関連付ける。次のDNSSEC問い合わせ元がCOを送らなければ、NXNAME応答のRCODEをNOERRORへ戻す。

署名済み証拠は同一で、ローカル表示だけが変わる。キャッシュの保存形式でCOを失えば契約を再現できない。最後のRCODEだけでは、NXNAMEを検証したのか、相手の能力へ適応したのか、上流値を転送しただけか判別できない。

コンパクト化は負荷の所有者を変える

RFC 4470は最小被覆NSECとオンライン署名の先行仕様、RFC 5155はNSEC3である。RFC 9824は、より大きい動的証拠と比べて応答量と署名演算を減らし、ゾーン列挙も抑える。

一方、RFC 8020とRFC 8198が示すNXDOMAINやワイルドカードの合成は使えない。証拠が最小範囲しか語らないため、リゾルバーは広い名前集合の代わりに答える権限を得られない。疑似ランダムなサブドメイン問い合わせが権威署名器まで届きやすくなる。

オンライン署名では、インターネットから到達可能な権威基盤が秘密署名能力へアクセスし、応答ごとに計算する。コンパクト回答は相対的な作業を減らすが、事前計算済み署名と同じではない。RFC 9824は計算資源へのDoSリスクを認め、導入理由が弱い場合に従来方式を選べるとしている。

アプリケーション結果は別に観測する

AAAA問い合わせへのNODATA形応答を受けたアドレス検索が、同名のA問い合わせを追加することがある。通常のNXDOMAINなら抑止できた可能性がある。スタブがDNSSECを要求しない、ツールがタイプビットマップを読まない、リゾルバーが下流COに合わせて表示を変えるという経路もある。

Running-Code Primacyが求めるのは、生成、署名、検証、NXNAME解釈、キャッシュ、CO判断、RCODE、追加問い合わせ、アプリケーション結果を実行順に追うことだ。Reality LayersはNOERRORを存在証明にせず、正しい署名をアプリケーション成功にも昇格させない。

情報源

  1. IETF Datatracker：RFC 9824
  2. RFC 9824履歴
  3. RFC 9824被参照情報
  4. RFC 9824参照文献
  5. Heng Lu：Minimum Initial Specification
  6. Heng Lu：Reality Layers
  7. Heng Lu：Running-Code Primacy
  8. IANA DNS Parameters
  9. RFC 9824 errata
  10. RFC Editor情報
  11. RFC 4034
  12. RFC 4035
  13. RFC 4470
  14. RFC 5155
  15. RFC 6891
  16. RFC 8020
  17. RFC 8198
  18. RFC 8914
  19. RFC 9364
  20. RFC 9499
  21. RFC 9824