要約

  • SOAシリアルは時刻ではない。ゾーンのコピーを32ビットの循環空間に置き、各セカンダリが相対的な順序を自分で計算するための値である。
  • 通常の整数比較は折り返しで失敗する。RFC 1982では最大値の次の0を新しいと判断できる一方、ちょうど半周離れた値には順序を定義しない。
  • 規則が働くのは、生きているコピーがEXPIREの期間内に半周の窓へ収まる場合だけだ。版の順序は、内容の正しさ、編集権限、所有権、全サーバーの収束を証明しない。

最大値の次に来るゼロ

あるセカンダリが4,294,967,295を持ち、プライマリが0を示したとする。数値の大きさだけで比べれば、セカンダリの方が新しく見える。SOAシリアル演算では、0を次の版として扱える。

32ビットの番号を長く使えば、いつか値を再利用する。最大値で停止する設計なら、ゾーンの更新もそこで停止するか、別の版制度へ移行しなければならない。折り返し自体は避けるべき事故ではなく、有限空間を継続利用する条件だった。

難しいのは、円になった後の進行方向である。DNSは中央の時計や「最新版」を宣言する機関を置かなかった。同じ二つの値を見た実装が同じ答えを出す、小さな計算規則を共有した。

1987年仕様に残った空白

RFC 1034は、プライマリで変更を調整し、セカンダリがSOAを定期確認するモデルを定めた。変更のたびにSERIALを進め、プライマリが新しければゾーンを取得する。REFRESH、RETRY、EXPIREは通常確認、再試行、そして新鮮さを確認できないコピーが権威を降りる期限を示す。

RFC 1035はSERIALを符号なし32ビット版番号とし、転送でその値を保存すると定義した。値は折り返し、シーケンス空間演算で比較すると書かれた。

しかし、DNSで必要な一般比較は示されなかった。輸送プロトコルの番号から直感は借りられても、境界の全組み合わせについて実装が同じ結論を出す保証はない。ゼロ付近で、同じSOAを見た二台が逆の版を採用し得た。

数行で書ける比較が、どの公開状態を置き換えるか決める。定義の薄さと影響の大きさが釣り合っていなかった。

半周だけは決めない

1996年8月のRFC 1982は、その不足を補った。DNSの値は0から4,294,967,295まで。加算は2^32を法として循環するが、一度に定義される最大増分は2^31−1である。

二つの異なる値が半周未満なら、短い前進方向にある方を新しいとする。4,294,967,294の後に3が来てもよい。十進表記の大小は、時間の前後を表さない。

距離がちょうど2^31なら、左右の道は同じ長さになる。片方を恣意的に選ぶと、両者に同じ数を足した際に順序が反転しかねない。RFCはそこで大小を定義しない。等しくはないが、どちらも大きくも小さくもない。

これは欠陥を放置したのではない。観測値だけでは決められない場所に、偽の確信を置かなかった。運用は有効な版をその地点へ連れて行かない責任を負う。

EXPIREが円を秩序に変える

古いコピーが永遠に残れば、プライマリはいつか半周以上先へ進む。RFC 1982は、一つのSOA EXPIRE期間内に、複数回の合計でも2,147,483,647を超えてシリアルを進めないよう求める。

孤立したセカンダリがその間ずっと古い値を保ち、半周後に戻れば、比較上は古い側が新しく見える可能性がある。計算式の誤りではない。システムが計算式の前提を破った結果である。

共通時計を使わない代わりに、更新速度とコピーの寿命を結び付けた。セカンダリは時刻に同意する必要はないが、EXPIREまでプライマリを確認できなければ権威回答を止めなければならない。

ローカル検証は中央依存を減らす。それでも、検証可能な範囲を保つ運用責任までは消さない。

高すぎる番号は削除できない

自然な折り返しより現実的なのは、誤って大きすぎる値を公開する事故だ。正しいと思う小さな値へ書き戻しても、すでに大きな値を見たセカンダリはそれを古い版として無視する。

RFC 2182は単純な減算を禁じ、定義された前進増分で目的の領域まで進む方法を説明する。各段階で全セカンダリが追随したことを確認してから次へ進む。

プライマリのファイルを書き換える権限と、分散した観測を消す能力は同じではない。いったん受信側が判断に使った証拠は、送信側の後悔では巻き戻らない。

したがって復旧はローカルな「元に戻す」作業ではなく、すべての現存状態から検証可能な新しい経路を作る作業になる。

日付の形をしても時計ではない

RFC 1912は、小数表記が予想外の32ビット値へ変換される問題を指摘し、YYYYMMDDnn形式を勧めた。人間には変更日とその日の版数が読める。

だが、ネットワーク上では一個の整数にすぎない。セカンダリはカレンダー、タイムゾーン、編集者、承認記録を検査しない。誤った時計でも未来の日付を作れるし、単純な連番でも規則上は正しい。

可読な形式は運用上の便宜であり、共通の真実ではない。日付らしさを時刻証明へ昇格させれば、薄い相互運用層に不要な権威を持ち込む。

NOTIFYとIXFRが参照する位置

RFC 1996のNOTIFYは、セカンダリに早く確認させる。受信側はSOAを問い合わせ、自分でシリアルを比較する。通知は新版の順序を確定せず、ゾーンを書き換えない。

RFC 1995のIXFRでは、クライアントが持つシリアルが差分の出発点になる。サーバーに履歴があれば削除と追加の列を返し、なければ全体転送へ戻れる。

番号が述べるのは「このコピーは位置Xにある」ということだけだ。差分の内容、転送の完全性、データの正しさ、公開の決定は別の証拠と処理を必要とする。

誰にも尋ねず共有できる順序

RFC 1982は、日々の版判断を全実装が再現できるローカル計算にした。ゾーンの所有者、運営国、契約関係、編集時刻を知らなくても比較できる。

その狭さが強みである。YがXの次だと証明しても、Yの内容が正しいとは言わない。完全に整ったシリアル列の中で、誤ったMXやAレコードを配ることもできる。

共通層は、相互運用に不可欠で、各参加者が自分で検証できる問いだけを扱えばよい。半周地点で「分からない」と明示した設計は、答えを増やすより権力を限定することを選んだ。

情報源と証拠の限界

RFC 1034とRFC 1035が原型を示し、RFC 1912が運用上の誤りと日付形式を記録する。RFC 1982が演算を定義し、RFC 2182がセカンダリ運用と復旧を説明する。RFC 1995とRFC 1996はIXFRとNOTIFYによる利用を示す。

これらは世界共通の導入日や、すべての実装がゼロを正しく扱った証拠を与えない。中央時計ではなくローカルな決定規則を置いたという評価は、仕様からの構造的推論である。シリアルは所有権、編集者の身元、内容の真実、全体収束を証明しない。