要約

  • RFC 9432は、メンバーゾーンの一覧と属性を通常のDNSゾーンに格納し、コンシューマーが権威サービスを自動で追加・削除・再構成できるようにする。メンバーの権威データそのものは、別のゾーン転送で取得される。
  • バージョン2として正しいこと、転送相手が認証済みであること、メンバー名をローカルに受け入れられること、削除対象の状態がそのカタログに属すること、実行中のサーバーが意図どおり動いたことは、別々の事実である。
  • 安全な運用には、最終有効状態の保持、独立した受入れ範囲、カタログとメンバーラベル単位の来歴、破壊的差分の停止、復旧可能な隔離、coo移行の明示、外部からの権威応答確認が必要になる。

再起動しても残すべき状態、受信後に消える状態

RFC 9432は、以前は正しかったカタログが壊れた場合、そこから構成されたメンバーを削除も再構成もしてはならないと定める。サーバーが再起動しても、最後に有効だった一覧を基にメンバーを提供し続けることが望ましい。壊れた入力を新しい命令として扱わない、よく設計された境界である。

ところが、メンバーが一件もないカタログは壊れているとは限らない。SOAとNSがあり、version TXTが一つだけ「2」を示し、矛盾したPTRも不正な属性もなければ、形式は正しい。認証付きIXFRが成功すれば、ネットワーク上の検査も通る。

それでも、空の一覧が在庫取得失敗の産物なら、意味は誤っている。RFC自身、生成スクリプトが空のカタログを作れば、数百万のメンバーが数秒でセカンダリーから削除され得ると警告する。

「壊れたか」を判定する仕組みと、「正しい形式の変更を実行してよいか」を判定する仕組みは別にしなければならない。

特別な意味を与えられた普通のDNSゾーン

Catalog Zoneは、転送という点では通常のDNSゾーンである。zones配下のPTRがメンバー名を示し、一意のラベルの下にgroupやcooなどの属性が置かれる。コンシューマー側でそのゾーンをカタログとして設定したときに初めて、レコードがサーバー構成へ変換される。

カタログにメンバーゾーンのA、AAAA、MX、NSやDNSSECレコードが入るわけではない。メンバーを構成に追加した後、コンシューマーは指定されたプライマリーから通常の転送を行う。

したがって、カタログ転送成功とサービス開始は同じイベントではない。新しいメンバーが構成に現れてもAXFRが失敗することがある。カタログから消えたメンバーを一部のノードだけが提供し続けることもある。メンバーのNOTIFYが、カタログでの追加より先に届く場合さえある。

証拠はカタログのSOAシリアルで終わらない。ローカル判定、実行時構成、メンバー転送、ロード、各提供拠点の権威応答まで連続していなければならない。

「受け取った」と「任せた」の間にある三つの境界

最初は形式の境界である。バージョン2には、実装が理解する値を持つ単一のversion TXTが必要だ。メンバーPTRのRRsetは一つの値だけを持ち、異なるラベルが同じメンバーを重複して指してはならない。既知の属性が不正ならカタログは処理されない。未知のレコードは勝手に意味付けせず無視する。

次は転送元の境界である。TSIGはDNSトランザクションを認証し、TLS上のゾーン転送は通信の保護や機密性を加えられる。これは、設定した相手から観測したメッセージが届いたことを裏付ける。生産側の顧客台帳が正しいことまでは証明しない。

三つ目は受入れの境界である。RFC 9432は、どのゾーンを提供するかという管理権がカタログ生産者へ完全に移ると説明したうえで、コンシューマーに許容メンバーの範囲を制限するよう勧める。正規表現でも、別データベースとの照合でもよい。

認証は「誰から来たか」を狭める。受入れポリシーは「その相手に何を任せるか」を狭める。両者を一つの信頼フラグにまとめると、既知の相手が出した誤った在庫を止められない。

名前が同じでも、状態の所有者は同じとは限らない

メンバー削除には来歴条件がある。あるカタログからゾーンが消えても、そのゾーンが同じカタログによって最初に構成されたのでなければ、コンシューマーはゾーンや関連状態を削除してはならない。静的設定や別カタログが作った状態に、着信カタログの削除権限は及ばない。

この判断には、現在のゾーン名だけでなく、起点カタログ、メンバーラベル、初回受入れシリアル、適用したローカルプロファイル、作成した状態領域が必要になる。

起点が一致する場合、削除対象にはゾーンデータやDNSSEC鍵が含まれ得る。RFCは誤操作からの回復のため、一時的なアーカイブも検討できるとしている。保持期間、復元責任者、鍵の保護、復元後の再同期を決めていないアーカイブは、復旧策ではなく未整理の秘密保管になる。

古いカタログを再送するだけでは巻き戻せない場合もある。製品がファイル、ジャーナル、タイマー、鍵を消した後なら、同じPTRを戻しても新規メンバーとして作り直されるだけかもしれない。

意味を持たないラベルが状態をリセットする

メンバーの一意ラベルは、人間向けの意味を持たない。ゾーン名はPTRの対象にある。しかしラベルを変更すると、コンシューマーはメンバーを一度削除し、直ちに新規追加として処理する。つまり、見た目には無意味な文字列差分が状態リセットを指示する。

cooによる所有権変更では、このラベルが引継ぎの鍵になる。旧カタログが新カタログを指し、新側にもメンバーが現れ、旧側の指示がまだ有効であることを確認してから移行する。

新カタログが同じラベルを維持すれば、関連状態を引き継げる。意図された事業者移行なら有益だが、鍵や製品固有データまで新しい所有者へ渡る可能性がある。引継ぎを望まない旧所有者は、cooと同時かそれ以前にラベルを変え、状態をリセットしなければならない。

移行申請には「ゾーンを移す」だけでなく、データ、ジャーナル、タイマー、DNSSEC鍵、非公開メタデータの扱いを個別に記す必要がある。

空は有効、重複は壊れ、衝突は拒否される

カタログ処理では、似て見える差分が異なる結果を持つ。空の一覧は有効になり得る。重複PTRは壊れたカタログになる。既に別の方法で構成された同名ゾーンと着信メンバーが衝突すれば、新しい方を無視し、エラーを記録する必要がある。

この違いを運用画面で保持すべきだ。「未適用」という一分類にすると、構文違反、ローカル受入れ拒否、名前衝突、異常差分停止、実装未対応が区別できない。復旧方法も責任主体もそれぞれ異なる。

有効だが異常な差分には、ローカルの停止条件が必要だ。想定外の空、一定割合を超える削除、新しいサフィックス、顧客区分をまたぐ変更、ラベル大量変更、未知の私有属性を実行前に隔離する。最後に有効だった実行状態を維持しながら、人間または独立した在庫証拠で意図を確認する。

グループと拡張は合意があって初めて意味を持つ

groupの文字列には共通の意味がない。生産者とコンシューマーが事前に合意し、コンシューマーがローカルの構成プロファイルに結び付ける。理解できない値は無視し、複数値をどう扱うかも実装が決める。

ext配下のカスタム属性はさらに限定的で、実装固有の意味しか持たず、相互運用性は期待されない。IANAはバージョン2についてzones、version、coo、group、*.extを登録している。登録は名前空間の調整であって、私有属性を普遍的な命令に昇格させるものではない。

ここにはHeng LuのMinimum Initial Specificationが見える。共通層は、ローカルに検証できる最小の文法と失敗規則にとどまる。追加の意味は当事者が選んで採用する。文書に掲載されたことではなく、実装・検証・稼働によって初めて現実になる。

製品名ではなく、リリースごとの挙動を調べる

BINDの現行文書は、カタログ更新によるメンバーの追加、削除、再構成、バージョン1と2、ラベル変更によるリセット、cooを説明する。最小更新間隔は変更の頻度を抑えるが、意図を審査するものではない。

Knot DNSはグループをローカルの構成プロファイルへ割り当てる。カタログから外れたメンバーについて、文書にあるゾーンファイル例外を除き、ゾーンファイル、ジャーナル、タイマー、DNSSEC鍵を直ちに消去すると明記する。また、カタログ更新がより広いゾーン再ロードを引き起こし得る。差分の影響はメンバー一覧に限定されない場合がある。

PowerDNSはバージョン2の生産者・コンシューマー、coo、複数のgroup、状態リセットを示す一意値を文書化している。対応するバックエンドや属性には独自の範囲がある。

混在環境では「RFC 9432対応」という一行を証拠にできない。壊れた入力、空入力、衝突、未知のグループ、削除、ラベル変更、片側だけの移行、再起動、復元を各リリースで試し、状態とパケットを記録する必要がある。

カタログの権力を追跡できる台帳

受け入れた各シリアルについて、内容ハッシュ、正規化差分、認証相手、転送方式、形式判定、受入れ規則と版、各メンバーの起点カタログとラベル、衝突や無視理由、コンシューマーごとの適用結果、メンバー転送、ロード、外部権威応答を結び付ける。

削除には状態一覧、アーカイブID、消去時刻、復元期限を加える。cooには新旧双方の観測、ラベル継続またはリセット、状態引継ぎの承認を加える。秘密鍵や機密カタログ全文を通常ログへ出してはならない。

台帳が答えるべきなのは、誰が何を送ったかだけではない。どの範囲を受け入れ、何を所有していたため削除でき、どのバイナリーが何を実行し、利用者が最後に何を解決できたかである。

情報源