要約

  • ZONEVERSION は、ある権威応答を生成したゾーン版を同じ応答内で示し、後から別の SOA を引く場合の時間差を避ける。
  • 値が証明する範囲は観測した一応答に限られる。ゾーンの内容ハッシュでも、全ノードの収束証明でもなく、EDNS 値は RRSIG の対象外である。

障害対応の始まりを、エラーではなく成功応答に置いてみる。異なる二地点から同じ anycast アドレスへ、同じ名前を直接問い合わせる。どちらも NOERROR だが、一方は新しいアドレス、もう一方は古いアドレスを返した。ZONEVERSION の SOA-SERIAL はそれぞれ 4120 と 4119 だった。

ここで数秒後に SOA を別途問い合わせても、対応関係は戻らない。経路が変わり、両方の後続問い合わせが更新済み拠点へ届けば、記録には 4120 しか残らない。古い答えを実際に生成した版が 4119 だったという証拠は消える。

これは説明用の場面であり、実在の障害や製品対応状況を示すものではない。RFC 9660 の利点は、答えと版を同時に返す点にある。同時に、4119 という値だけでは原因を特定できず、4120 だけでは内容の正しさを証明できない。

要求は版を指定しない

問い合わせ側は OPT 擬似 RR に EDNS オプションコード 19 を置く。要求の OPTION-LENGTH は 0 で、データはない。「4120 を使え」と命令するのではなく、「この応答を作ったゾーン版を示せるなら示してほしい」と尋ねる。

長さが 0 でない、または ZONEVERSION が複数ある要求は不正である。実装した権威サーバーは FORMERR を返す。この結果をゾーン障害に読み替えてはならない。調査者はまず、プローブが送った生のバイト列を再現できる必要がある。

正しい要求でも応答は任意である。サーバーはオプションを理解し、関係する包囲ゾーンに対して権威を持ち、要求に応じる判断をして初めて値を返す。値がないことは、今回の対応付けが得られなかったという意味にすぎない。

また、この情報は hop-by-hop である。フォワーダーが上流の値を無条件にコピーすれば、誰がどの答えを生成したかという関係が壊れる。

LABELCOUNT が版の属するゾーンを決める

応答データは 1 オクテットの LABELCOUNT、1 オクテットの TYPE、TYPE ごとの VERSION から成る。LABELCOUNT は元の QNAME の右端からラベルを数えて包囲ゾーンを示す。0 はルートである。

host.branch.example なら 2 は branch.example、1 は example を示す。QNAME のラベル数を超えることはできない。「serial 4120」だけを抽出し、QNAME とカウントを捨てれば、その値がどのゾーンに属したか分からなくなる。

親ゾーンが生成する下位委任の referral、権威的な NXDOMAIN や NODATA、関係するゾーンを識別できる一部の SERVFAIL にも付けられる。複数ゾーンや複数 TYPE を返せるが、同じ TYPE と LABELCOUNT の組には一値までである。

SOA-SERIAL を普通の整数として扱わない

TYPE 0 の SOA-SERIAL が、RFC 9660 で定義された公開 TYPE である。VERSION は対象ゾーンの SOA SERIAL 4 オクテットを写し、応答オプション全体の長さは 6 になる。

Serial はゾーン内の値であり、世界共通の世代番号ではない。RFC 1982 の 32 ビット循環算術に従うため、折り返し後は数値の小さい方が新しい場合がある。組によっては順序自体が未定義になる。単純な整数比較は正常な折り返しを巻き戻しと誤認する。

さらに serial はダイジェストではない。運用ミスで異なる内容に同じ値を付けることもできる。同じ版の応答が条件や方針により異なる場合もある。RRset、各セクション、フラグ、TTL、DNSSEC 検証結果をトークンと一緒に比較すべきである。

ゾーン全体の内容を検証する問いには RFC 8976 の ZONEMD がある。ZONEVERSION は一応答の版を結び、ZONEMD は全体のダイジェストを検証する。役割を交換してはならない。

Anycast の一回答は全体を代表しない

同じ anycast アドレスでも、観測地点や時刻により別のサービス拠点へ届く。一回の成功は、その経路がその瞬間に見た状態だけを示す。

NS 名、アドレス、anycast プレフィックス、配信コホート、測定地点を先に列挙する。再帰を無効にした直接問い合わせで、送受信アドレス、トランスポート、時刻、QNAME、RCODE、AA、応答バイト、TTL、オプション、検証結果を残す。同じ問い合わせを繰り返して初めて、一時的な経路変化と継続する拠点差を分けられる。

NSID はインスタンスを見分ける補助になるが、意味と一意性は運用者が決める。存在するだけで認証されるわけではなく、エンドポイントや測定地点の代わりにはならない。

三地点が継続して 4120 と同じ応答を返し、第四地点が 4119 と古い応答を返すなら、測定範囲内の差を主張できる。原因を言うには、転送 journal、署名生成、ロード状態、経路と拠点の対応が必要だ。

DNSSEC は ZONEVERSION を署名しない

DNSSEC は署名対象 RRset の出所と完全性を検証できる。しかし ZONEVERSION の EDNS バイトは RRSIG の対象外である。保護されていない経路では、署名済み回答が検証に成功したまま、オプションだけを変更または削除できる。

「RRset が検証済み」と「応答と版の組が保護された」は別々に記録する。重要な診断では、認証・暗号化されたトランスポート、TSIG、SIG(0) を利用し、相手または鍵と検証結果を残す。それでもゾーン内容や全体収束の正しさまでは保証しない。

OPT はゾーンデータではない。ZONEVERSION を通常 RR のようにキャッシュ、転送、再利用して別の応答に貼り付けることはできない。

出典