要約

  • RFC 8976はゾーン頂点のZONEMDレコードを定義し、受信側が完全なゾーンのダイジェストを再計算して、転送方法に依存せず公開値と比較できるようにする。
  • DNSSECで認証されたZONEMDはゾーン全体の完全性と発行元の真正性を確認できるが、DNSSECがなければ意図しない変更を検出するチェックサムにとどまる。

分析

AXFRはゾーン全体を、IXFRは差分を配送する。ゾーンファイルはHTTPなどDNS以外の経路でも配布できる。しかし、いずれの配送手段も、処理が成功しただけでは最終的なレコード集合が公開側の意図と一致することを証明しない。

ZONEMDはRRタイプ63であり、ダイジェストをSOAシリアル、照合方式、ハッシュアルゴリズムに結び付ける。受信側は自分のコピーから値を再計算する。RFC 8976では、ゾーン頂点以外のZONEMDレコードを検証に使用してはならない。

SIMPLE方式は、レコードを正規化されたワイヤ形式と順序で処理する。定められた規則に従ってゾーンデータを含める一方、計算時の仮置きZONEMDレコードと、完成後のZONEMD RRsetを覆うRRSIGは除外する。対応するSOAシリアルとZONEMDは同時に公開されなければならない。

IANAの登録値はSIMPLEが方式1、SHA-384がアルゴリズム1、SHA-512がアルゴリズム2である。RFC 8976はSIMPLE実装にSHA-384の対応を求め、SHA-512も定義している。複数の方式・アルゴリズムの組は移行に役立つが、計算と運用の複雑さも増す。

ダイジェスト不一致が示すのは「状態が一致しない」という事実であり、原因ではない。不完全な転送、古いシリアル、正規化入力の差、署名順序の誤り、意図しない変更などを切り分ける必要がある。受信側はコピーを隔離し、双方の計算結果を保存し、公開側の状態と照合してからサービスへ昇格させるべきである。

適用限界も明記されている。SIMPLEは更新ごとにゾーン全体を再計算するため、RFC 8976は大規模で頻繁に変化するゾーンには現行仕様のままでは実用的でないとする。将来の方式を追加できる拡張性はあるが、この資料群は特定事業者の導入状況、普遍的な性能コスト、事故防止実績を示していない。

情報源