要約

  • draft-hardaker-dnsop-nothing-new-00 は、TC に NN 信号と 16 ビット識別子を持つ LARGE RR を組み合わせ、変化していないように見える大きな RRset の再取得を避ける案を示す。
  • これは個人提出の Internet-Draft で、本文自身が未完成かつ実装不能と明記している。Datatracker はストリームも目標 RFC 状態も示さず、文書ヘッダだけが Standards Track とする。
  • TC は応答が切り詰められたことを示す。NN は応答した一つの権威の比較結果である。どちらも、TCP が使えないこと、完全取得が新情報を含まないこと、全権威が収束したことを証明しない。
  • 安全な運用では、手掛かりの由来、LARGE とキャッシュ RRset の系譜、RRSIG の有効期間、権威世代、再取得判断、クライアント結果を分離する。

切り詰めは「十分」の同義語ではない

大きな DNS 応答が利用可能な UDP サイズに収まらなければ、TC が立ち、リゾルバは通常、信頼できるトランスポートで完全な応答を求める。将来の耐量子鍵や署名はサイズ圧力を高め得るが、revision 00 は導入状況や削減量を測定していない。

提案は、同じ大きなデータをリゾルバが既に持つなら再送を省く。権威側は TC と一緒に NN を返し、対象レコードが最近変わっていないと知らせる。LARGE の短い識別子がキャッシュ側の値と一致すれば、完全取得をやめられる。

ここで TC が証明するのは、現在の応答が切り詰められたことだけである。TCP が故障しているとも、完全な RRset が同一とも、取得費用が便益を上回るとも言っていない。RFC 7766 は完全な DNS 実装に TCP 対応を求める。取得を省くのはリゾルバの政策判断である。

したがってログの動詞は「最新と確認」ではなく「政策 P により再取得を抑止」でなければならない。入力と代替経路が残れば、後でその判断を検証できる。

小さな信号は取得する証拠を選別する

この仕組みでは、小さな手掛かりを評価した後で、大きな対象を取りに行くか決める。つまり手掛かりは、自分を反証し得る証拠の取得を制御する。

それ自体は不正ではない。キャッシュや条件付き取得は同じ効率化を広く使う。ただし手掛かりの発話者、対象、時刻、認証、比較基準を保存しなければならない。

必要な記録には、問い合わせ名・型・クラス、応答権威、ビュー、TC/NN、LARGE 識別子、署名状態、生成方式、キャッシュ RRset の完全ハッシュ、RRSIG 期間が含まれる。match=true だけでは、何と何が一致したか再構成できない。

運用画面が「取得しなかった」を「fresh」に変換すると、判断が観測に化ける。これは表示上の省略ではなく、証拠を持つ主体の変更である。

一つの権威応答は集合の投票ではない

プライマリ、セカンダリ、anycast インスタンスは、転送、ロード、部分障害の間に異なる世代を返し得る。NN は到達したサーバが自分の世代をどう比較したかを示す。権威集合全体の収束証明ではない。

キャッシュとサーバ A が世代 1 を持ち、サーバ B が世代 2 に移った場合、A の NN と識別子一致は正直である。それでも運用者の現在意図や集合収束は証明できない。

重要な変更では分母が必要だ。どの権威を観測対象とし、どの場所から、何件一致すれば古い経路を外せるのかを決める。anycast アドレス一つは、その背後の全インスタンス一覧ではない。

通常の問い合わせで一観測を受け入れる政策もあり得る。その場合はリスクを明記する。鍵ロールオーバー、委任変更、復旧では完全取得や複数観測を必須にできる。プロトコルの便利さがリスク分類を消してはならない。

16 ビットには系譜が要る

LARGE 識別子は 16 ビットで、表現するデータの署名寿命内に限って一意でなければならない。全世界・全期間の版番号ではない。

草案はハッシュ、カウンタ、時刻、データ由来値を例示する。それぞれ契約が違う。短縮ハッシュには衝突、カウンタには永続化と多ノード協調、時刻には解像度と再起動規則、内容由来値には正規化が必要である。

同じ短値が同じ大きなオブジェクトを意味するのは、名前、型、クラス、ビュー、生成方式、非再利用期間が同じときだけだ。設定復元やカウンタ初期化、キャッシュの誤結合は別物を同じ値にできる。

短値を完全 RRset ハッシュ、発行権威、生成プロファイル、署名期間、キャッシュ世代に結び付けるべきである。短値は転送効率を担い、完全ハッシュは監査を担う。

SOA serial は別の対象を数える

revision 00 は SOA serial の安易な流用を勧めない。動的ゾーンでは SOA が頻繁に進んでも、大きな DNSKEY RRset は変わらないことがある。ゾーン版と RRset 版は同じ質問ではない。

一つの便利な番号ですべてを代表すると、番号の発行者が「どの変化を変化と数えるか」を支配する。RRset 単位の判断には RRset 単位の証拠が必要である。

split view も同じ問題を持つ。異なるクライアントに異なるデータが正しい場合、識別子はビュー内でのみ意味を持つ。ビューを失った集計は、偽の衝突か偽の連続性を作る。

有効な RRSIG は現在意図ではない

DNSSEC は特定 RRset を特定の鍵連鎖と有効期間に結び付ける。未期限切れの RRSIG はその暗号学的事実を示すが、運用者が置換を決めていないことや、全権威が同じ世代を持つことまでは示さない。

旧世代がまだ検証可能な間に、新世代が一部で公開されることはある。signature_valid を current に変えると、受容可能性と最新性が混同される。

さらに草案は、LARGE の署名が応答に入れば添付を必須とし、入らなければ未署名 LARGE の送信を推奨する。未認証の小信号が、署名済み大データを取らない判断に影響し得る。

セキュリティ節は、中間者が信号を偽造できるならパケットを落として stale 利用を誘発する力も既にあると論じる。これは追加攻撃能力の比較であり、信号の認証ではない。タイムアウトより早く stale 経路に入る影響も別に評価すべきである。

stale と current を分ける

RFC 8767 は、更新に失敗した際に有界な規則で古いデータを提供する。継続性のための明示的契約であり、古いデータを最新と呼ぶ許可ではない。

タイムアウトと NN は同じキャッシュ bytes に至っても、証拠が違う。前者は更新失敗、後者は一権威の「更新不要」主張である。警告、エスカレーション、信頼度を同一にしてはならない。

状態は、TTL 内、署名内、認証 NN 後維持、未認証 NN 後維持、更新失敗後 stale、完全再取得に分ける。単一の cache hit 率では事故原因を追えない。

アプリ結果も別層である。古い DNS でサービスが動くことも、正しい最新 DNS で別依存が失敗することもある。サービス成功は freshness の証明ではない。

文書の存在も導入証明ではない

証拠凍結時、Datatracker は revision 00 を active individual Internet-Draft とし、IETF の承認や正式地位がないと明示していた。ストリーム、担当 AD、telechat、目標 RFC 状態はなく、文書ヘッダだけが Standards Track と記した。

本文は「非常に作業途中」「完全な仕様ではない」「現時点で実装不能」と述べる。IANA は TBD、DNSSEC には未記述の案があり、形式・配置・リゾルバから親への信号も議論段階である。

よって最終割当、実装、相互運用、導入、PQC 利用、測定効果、事故を主張できない。分析できるのは、将来この最適化が成熟するなら守るべき証拠境界である。

取得を省くなら判断を残す

証拠グラフは問い合わせとキャッシュ世代から始まり、権威・ビュー、TC/NN、LARGE、認証、生成プロファイルを追加する。比較ノードが短値を完全ハッシュと署名窓に結ぶ。政策ノードが再取得を省いた理由を記す。

TCP 結果、キャッシュ採用、クライアント応答、アプリ観測は後続ノードであり、前の意味を書き換えない。

説明可能な文はこうなる。「権威 X が時刻 T に NN を返し、識別子 Y がキャッシュ RRset Z と一致し、Z の署名は E まで有効だったため、政策 P が一回の再取得を省いた」。これは「DNS は最新だった」より狭く、はるかに検証しやすい。

小さな信号で大きな転送を減らすことは合理的である。小さな信号が再観測を止めたという理由だけで、現実が変わっていない証明に昇格してはならない。

出典