要約

  • DNSの当初の複製モデルでは、セカンダリがREFRESHの周期でプライマリのSOAを確認した。負荷を抑える一方、複数の権威サーバが異なる版を答える時間を設計上受け入れていた。
  • NOTIFYは新しいゾーンを送り込む仕組みではない。設定済みのセカンダリにシリアル確認を促し、IXFRはそのセカンダリが持つ版から現在版までの削除・追加を順序付きで返した。
  • 高速化しても、循環するシリアル算法、AXFRへのフォールバック、安定記憶への保存、全差分の処理、原子的な切替、任意のTSIG認証が境界を保った。早い合図は、早い服従を意味しなかった。

権威が二つの現在を語るとき

一つのゾーンに複数の権威サーバを置けば、障害耐性は高まる。しかし、プライマリの内容が変わった瞬間、複製という仕組みは別の問題を生む。すべてのサーバが同じ「現在」に到達するまで、どれも権威を名乗りながら異なる答えを返し得る。

RFC 1034は、変更を調整するプライマリと、定期的にSOAを問い合わせるセカンダリを定めた。セカンダリはSERIALを比較し、プライマリが新しければゾーンを転送する。REFRESHは通常の確認間隔、RETRYは失敗後の再試行、EXPIREは更新できないコピーが権威を降りる期限である。RFC 1035はこれらを32ビットの値として定義し、ゾーン全体を移すAXFRを割り当てた。

これは合理的な節約だった。変化がなければ小さなSOA問い合わせだけで済み、毎回ゾーンを複製しない。セカンダリ自身が確認時刻と失効期限を持つため、プライマリが各複製との常時接続を管理する必要もない。

その代わり、古さの長さが運用パラメータになった。確認直後に更新が入れば、次のREFRESHまで旧版が提供される。間隔を短くすれば平常時の問い合わせが増え、長くすれば権威間の不一致が伸びる。

これはリゾルバのキャッシュとは別である。権威サーバが全て新しくなった後も、再帰リゾルバはTTLの間だけ旧RRを持ち続けることがある。逆に権威側が未収束なら、空のキャッシュを持つ二つのリゾルバでさえ、問い合わせ先によって異なる答えを得る。NOTIFYとIXFRが短くしたのは後者の時間だ。

変化がなくても尋ね続ける費用

ゾーンが大きくなると、発見と取得の二つの無駄が目立った。小さな変更を早く知るには頻繁なポーリングが必要で、知った後は一レコードの修正でもAXFRで全体を運ぶことがあった。静かな期間の監視コストと、実際の変更量が結びついていなかった。

RFC 1996は、長い更新間隔がマスタの負荷を下げる一方、更新後の不整合を長引かせると説明した。DNS NOTIFYはポーリングを捨てず、その横に割り込みを置いた。マスタが新版を読み込むと、既知のセカンダリ群へ変更を知らせられる。

受信側は通知に含まれるデータをそのまま公開しない。設定したマスタへSOAを問い合わせ、シリアルを比べ、必要な場合だけ転送を始める。NOTIFYの応答部に載せられる情報も、安全な根拠ではなくヒントにすぎない。通知者が得たのは確認を早める力であり、相手の状態を直接書き換える力ではなかった。

ノックは荷物ではない

標準の通知先は、SOAのMNAMEを除くNS RRsetのサーバだった。管理者はこれを上書きし、公開NSには現れないステルス・セカンダリを追加できた。転送関係はループのない依存グラフを構成する必要があり、あるサーバは上流から見ればセカンダリ、下流から見ればマスタになれた。

この階層はプライマリへの負荷集中を避ける。だが、実際の複製経路が公開ゾーンだけでは見えないことも意味する。誰が誰から取得し、どの更新をさらに知らせるのかは、運用側が管理すべき設定情報だった。

NOTIFYはベストエフォートである。UDPでは応答を得るか上限に達するまで再送できる。複数の上流から同じ変更を聞くセカンダリは、処理中の重複を抑えなければならない。複数回のノックを複数の同時転送に変えれば、マスタを守るための機構が逆にマスタを叩く。

応答は受信確認であって、更新完了証明ではない。送信元を偽装した通知は不要なSOA問い合わせを誘発でき、未対応サーバはNOTIMPを返す。通知を失っても従来のREFRESHが次の確認を起こす。したがって「DNSをプッシュした」という表現は正確でない。押し出されたのは緊急性で、ゾーン本体と採用判断は別経路に残った。

ゼロへ戻っても古くならない番号

版の比較にはSOAシリアルを使う。32ビットの最大値を越えるとゼロへ戻るため、通常の整数比較では未来が過去より小さく見える。RFC 1982は有限のシーケンス空間として算法を定義した。

加算は剰余で行い、許される増分には上限がある。半周より近い二値なら、ゼロをまたいでも前後を判断できる。しかし空間のちょうど半分だけ離れた値には大小が定義されない。EXPIRE期間内に合計2^31−1を超えて進めると、古いセカンダリの番号が新しく見える危険がある。

シリアルは時刻ではない。変更者、承認理由、内容の正しさも示さない。許された遷移列のどこにいるかを比較するための証拠である。狭い意味を守れば十分役立つが、日付や所有権のように扱えば複製判断を壊す。

書庫全体ではなく編集差分を送る

NOTIFYが発見を早めたのに対し、RFC 1995のIXFRは取得を軽くした。クライアントは自分のSOAシリアルを要求に含める。サーバが必要な履歴を持っていれば、その版から現行版までの削除と追加の列を返す。

レコード変更は旧形式の削除と新形式の追加で表され、各差分は旧SOAと新SOAで区切られる。複数の差分は古い順に並ぶ。これは「どこにでも当てられるパッチ」ではなく、「あなたのXから私のYへ至る経路」である。クライアントは全差分を処理してから旧版を置き換える。

サーバに永久保存義務はない。IXFRがAXFRより大きくなるなら古い履歴を捨てられ、EXPIREより古い情報も削除できる。中間版をまとめた純差分も作れるが、別のサーバがクライアントの開始シリアルを知らなくなる場合がある。そのときは全体転送へ戻る。

AXFRへの回帰は退化ではない。差分は共有する起点と保存された経路があるときだけ意味を持つ。共通の記憶が切れたとき、完全な状態が再び基準を作る。効率化は任意でも、収束可能性は必須だった。

公開前に再起動へ耐える

RFC 1995は、サーバが新版をIXFRやAXFRで配る前に安定記憶へ保存するよう求めた。配布後にクラッシュし、再起動したマスタがその版を失えば、セカンダリだけが再現不能な世代を提供することになる。速い複製が永続的な不一致を作ってはならない。

RFC 5936は受信側のAXFRについて、完全性と原子的切替を明確にした。別のファイルやデータ領域で全体を受け、健全性を確認し、それから一度に提供状態へ移す。失敗時は以前の有効版を出し続ける。IXFRも全差分を処理するまで置換しない。

高速経路は、通知、版比較、候補データの取得、検証後の切替という別々の門を通る。一番早く着いたメッセージが、残りの門を飛び越えて権威になることはない。

経路を認証しても内容を聖別しない

ゾーン転送は情報を露出し、受信側の回答を変える。RFC 5936はポリシーに沿ったアクセス制限とトランザクション保護を示した。現在の標準であるRFC 8945は、共有秘密とMACを使うTSIGを定義する。

複数DNSメッセージからなるTCP転送では、TSIGがMACを連鎖させ、途中の改変を検出できる。相手が合意済みの鍵を持つことは分かる。ただし暗号化はせず、鍵配布は範囲外で、相手が増えるほど点対点秘密の管理は重くなる。

そしてTSIGが保証するのは通信の真正性であり、元データの真実ではない。誤ったマスタも、侵害されたマスタも、暗号学的には正しい誤情報を送れる。MACの成功を、名称の法的所有、組織の意思、内容の正確性へ読み替えてはならない。

1996年の静かな権限分割

NOTIFYとIXFRは性能拡張に見えるが、分散権威の問いに答えた。一方の運用者が、相手のサーバを直接支配せず、どうすれば素早い変更を促せるのか。答えは発言を小さく分けることだった。「変化した」「私の版はYだ」「あなたのXからはこの差分だ」「履歴がなければ完全版だ」「この転送は合意鍵の保持者から来た」。

どれ一つとして単独では公開判断にならない。セカンダリは開始点、取得元、完全性、切替を自分で引き受ける。その構造のおかげで、古い権威データが残る時間は短くなっても、通知者の権力は無制限にならなかった。

もちろん誤りも速く広がる。悪い編集は最初の苦情より先に全拠点へ届き、短いジャーナルは長期障害からの復帰時にAXFR集中を生み、誤ったシリアル操作は更新を止める。高速化は運用統治を不要にせず、変更前の検証をより重要にした。

ゾーンはノックを覚えた。セカンダリは早く目を覚ますようになった。それでも、扉を開け、荷物を検め、何を権威として答えるかの責任は受信側に残った。

情報源と証拠の限界

RFC 1034とRFC 1035はポーリング、SOAタイマ、AXFRを定める。RFC 1982はシリアル算法、RFC 1995はIXFRと全体転送への回帰、RFC 1996はNOTIFYと設定グラフ、RFC 5936は完全かつ原子的なAXFR採用、RFC 8945はTSIGの保護範囲を定める。

これらは設計と要件の証拠であり、世界同時の導入日、全運用者の設定値、実測された世界収束時間を示さない。本稿が導くのは、合図、版証拠、転送、ローカル実行が分離されたという限定的な結論である。