記事保存。
ルートサーバーに手が加わると、企業のネットワーク担当者が管理するDNSサーバー側でも変更が必要になることがある。今回のようにルートサーバーのIPアドレスが変わったケースでは、企業などに設置されているキャッシュDNSサーバー側で設定変更しなければならない。どこに手を加えればいいかは、そもそもキャッシュDNSサーバーが最初に接続するルートサーバーをどのように決めているかを知ると理解しやすい。
キャッシュDNSサーバーには、「ルートヒントファイル（単にヒントファイルとも呼ぶ）」というルートサーバーの一覧が保存されている。プロセス起動時などにこの中から1つのルートサーバーを選んで接続し、「最新のルートサーバーの名前の一覧とそのIPアドレス」を問い合わせて、返ってきた内容をメモリー上に保存しておくのだ。もう少し細かく書くと、キャッシュDNSサーバーからルートサーバーに対して、「ルートサーバーのNSレコードならびにその参照情報」を問い合わせて応答を得ていることになる。以降、キャッシュDNSサーバーが反復的問い合わせをする際には、このメモリー上にためた情報を使う。
以上のような機能は、「最初に問い合わせる先を調べる」という意味で「プライミング（priming）」と呼ばれる。priming動作の詳細はDNSサーバーソフトごとに異なるが、BIND、Unboundなどの有名なDNSサーバーソフトの最近のバージョンには実装済みだ。
一見、「primingがあれば、ルートサーバーのIPアドレスが変更になってもキャッシュDNSサーバーは最新の情報を取得できる」と思ってしまうかもしれない。ただしルートヒントファイルが古いままだと、priming時の最初の問い合わせ先として古いルートサーバーのIPアドレスを選択し、接続に失敗する可能性がある。この場合、タイムアウトして別のルートサーバーに接続するまでに時間がかかる。
また、古いIPアドレスが別のサービスに転用されてしまうと問題が起こりそうだ。例えば攻撃者が古いIPアドレスを利用して悪意あるサーバーを立て、偽のルートサーバーとして振る舞うようなケースだ。偽のルートサーバーにキャッシュDNSサーバーがprimingで接続してきたら、不正なサーバーの一覧を送り付けられてしまうかもしれない。キャッシュDNSサーバーが偽の一覧情報を受け入れてしまったと仮定すると、その配下のクライアントは本来のインターネットとは全く異なる名前空間に誘導されてしまう危険性がある。こうした問題が起こる可能性はかなり低いが、論理的にゼロとも言いきれない。
そのためprimingが実装されているDNSサーバーソフトを採用していても、キャッシュDNSサーバーの管理者はルートヒントファイルの設定を最新のものに変えておく必要がある。ルートヒントファイルは、インターネット上で公開されている。
具体的な設定方法は、DNSサーバーソフトによって異なる。例えばBIND 9では「named.conf」という設定ファイルでルートヒントファイルを指定する。これを最新のファイルに更新してから、「rndc reload」コマンドでファイルを再読み込みするか、DNSサーバーのプロセスを再起動する（日本レジストリサービスの情報）。ちなみにD-rootはIPv6にも対応するが、こちらは変わらないのでIPv4に関してだけ設定変更を実施しておけばよいそうだ。
上で挙げたような「名前空間乗っ取り」は、最悪のケースを想定した展開である。実際に起こる可能性は高くはないので、ルートサーバーのIPアドレス変更に伴う作業は今すぐに実行しなければならないものではない。メリーランド大学では、1月3日から最短でも6カ月間は古いIPアドレスも併行して運用すると発表している。日本レジストリサービス（JPRS）に聞いたところでは、「6カ月以内のDNSサーバーの定期メンテナンス時などに、忘れずに実行しておくとよいだろう」（JPRS 技術広報担当の森下泰宏氏）とのことだった。
引用元: 記者の眼スペシャル2013 - 存外深いインターネットの“根っこ”の話：ITpro,
http://itpro.nikkeibp.co.jp/article/COLUMN/20130112/449247/?top_tl1
