要約

  • ZONEMDは、正規化されたゾーン全体を一つのSOAシリアルに結び付ける。偶発的な破損検知を越えて出所を証明するには、DNSSECによる検証が必要である。
  • 一致が示すのは、受領したコピーが公開者の提示した対象と同一だということだ。レコードの判断が正しかったことや、失敗時の即時停止が最善であることまでは示さない。

変更担当者が本番用アドレスを保守用アドレスに取り違えたとする。権限は正しく、SOAシリアルも更新され、ZONEMDも正確に計算され、署名も有効だった。セカンダリは公開されたゾーンを一字違わず受け取る。それでもサービスは誤った宛先へ向かう。検証は失敗していない。検証より前の意思決定が失敗したのである。

RFC 8976 は、チャネルから独立してゾーン全体を検査する方法を定めた。ゾーンはAXFRやIXFRだけでなく、HTTP、アーカイブ、ポリシーフィードなどでも配布される。転送時の認証はセッション終了後のファイルに残らないことがある。ZONEMDはダイジェストをゾーン内に置き、後から同じ対象を検証できるようにする。

規定上意味を持つレコードはゾーン頂点のタイプ63で、SOAシリアル、照合方式、ハッシュアルゴリズム、ダイジェストを格納する。検証時にはZONEMDのシリアルとSOAが完全に一致しなければならない。名前だけではなく、特定版の内容に証明を結び付けるためだ。

SIMPLE方式は RFC 4034 のDNSSEC正規ワイヤ形式と順序を使う。コメント、空白、大文字小文字、ゾーンファイル上の並びは対象の同一性を左右しない。グルーレコードや隠蔽されたデータも含み、同一RRの重複は一回だけ数える。頂点の仮ZONEMDと、そのRRsetを覆うRRSIGは循環を避けるため除外する。頂点以外のZONEMDには、この仕様で検証上の意味はない。

IANAの現行レジストリ では、公開方式はSIMPLE 1、公開ハッシュはSHA-384の1とSHA-512の2である。SIMPLE/SHA-384は必須実装、SHA-512は推奨実装だ。移行中は異なる組を複数置けるが、受信側が対応しローカル方針で許可した一組の一致で成功し得る。古い組を残せば、その弱さも受け入れ経路として残る。

検証手順は単純な再計算ではない。まず、そのゾーンにDNSSECを期待すべきかをローカルのトラストアンカーと親の検証済みDSから判断する。存在すべきZONEMDがコピーにない場合は成功にできない。SOAとZONEMDの署名、組の重複、シリアル、方式、アルゴリズム、長さを確認し、全体を正規化して計算結果と比較する。失敗理由を個別に残すことが重要である。

未署名ゾーンでは、ゾーンを改変できる攻撃者がダイジェストも再計算できる。そこではZONEMDは破損や切断、コピー差を見つけるチェックサムであり、攻撃者に対する出所証明ではない。DNSSECを通して初めてSOA/ZONEMDの主張を受信側の信頼へ連結できる。その全体像と限界は RFC 4033 にある。DNSSECとZONEMDは代替関係ではない。

強い結果にも範囲がある。正しい公開者が間違ったMXを消し、過剰なRPZ規則を追加し、予定日前にアドレスを切り替えた場合、ZONEMDはその状態を正確に覆う。ハッシュ関数は変更申請、顧客合意、サービス台帳を読まない。従って一致は「公開された対象」を認証するのであって、「公開すべき対象」を審査するものではない。

製品の設定もこの違いを示す。Knot DNS はロード・更新時の zonemd-verify とSHA-384/SHA-512生成を分離し、いずれも既定では動作させない。大規模ゾーンで時間とCPUを要するとの注意もある。Unbound は検査、欠落拒否、許容モードを別々に持ち、許容時は失敗を記録してもゾーンを遮断しない。PowerDNS はファイルを明示的に検証するコマンドを提供する。実装対応と強制停止は同じ判断ではない。

RFC 8976自身が、完全性と可用性の緊張を認めている。破損した候補を利用前に止めれば耐障害性は上がる。一方、一つの欠落や実装不具合によって他の正常データも利用不能になり得る。比較結果だけでは、故意の改ざんと生成側のバグを区別できない。そのため、当初は警告として経験を蓄積し、後にエラーへ移す段階導入が示唆されている。

RFC 5936 のAXFRモデルには、候補と稼働状態を分ける原則がある。新しいデータを保存して検査し、成功後に原子的にロードする。失敗した候補は破棄し、以前から提供していた版は継続する。ZONEMDは候補検査を強化するが、最後に正常と分かった版の消去を命じない。

ただし旧版を無期限に使うことも安全ではない。最大経過時間、エスカレーション条件、例外承認者をゾーンごとに定める必要がある。ルートのローカルコピー、企業ドメイン、RPZフィードでは、古さによる損害が異なるからだ。

時間は暗号証拠にも作用する。公開者は対応するSOAとZONEMDを同時に出さなければならない。ZONEMDへの署名処理でSOAを再更新すれば、直前の結び付きが壊れる。またKSKロール後にDSやトラストアンカーが失われれば、有効期限内のRRSIGであっても過去の主張を検証できない場合がある。

SIMPLEは更新のたびにゾーン全体を計算する。RFC 8976は、計算時間が更新間隔や伝播時間に近づく大規模・高頻度更新ゾーンには不向きだとする。運用予算に収まらない厳格な検査は、遅延か緊急回避を生み、結局使われなくなる。

監査は、受領候補、正規対象、DNSSECの出所、意味検査、ローカル受け入れ、ロードされた版、実際の権威応答を分けるべきだ。Heng LuのRunning-Code Primacy、最小初期仕様とローカルな将来判断、現実の層という議論は、この分離を支える。共通規則は決定論的でよいが、失敗の結果は損失を負う運用者が明示的に決める。

RFC 8976の正誤表 には、付録の私用方式例でSHA-384表示が短すぎるという保留中の技術訂正がある。規範的な48オクテット要件は変わらない。権威ある文書の局所的誤りを記録すること自体が、証拠を層別化する実践である。

経営判断は「一致したか」では終わらない。どのシリアルを、どの信頼経路とアルゴリズムで検査し、誰が候補を隔離し、旧版をいつまで保持し、最終的にどの応答が観測されたのか。ここまで追跡して初めて、暗号学的完全性は運用上の証拠になる。