CZDSのゾーンファイルアクセスは誰が認めるのか

要約

ICANNのCentralized Zone Data Serviceは申請経路と標準契約を共通化する。しかし、資格情報の確認、レジストリによる承認、契約上の監督、利用者の行為は、それぞれ異なる責任主体に属する。
承認で得られるのは、ゾーンデータを限定的かつ譲渡不能な形でコピーする権利である。ドメイン名の所有権やTLDの管理権ではない。契約に処理期限がないことが、最も見えにくい統制上の空白だ。

セキュリティ担当者やDNS研究者にとって、CZDSの利便性は明確だ。参加するgTLDごとに契約書と配布経路を探す代わりに、一つのアカウントから複数の申請を送れる。手続の探索コストは大きく下がる。

一方、ICANNの案内は重要な限界も示している。Registry Agreementには、レジストリ運用者が申請を処理すべき期間が定められていない。窓口は一元化されても、回答時間は統一されていない。

この差は、データがいつ役に立つかを左右する。長期的な統計研究なら数日の遅れを吸収できるかもしれない。インフラを短期間で切り替えるフィッシングやマルウェアの追跡では、同じ遅れが観測価値を失わせる。画面に「処理中」と出るだけでは、本人情報の不足、レジストリの審査、説明のない滞留を区別できない。

gTLDのゾーンファイルは、委任された名前と、その権威DNSサーバーへ到達するためのレコードをまとめて示す。追加や削除、インフラの集積を観測する材料になる。しかし、登録者情報を網羅するデータベースではなく、名前の所有者を証明するものでもない。

改正後のSpecification 4が認めるのは、非独占的、譲渡不能かつ限定的なアクセスで、通常は24時間に一度までコピーを取得できる。利用は合法でなければならず、不特定多数への商業勧誘、レジストリやレジストラのシステムに対する大量の自動照会、登録者の通常業務への妨害には使えない。

コピーを受け取ることと、ゾーンを変更することは違う。無制限に再配布する権利も、レジストリとして振る舞う権限も生じない。観測可能性と統治権限を混同しないことが、この制度を読む第一歩になる。

最初の判断主体は、ICANNまたはその指定先であるCZDA Providerだ。申請者が本人確認と連絡先の要件を満たさなければ、申請を拒否できる。これは資格情報に関するゲートである。

次に、レジストリ運用者は、情報が不正確・不正である場合や、予定する利用が契約上の制限に反すると合理的に考える場合に拒否できる。アクセスを認めた後も、違反を裏付ける証拠があれば取り消せる。取消しは、承認後の行為を根拠とする点で、最初の拒否とは異なる。

ICANN Contractual Complianceは、第三者アクセスを提供するレジストリの義務について苦情を受け付ける。契約順守を審査することは、個々の申請を直接承認することではない。「ICANNが拒否した」と一括りにすれば、誰が何を根拠に判断し、どの救済経路が使えるかが見えなくなる。