要約

  • DNSOP は 9 月 2 日、draft-farrokhi-dnsop-ede-nta-01 の作業部会採用募集を開始した。締切は 16 日で、現時点では個人 Internet-Draft のままであり、RFC でも採用済み文書でもない。
  • EDE 33 は、応答生成時に対象を覆う Negative Trust Anchor が有効だったことを示す。案は、NTA が応答内容へ実質的な影響を与えなかった場合にも送信を認める。
  • 効果を判断するには、EDE の発信元と区間保護を、NTA なしの同時点検証結果または明示的な「未測定」と結ぶ、限定的な別記録が要る。

採用前でも番号は存在する

DNSOP の募集が問うのは、NTA の応答内開示を扱う文書を作業部会が引き受けるかどうかである。期間は 9 月 2 日から 16 日まで。Datatracker の状態はまだ Call For Adoption By WG Issued で、01 版は Informational を予定する個人案だ。採用結果も RFC 出版も記録されていない。

一方、IANA の DNS Parametersには 33 が Negative Trust Anchor として載る。先行実装が別々の番号を選ぶ事態を避けるための調整である。番号の存在は、作業部会の結論、文章の確定、実装普及のいずれも意味しない。

文書の管理主体、識別子の割り当て、出版、導入は別々の状態だ。DNS のパケットでは一つの数値に見えるが、その背後の制度上の時計まで一つになるわけではない。

NTA は権威データではなく検証器を変える

RFC 7646 の NTA は、再帰リゾルバ内の局所設定である。指定名から下で DNSSEC 認証連鎖を止め、対象応答を未署名ゾーンのデータとして扱う。署名や委任を修復せず、リゾルバがゾーンの権威になることもない。

到達性を戻す代わりに認証を一時停止するため、導入は自動であってはならない。訓練された担当者が設定ミスと攻撃を見分け、意図的に壊した試験ドメインを除外し、ゾーン側への連絡を合理的に試みる。範囲は狭くし、通常検証を再試行する。自動失効を備え、期間は一週間を超えないことが推奨され、復旧後は速やかに削除して対象以下のキャッシュも消す。

この承認・期限・削除の記録は既存記事が扱っている。本稿はそれを複製せず、クライアントが一つの応答から得られる証拠だけを見る。

適用中という事実と結果への寄与

01 版では、一つ以上の EDE 33 は、応答生成時にカバーする NTA が有効だったことを意味する。情報は診断用で、AD ビットの処理を変えない。検証を行わない権威専用サーバが付けるものでもない。

NTA を設定した運用者は影響を受ける応答に送ることが推奨される。しかし案はさらに、NTA が有効な間は、内容に実質的な効果がなかった応答にも付けてよいとする。

同じ NTA の下で、一方の名前は通常検証なら Bogus となり、例外によって初めて利用可能になるかもしれない。別の名前は、例外を外しても Secure または Insecure として同じ結果を返すかもしれない。両方に 33 が付く。前者は結果変更、後者は環境表示だが、受信パケットだけでは区別できない。

これは透明性のために毎回二重検証を課さない設計でもある。EDE は軽量な観測を提供し、反実仮想の証明までは引き受けない。利用者側もその境界を守る必要がある。

追加情報にも権限の限界がある

EXTRA-TEXT には NTA の設定名、理由、参照先、予想期間を書ける。構造化形式では d が設定ドメイン、t が存続すると予想される時刻を示す。

いずれも任意である。d は適用範囲を狭めても、当該応答の変化を証明しない。t は予定であり、実際の削除証跡ではない。理由文は運用者の説明であって承認者の資格証明ではない。複数 NTA が該当すれば複数インスタンスを出せるが、候補が増えても因果は決まらない。

RFC 8914によれば、EDE は補助的で DNS の処理を変えてはならず、適切なトランザクションや通信路で保護されない限り固有の認証もない。フォワーダーは削除、転送、再生成を選べる。発信元を明記すべきなのは、クライアントから最後の送信者が診断の作成者に見えるためだ。

従って確認できるのは「応答したシステムが、その時点でこの応答を覆う NTA があったと述べた」ことまでだ。ゾーン障害、判断の正当性、結果への寄与、現在の継続は別証拠を要する。33 がないことも NTA 不在の証明にはならない。

デモ環境は自ら直ってしまった

採用スレッドには、証拠の時間性を示す場面がある。01 版は意図的に不正な子委任を置き、NTA と EDE を例示した。共著者 Joe Abley は 9 月 2 日の返信で、Cloudflare の既定自動化が委任を修復するかゾーンカットを除去し続け、オンラインの状態が当初の例に合わなくなったと説明した。作者側で直すとも述べた。

これは障害や制御失敗の証明ではない。文書版と実験用 DNS が異なる速度で変わることを示す。自動修復が反実仮想を消せば、後から EDE の存在だけを見ても通常検証の失敗を再現できない。

先の実装議論でも、実際の EDE 33 応答からは NTA が問い合わせ名にあるのか祖先にあるのか、複数あるのか、外しても検証できるのかが分からないと指摘された。限定された診断は、不完全だから偽なのではない。別の問いへの答えではないだけだ。

コードを太らせず効果記録を分ける

クライアントのアドレス、問い合わせ履歴、内部チケット、機微な障害情報を EXTRA-TEXT に載せるべきではない。足りない部分は運用側の NTA 効果記録 に分けられる。これは私の編集上の提案で、IETF や IANA の要件ではない。

サンプル応答やインシデント単位で、時刻と応答フィンガープリント、EDE を生成したリゾルバ／フォワーダーの役割、発信元、観測区間の保護、33 と d／t、AD 状態、隔離経路で NTA を外した同時点検証、または理由付きの「未測定」、データや結果の差、別管理の承認・失効記録への参照を結ぶ。

実ユーザの全問い合わせを二重処理する必要はない。安全な再現や抽出調査でよく、取れない反実仮想は取れないまま残す。公開時は効果分類の集計にし、危険な名前や利用者情報を守る。存在を原因へ昇格させないことが目的である。

Heng Lu の The Policy Mirrorにならえば、IANA の番号管理、IETF の文書状態、運用者の例外判断、通信路の観測は異なる権限と証拠を持つ。Running Code Primaryの原則では、最終的な効果は案の説明ではなく稼働する検証器の比較で確かめる。

EDE 33 は例外の存在を可視化する。その価値を守る最善の方法は、変化させたかどうかについて沈黙している点まで正確に読むことだ。

出典

  1. DNSOP 作業部会採用募集
  2. IETF Datatracker の現行記録
  3. DNS 応答における NTA 開示、01 版
  4. 文書履歴
  5. Joe Abley による例の状態説明
  6. 実装境界の議論
  7. RFC 7646 — DNSSEC Negative Trust Anchors
  8. RFC 8914 — Extended DNS Errors
  9. IANA DNS Parameters
  10. DNSOP 作業部会記録
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Running Code Primary