DNSカタログゾーンが集中させる設定権限

要約

通常のゾーン転送は一つのDNSゾーンの内容を同期するが、セカンダリが提供すべきゾーン一覧までは同期しない。RFC 9432は、その一覧を通常のDNSゾーンとして表す。プロデューサーがPTRによるメンバーと属性を公開し、コンシューマーが転送後に自身を設定する。

これはサーバーごとの反復作業と実装差を減らす。しかし同時に権限を移す。仕様は、どのゾーンを提供するかという管理上の制御がコンシューマー運用者からカタログのプロデューサーへ完全に移ると述べる。一回の更新が多数のサーバーの追加、削除、変更を引き起こし得る。

壊れたカタログには命令としての意味が与えられない。必須バージョンの欠落や未対応値、重複メンバー、既知属性の不正があれば処理してはならない。以前は正しかったカタログが壊れても、既存メンバーを削除・再設定せず、最後の有効状態を維持する。

ただし、有効で空のカタログは壊れていない。同じカタログが設定したメンバーを削除する命令になり得る。したがって公開前にはDNS構文だけでなく、生成された件数と承認済み台帳の照合が必要だ。

coo属性は別カタログへの移行を調整する。コンシューマーは移行先にもメンバーがあることを待ち、旧カタログの指示を再確認する。同じメンバーノードラベルを使えば関連状態を新しい所有者が引き継げる一方、ラベル変更は状態リセットを求める。

これは単なる名称変更ではない。ゾーンデータ、DNSSEC鍵、運用属性の境界である。移行記録には旧・新カタログ、ラベル、承認者、引き渡す状態、双方が整合していた証拠を残す必要がある。

RFC 9432は転送と更新の認証を推奨する。RFC 8945のTSIGはDNSメッセージを認証し、RFC 9103のTLSゾーン転送は機密性とTLS認証を提供できる。TSIG共有秘密をカタログに含めてはならない。

それでも、認証された生成者が誤ったメンバーを選ぶ可能性は残る。コンシューマーは外部台帳などで受入可能なゾーンを限定すべきだ。カタログには提供ゾーンと管理属性が現れるため、機密性も必要になる。

標準は普及率、特定事業者の事故、効果の測定値を示していない。恩恵を受けるのは一貫した迅速な設定を得るDNS運用者と顧客であり、代償は権限と障害範囲の集中である。反実仮想の手動設定は遅く不均一だが、一つの誤りが即座に全体へ広がりにくい。