要約

  • RFC 9859 は、子ゾーンがDSYNCで通知先を見つけ、CDS、CDNSKEY、CSYNCの変化を親側へ早く知らせる方法を定める。
  • 発見、送信、応答確認は通信とタイミングの証跡であり、親側の検証、受理、親ゾーンへの反映を示す証跡ではない。

DNS委任の運用では、子が正しい情報を公開しても、親側の定期走査がそれを見つけるまで待たされることがある。RFC 9859 はその待ち時間を短くする。子側は公開されたDSYNCレコードから通知先を発見し、対象の変更を示すNOTIFYを送る。受信側は、通常ならタイマーで始まる確認を前倒しできる。ここで得られるのは速い着手であって、速い承認ではない。

この限界は仕様の中心に置かれている。通知は、受信者がもともと行う確認を早く始めさせるだけで、その確認の内容や安全性の判定を変えない。DSYNCにはRRタイプ、方式、ポート、対象名が入る。これは「どこへ知らせるか」を記録するもので、「子のデータが正しいか」「親が受け入れるか」「親ゾーンに何が掲載されたか」を記録するものではない。

親側には複数の役割があり得る。レジストリ、レジストラ、あるいは指定された別の事業者が、受信点または後段の判断を担う場合がある。RFC 9859 はその内部配置を規定しない。したがって、公開された宛先は配達を可能にしても、発信者に決定権を与えず、最終的な受理者の同意を証明もしない。経路情報を同意の証拠と読み替えることは、調整のための記録を権限の宣言に取り違えることになる。

NOTIFY応答も同じように限定して扱う必要がある。受信者は応答を返して直ちに調査を予定できる。一方、レート制限などの理由で処理しない場合にも、不要な再送を抑えるため応答を返せる。応答が示すのは送信側の再試行キューを閉じられる程度にメッセージを受け取ったことだけである。DSの検証、受理、公開が済んだという成功通知ではない。

責任を伴う判断はその後にある。RFC 9859 は、子側が公開前後の権威サーバー間で一貫した見え方を確保してから通知することを勧める。早すぎる通知は、親側が不整合な情報を見る原因になる。応答の後でも、継続性要件などにより非同期で処理が失敗し得る。DNSSECの初期導入では、RFC 9615 が親側の代理者に、権威サーバーからの取得、DNSSEC検証、RRsetの照合、エラー時の中止を求めている。RFC 8078 も、初回導入、ロールオーバー、非保護状態への復帰について親側の受理方針を残している。

運用記録は、この順序を潰してはならない。DSYNCの発見と検証状態、NOTIFY送信、通信応答、親側が実際に取得したデータ、検証と継続性の結果、受理または拒否の判断、親ゾーン公開、外部からの名前解決確認を別々に残すべきである。一つの「同期済み」表示にまとめれば、見栄えのよい通信履歴は残るが、誰が何を決めたかは消える。

Heng Lu のいう実行中の現実を優先する姿勢は、この場面で明快である。調整用の記録は、採用された現実を記述すべきで、まだ行われていない将来の判断を作り出すものではない。DSYNCは調整の記録であり、NOTIFYは時間を変える合図である。重要なのは、その後に責任ある側がどの規則で確認し、何を公開したかである。

RFC 9859 が保証するのは、子の公開から親側の検討開始までの間隔を短くできることだ。委任変更そのものを取得したことではない。この差を守ることが、迅速さと責任を同時に保つ条件になる。

出典