要約

  • 1998年1月28日のメールで、Jon PostelはルートゾーンのセカンダリサーバーにIANAの DNSROOT.IANA.ORG からゾーンを取得するよう求めた。同じ内容のコピーを使い、変更手続きも変えないと説明している。
  • 2月3日、Postelは検証試験の終了を伝え、Aルートから取得する従来の方法に戻るよう求めた。残る記録は依頼を示すもので、各運用者の設定変更を証明するものではない。

ひとつのDNSサービスにある二つの通信

名前を引くリゾルバーと、ゾーンのコピーを更新するセカンダリサーバーは、別の仕事をしている。リゾルバーは権威サーバーへDNS問い合わせを送る。セカンダリは、別に設定されたマスターとの転送関係を通じて、自らが提供するデータを得る。二つの役割が同じマシン上にあっても、同じネットワーク処理になるわけではない。

この区別はDNSの運用設計にすでに示されていた。RFC 1034は、プライマリーが変更を調整し、セカンダリがSOAシリアルを確認して更新されたコピーを取得する仕組みを説明する。RFC 1035では、AXFRはゾーン全体を転送する要求として定義されている。リゾルバーがレコードを問い合わせることは、ルートゾーンのAXFRを要求することではない。

1998年1月、ひとつのマシンがルートサーバーとして問い合わせに答え、同時に他のルートサーバーがデータを更新するための転送元になることもできた。Postelの依頼が対象にしたのは後者の役割だ。世界中のリゾルバーに、通常のルート問い合わせをIANAのホストへ送るよう求めたのではない。

メールが指定したのは限定的な転送依頼

保存されたメールは1998年1月28日付で、件名は「root zone secondary service」だった。Postelはルートドメインのセカンダリサーバーに対し、198.32.1.98 のIANAサーバー DNSROOT.IANA.ORG から「ゾーン転送で」直接取得するよう求めた。そこにあるデータは、当時 A.ROOT-SERVERS.NET で利用できたルートゾーンの完全なコピーだと記している。また、ルートゾーン変更の方針や手続きに変更はないと明示した。

サーバー名と同じくらい重要なのが、依頼の適用範囲を限る一文だ。対象はルートゾーンのみだった。他のゾーン、トップレベルドメインを含むゾーンのセカンダリサービスを提供する運用者は、従来の取得元を使い続けるよう指示された。したがって、メールが提案したのは複製経路のひとつを変えることであり、DNS全体を転送したり、すべての上流関係を置き換えたりすることではない。

同じアーカイブには、Postelが報道機関などに送った説明も残る。ルートゾーン情報の流れを組み替え、移行を問題なく行えるか検証する試験だと説明し、ゾーン内容は従来どおりに決定・準備されるとした。ここには別々の二つの主張がある。データは同じままにすること、そしてセカンダリのコピー元として別のIANAサーバーを試すことだ。各セカンダリの設定や個々の転送結果を示す資料ではない。

試験の背後には、レコード自体の変更を誰が認めるのかという別の管理上の問いもあった。1月のメールはその手続きを変えないと明記する。転送元はコピーを供給できるが、それだけでコピー内のすべてのレコードの作成者になるわけではない。試験中にIANAが新しいルートゾーンデータを編集・公開し始めたことを示す記録はない。

転送元の変更は問い合わせ先の変更ではない

この出来事は、Aルートが二つの役割を担っていたため誤読されやすい。Aルートはルートサーバーのひとつとして問い合わせに答える一方、従来のルートゾーンファイルの取得元としても扱われていた。役割は同じマシンに結び付いていたが、転送プロトコルによって、配布元とリゾルバーに応答するサーバーは別々に考えられた。

その影響は条件付きの推論として述べられる。セカンダリが同一のゾーンコピーを取得して正しく読み込めたなら、コピーの取得元を変えるだけでリゾルバーに返るレコードが変わるわけではない。保存メールはIANAのコピーが同一である予定だったと記すが、全サーバーを対象とした比較や、条件がどこでも成立したことを示す問い合わせ測定はない。

後の米国議会公聴会で、NSIは政府との協定に基づきルートゾーンの「プライマリー」サーバーを担った一方、13の運用者間に契約はなく、他の運用者に毎日の取得義務もなかったと証言した。この会社側の説明は、「プライマリー」が運用上の配置を指し、すべてのセカンダリに対する契約上の命令ではなかったことを理解する手掛かりになる。ただし、1998年にPostelの依頼を受け入れた運用者が誰かを明らかにするものではない。

差し戻しの依頼が出来事の範囲を示す

2月3日、Postelは「root zone transfer verification completed」という件名で試験の終了を伝え、ルートゾーンの取得元をAルートに戻すよう求めた。これも対象はルートゾーンに限られていた。RSSAC-023v2の後年のルートサーバー史によると、Postelは試験用にJim KodaとPaul VixieへISIのプライマリーサーバーを作成・運用するよう依頼し、複数の運用者にそこからゾーンを取得するよう伝え、数日後には全運用者に以前のプライマリーへ戻るよう求めた。

この回顧は一連の流れを裏付けるが、参加者を「複数」としか数えていない。回顧にも保存メールにも、実際に設定を変えた運用者の一覧、完全なAXFRログ、各運用者がいつAルートへ戻ったかの受領記録はない。依頼は意図の証拠にはなるが、すべての受信者が実行した証明にはならない。

資料からサービスへの影響を測ることもできない。Postelの説明は中断なしで移行できるという高い自信を示したが、自信は運用データではない。メールには問い合わせ時系列、障害記録、稼働中のコピーすべての独立した比較は添付されていない。

参照資料

出来事に最も近い記録は、Postelの1月28日の依頼と2月3日の差し戻しメールを保存したアーカイブだ。PGP署名ブロックも掲載されているが、この記事ではその署名を独立に検証していない。RSSACの回顧は後年の機関記録を提供する。RFC 1034とRFC 1035は転送方法を定義するもので、1998年の各運用者の設定を記録した資料ではない。NSIの説明は米国下院司法委員会の公聴会記録にあり、会社の証言として扱った。