特集
いよいよ明日10月11日深夜に実施、「ルートゾーンKSKロールオーバー」は過度に恐れる必要は無い!?（普段からきちんと管理されているネットワークであれば）
2018年10月10日 12:05
延期されていた「ルートゾーンKSKロールオーバー」における新しい署名鍵での署名開始が、当初の予定から1年遅れとなる協定世界時の10月11日16時（日本時間では10月12日1時）に決まった。9月16日にベルギーで開催されたICANN理事会において正式決定された。ICANNでは、延期していた間に実施した問題解決のための活動、関係者間の連携強化、さらなるアウトリーチ活動により、再延期の必要はないと判断しているが、実際のところはどうなのだろうか。その点について、技術的な面から改めて確認してみたい。
なお、本記事の執筆における技術的な背景や内容の確認については、株式会社日本レジストリサービス（JPRS）に取材というかたちでご協力いただいた。
「ルートゾーンKSKロールオーバー」とは何か？誰が何を対応すればよいのか？
「ルートゾーンKSKロールオーバー」とは、DNS（Domain Name System）のセキュリティ拡張機能である「DNSSEC（DNS Security Extensions）」の運用に関する作業の1つで、文字通り、ルートゾーンで使っているDNSSECの鍵署名鍵（KSK）を新しいものに更新する（ロールオーバーする）ことである。DNSSECでは安全性を高く保つために鍵の更新が必要であり、今回がルートゾーンにおけるDNSSEC運用開始後、初めての作業となる。
DNSSECでは、電子署名の技術を用いた信頼の連鎖を、親子間で構築している。図1のように各ゾーンにおいて鍵署名鍵（KSK）とゾーン署名鍵（ZSK）と呼ばれる2種類の鍵が使われており、KSKに対応するDSリソースレコードを親ゾーンに登録することで、親子間の信頼の連鎖が構築される。
ルートゾーン以外のKSKを更新する場合、それに対応する親ゾーンのDSリソースレコードを更新する必要がある。これらは、それぞれのゾーンの権威DNSサーバーの管理者が作業すればよい。
しかし、ルートゾーンはDNSの階層構造の頂点に位置しており、親ゾーンは存在しない。そのため、ルートゾーンのKSKを更新する場合、それに対応する「トラストアンカー」をフルリゾルバー（キャッシュDNSサーバー）側で更新する必要がある。トラストアンカーはDNSSECにおける信頼の起点であり、DNSSEC検証が有効になっているすべてのフルリゾルバーに設定しなければいけないものだ。
つまり、ルートゾーンKSKロールオーバーにおいて作業が必要になるのは、ルートゾーンを管理するICANNと、世界中に存在するDNSSEC検証が有効になっているフルリゾルバーの管理者ということになる。
DNSSEC検証が有効になっているフルリゾルバーは、世界中にどの程度存在するのだろうか。読者の皆さんは「あまり多くないのでは」と思われるかもしれない。しかし、米国最大のISPであるComcastやGoogle Public DNSをはじめとする主要なパブリックDNSサービスなどがDNSSEC検証を有効にしており、ICANNではこれらの利用者が世界中に7億5000万人いると見積もっている[*1]。 これらの利用者が、ルートゾーンKSKロールオーバーの影響を受ける可能性がある。
DNSサーバーソフトウェアにおける対応状況と注意点
このように書くと、「これは大変だ」と思われるかもしれない。しかし、ルートゾーンKSKロールオーバーはIETFにおけるDNSSECの標準化の時点ですでに想定されており、「RFC 5011」で定義されるトラストアンカーの自動更新をサポートしているフルリゾルバーであれば、ルートゾーンにおけるKSKの更新作業（具体的には、新しいKSKの事前公開作業から30日後）に同期するかたちで、保持しているトラストアンカーが自動更新されるようになっている[*2]。
また、DNSサーバーソフトウェアの「BIND」や「Unbound」の現在配布されているバージョンには、現在のKSKと新しいKSKに対応する2つのトラストアンカーが標準設定されており、初期状態でルートゾーンKSKロールオーバーに対応したものとなっている。こうした理由から、最新のDNSサーバーソフトウェアを適切な設定で運用していれば、ルートゾーンKSKロールオーバーに対応するための特別な設定作業は不要である。
ただし、前述した通り、今回のルートゾーンKSKロールオーバーはルートゾーンにおけるDNSSEC運用開始後、初めての作業である。また、事前検証で複数のDNSソフトウェアにおいて、RFC 5011の手順が正しく動作しなかったケースが報告され、修正版のソフトウェアがリリースされている。加えて、DNSサーバーソフトウェアの設定で、トラストアンカーの自動更新を意図せず無効にしてしまっているケースも考えられる。
そのためICANNでは、DNS運用者・メディア関係者・研究者向けにルートゾーンKSKロールオーバーに関するガイドを公開し、設定の確認とトラブル発生時の対処方法に関する注意を呼び掛けている[*3]。
[*2]……DNSセキュリティ拡張（DNSSEC）におけるトラストアンカーの自動更新（日本語参考訳）
[*3]……ルートKSKロールオーバーの実施により予想される影響について（PDF）
「ルートゾーンKSKロールオーバー」で懸念された2つの事項とその状況
今回のルートゾーンKSKロールオーバーを進めるにあたり、2つのトラブル発生が懸念された。1つは、今回の作業によりルートサーバーのDNS応答サイズが大きくなることで、応答を正しく受け取れなくなることによるトラブルの発生。もう1つは、前述したRFC 5011によるトラストアンカーの自動更新を含む、KSKの更新作業に伴うトラブルの発生である。
前者では、ルートゾーンが返すDNSSECの公開鍵、具体的にはDNSKEYリソースレコードの応答サイズがIPv6においてフラグメンテーションが発生しうる1280バイトを超える状態が発生する2017年9月19日がXデーとされた。この作業は予定通りに実施されたが、結果として大きなトラブルの発生は報告されなかった。
しかし、後者については作業直前の調査により、新しいKSKに対応していない、つまり、このまま作業を進めた場合にトラブルが発生することが懸念されたため、以降の作業を延期し、原因究明と問題解決のための時間を確保することとなった。
ルートゾーンKSKロールオーバーは、本来であれば昨年（2017年）10月に行われていたはずのものだ。しかし、ICANNがDNSSEC検証を有効にしているフルサービスリゾルバーを調査したところ、トラストアンカーの更新に対応していない可能性のあるものが無視できない割合で見つかったことから影響が大きいと判断し、延期を決定した。
その後、ICANNでは作業チームによる入念な調査および作業計画の策定と、さまざまなチャネルでのアウトリーチ活動を進めてきたという。その結果、多くの問題が解決し、延期されたルートゾーンKSKロールオーバーの実施が決定されたということである。
動作中のフルリゾルバーの確認方法
前述の通り、ルートゾーンKSKロールオーバーでは2つのトラブル発生が懸念された。そのうち、ルートサーバーのDNS応答サイズが大きくなることについては、2017年9月19日以降に大きなトラブルの発生が報告されなかったことから、今回の作業における支障は発生しないと考えられている。
しかし、サイズの大きなDNS応答はDNSSECに限ったものではなく、通常のDNS運用においても正しく受け取れる必要がある。そのため本稿では、サイズの大きなDNS応答を正しく受け取れるかの確認についても、改めて解説する。
サイズの大きなDNS応答を正しく受け取れるかの確認
ルートゾーンKSKロールオーバーに対応するためには、少なくとも1424バイトのDNS応答を正しく受け取れる必要がある。この確認には、Verisign Labsが公開している確認用のサイト「DNSSEC Key Size Test」が使用できる。
これは、ウェブブラウザーから同サイトにアクセスするだけという手軽さで診断してくれる（本サイトでテストされるDNS応答サイズは1424バイトよりも大きい）。診断結果は図2のような表を含むかたちで表示され、1から4までの4項目が緑で「PASS」となっていることを確認すればよい。5が赤で「FAIL」と表示されるが、こちらは失敗表示の確認用であるため、気にしなくてよい。
もしも1から4までの結果に「FAIL」が出た場合には、何らかの理由により大きなサイズのDNS応答を受け取れなかったことを示している。この場合、使っているフルリゾルバーが古かったり、フルリゾルバーから外部ネットワークまでに経由するネットワーク機器に問題があったりする可能性がある。
こうした問題は、昔設置したサーバーやネットワーク機器がそのままの状態で使われている場合に発生しやすい。フルサービスリゾルバーについては、ざっと考えても以下のような状況で作られたサーバー上で動いているものが想定される。そのため、以下のようなサーバーやネットワーク機器が使われていないか、改めて確認してほしい。
- 業者が設置してそのままになっているサーバー
- 学校などで昔、誰かが設定し、そのまま使われているサーバー
- インストーラーで設定した不適切なデフォルト設定のままで使われているサーバー
- フラグメントされたパケットを正しく処理できない、古いファイアウォールやネットワーク機器
- 不適切な設定がされているパケットフィルタリング装置
使用しているフルリゾルバーの確認
2つ目の懸念点、つまり、KSKの更新作業に伴うトラブルについてはICANNの文書にもあるように、フルリゾルバーにおいてDNSSEC検証が有効になっている場合が対象となる。
フルリゾルバーにおける確認事項は、以下の2点である。
- 少なくとも1424バイトのDNS応答を正しく受け取れることの確認
- DNSSEC検証を有効にしている場合、トラストアンカーの更新がうまくいっているかの確認
1.については、前述したVerisign LabsのDNSSEC Key Size Testで確認できる。2.についてはそれぞれのDNSサーバーソフトウェアのマニュアルやドキュメントに加え、前述したICANNの文書[*3]、JPRSが公開している資料[*4]の参考リンクから参照されている技術文書・発表資料などを参照し、適切な対応を実施してほしい。
[*4]……ルートゾーンKSKロールオーバーの概要と影響の確認方法（最終更新：2018年10月4日）（PDF）
やるべきことをやっていれば、過度に恐れる必要は無い
ここまでいろいろ述べてきたが、ルートゾーンKSKロールオーバーに対応するための要点をまとめると次のようになる。
- 1424バイトのDNS応答を正しく受け取れることを確認する。受け取れていればOK。
- DNSSEC検証を有効にしている場合、使用しているDNSソフトウェアとそのバージョン・設定内容が、ルートゾーンKSKロールオーバーに対応済であることを確認する。
- 大きなDNS応答はDNSSECに限ったものではなく、通常のDNS運用においても正しく受け取れる必要がある。そのため、自分の環境に問題がないか、改めて確認しておくとよい。
現実問題として考えれば、これらのことは普段からの管理がきちんと行われていれば自然とクリアされているはずの内容ばかりである。問題が起こるとすると、それは、“管理されていない”もしくは“間違った管理や運用がされている”ネットワーク環境ではないだろうか。
ルートゾーンKSKロールオーバーの各作業がいつ行われるかの日時は気に留めておいてほしい（図3）。しかし、それぞれの組織の管理者がやるべきことをやっていればそれを過度に恐れる必要は無いというのが、今回取材して感じたことである。
