RFC 5158：30日点検が証明したのはDNSの生存性だった

要約

登録サービスは、提案された権威サーバーが実際に稼働することを確かめてから親ゾーンを変更する。プライマリと少なくとも一つのセカンダリが到達可能で、対象ゾーンへの権威応答を返し、SOAとNS RRsetについて一致していなければならない。設定途中の委任を公表しないための、実務的な前提条件だった。

登録後も確認は続く。RFC 5158 は30日間隔でサーバーを調べ、失敗したら連絡し、14日後に再確認する流れを示した。2回目も失敗すれば委任を削除する。古い委任が永久に残るより、はるかに扱いやすい。

ただし、観測している変数を広げてはならない。問い合わせへの応答はサーバーの生存証拠である。同じSOAとNSは設定の整合証拠である。それらはIPv4の割当契約も、組織内部の承認も読んでいない。

6to4の/48は、外部IPv4の32ビットを2002::/16の後ろへ置いて作られた。式は安定しているが、入力となるIPv4の利用者は安定しているとは限らない。アクセス回線のアドレスがプールへ戻り、別の顧客へ再配布されれば、新しいサイトも同じ/48を導く。

以前の権威サーバーが停止していれば、定期点検はいずれ障害を発見する。しかし、サーバーが動き続けていれば、点検は成功する。旧管理者のDNSが健康であることと、現在のアドレス利用者がそのDNSを望んでいることは両立しない場合がある。

逆も同じだ。正当な管理者のサーバーが一時停止したからといって、組織の権限が失われたわけではない。生存性を権利の代理指標にすると、誤った主体を残し、正しい主体を消すという両方向の誤差が生まれる。

RFCは短いTTLを用いて、変更後も古い情報が長く残らないようにした。これはDNSキャッシュの寿命を扱う措置である。親ゾーンの委任がいつ撤回されるか、IPv4がいつ別の顧客へ移るか、管理者がいつ承認を取り消すかは、それぞれ異なる時計で進む。

四つの時刻を一つにまとめると監査が崩れる。レスポンスのTTL満了、登録サービスの30日点検、14日の猶予、実際のアドレス割当終了は相互に同期していない。最短のタイマーが他の状態を自動的に無効化するわけでもない。

IPv4を管理する側が別経路で登録をブロックできたことは、この違いをよく表す。送信元を持つクライアントの自己申請能力より、資源管理者の停止権限が上位に置かれていた。権限面は一枚ではなかった。

クライアントは、自分の6to4送信元から導かれるゾーンだけを要求できた。この制限により、無関係な/48を直接乗っ取る要求は難しくなる。HTTPSも、登録画面の改変やサービス偽装、プロキシキャッシュの混乱を抑えた。

それでもRFCは、アドレスベースの認証が原始的で詐称の余地を持つと認めている。さらに、同じサイト内部の端末なら正当な送信元を自然に持てる。ファイアウォールやACLで申請先への通信を制限しなければ、DNS管理を委任されていない利用者でも登録を変えられる。

従って成功したHTTPS取引は、保護されたチャネルと観測されたネットワーク位置の証拠である。誰が組織を代表したか、承認が現在も有効かという証拠は別途必要になる。

RFC 5158 は、逆引き情報からアドレスとドメインの関係を信頼できる形で検証してはならないと注意した。PTRが存在しても関係を証明せず、存在しなくても関係がないとは言えない。正引きとの一致を追加しても、二つのDNS設定が対応することを示すだけで、法的主体や運用責任までは示さない。

権威サーバーの定期点検はこの限界を変えない。稼働中のサーバーは、古い名前も誤った名前も高い可用性で返せる。ログやアクセス制御がPTRを利用するなら、名称を調査の手掛かりとして扱い、認証資格として扱わない設計が必要だ。

証拠として言えるのは、ある時点で親が導出ゾーンを、所定の稼働条件を満たすサーバー群へ委任していたということまでである。現在の主体を知るには、アドレス割当期間、管理者承認、サーバー変更、独立した運用証拠を結合しなければならない。

後続文書は6to4の運用問題を整理し、anycast relayの仕組みを非推奨にした。古いTLS依存関係も現在のTLS要件によって更新された。RFCに記載された歴史的サービス名から、現在の提供状況や採用を推測することはできない。

一方で、ヘルスチェックと権限を混同する危険は今もある。クラウドの自動登録、証明書発行、サービス発見でも、到達性テストが主体の正当性まで代替しがちだ。RFC 5158の点検手順は優れていたからこそ、その境界が見える。よい生存性チェックは、所有権チェックではない。