特別企画
「KSKロールオーバー」で問題を起こしそうな箇所はここだ！ 9月19日だけでなく10月11日にも注意
2017年9月15日 16:34
「ルートゾーンKSK（鍵署名鍵）ロールオーバー」の話題が関心を集めている。しかしながら、この話題の本質を正しく把握するのは難しい。そこで、一般社団法人日本ネットワークインフォメーションセンター（JPNIC）において9月1日に開催された「ICANNの最高技術責任者（CTO）David Conrad氏とのオープンセッション」で話された内容から、この件を整理してみたい。
なお、本記事の執筆における技術的な背景や内容の確認については、株式会社日本レジストリサービス（JPRS）に取材というかたちでご協力いただいた。
新しいKSKで署名が開始される「10月11日」も重要である
ICANNとJPNICとの共催として行ったオープンセッションにおいてConrad氏が取り上げた一連の話題のうち、最も注目を集めたのは、現在進行中のルートゾーンKSKロールオーバーに関するものであった。会場からの質問も多く、活発な意見交換が行われていた。
注目すべきは、Conrad氏の「10月11日に鍵更新が行われるので注意してもらいたい」という発言であろう。これは、ルートゾーンのDNS応答サイズが大きくなる日付だけでなく、新しいKSKが実際に使われ始める日付にも関心を持ってほしいというメッセージである。
その背景には、DNSSEC検証を行っている場合、バリデーター[*1]はKSKが切り替わる前に新しいKSKに対応するトラストアンカー[*2]を入手し、切り替わった瞬間から使われるように設定しておく必要があること。そして、新しいKSKが署名に使われる前に新しいトラストアンカーが設定されなければ、DNSSEC検証を行っているバリデーターは検証失敗によりSERVFAILを返すようになり、結果、名前解決に失敗してしまうということになる。したがって、KSKが切り替わる際には、トラストアンカーの更新に対する作業が必須となるのである。
なお、ICANNとVerisignから、今回の作業に関する時刻の情報が告知された。DNSKEYの応答サイズが大きくなるのが9月19日23時ごろ、新しいKSK（KSK-2017）でのDNSKEY署名が始まるのが10月12日1時ごろ（いずれも日本時間）ということである。詳細については、JPRSが公開した以下のリンクを参照していただきたい。
DNS管理者は、すべてのDNSソフトウェアを最新にすべき
現在、各所でさまざまな情報が提示されているが、読者の多くの関心事は「では、具体的にどうすればよいのか？」にあるのではないだろうか。細かなことを後回しにして最初に言ってしまえば、まずは「使用しているDNSソフトウェアを最新にする」ことである。
本件の影響を受ける可能性があるのは、インターネット上のフルサービスリゾルバー（キャッシュDNSサーバー）である。フルサービスリゾルバーは、利用者のコンピューターからの名前解決要求により各ゾーンを管理する権威サーバー（権威DNSサーバー）に対して名前解決を行い、その結果を問い合わせ元に返す[*3]。
今回変更されるのは、ルートゾーンを管理する権威サーバー（ルートサーバー）の設定である。したがって、ルートサーバーからの応答を受け取らない権威サーバーには本件の直接的な影響は無い。
ルートゾーンKSKロールオーバーにおけるポイントは、「IPフラグメンテーション」と「トラストアンカーの更新」である。IPフラグメンテーションの件は後述するが、トラストアンカーの更新方法についてはRFC 5011[*4]によりすでに定められている。
よく使われるオープンソースのフルサービスリゾルバーといえば、「BIND」と「Unbound」が思い浮かぶが、この2つのDNSソフトウェアの最新版は、トラストアンカーの自動更新に対応済みである。そのため、これら最新版のDNSソフトウェアを適切な設定で使うことにより、トラストアンカーの更新にまつわる不具合の発生を回避できる。
これら以外のDNSソフトウェアについては、開発元から出ているリリースノートやマニュアルを読むか、サポート窓口に問い合わせて対応状況を確認することをお勧めする。
問題を起こしそうなのは、管理されていないフルサービスリゾルバーやミドルボックス
Conrad氏は、オープンセッションの中で「分かっている範囲は良いのだが、分かっていないところがある」とも述べている。ここにも、大きなポイントがある。問題を起こしそうなものの多くが、管理されていないフルサービスリゾルバーや何らかのミドルボックス[*5]だと予想されるからだ。
では、管理されていないフルサービスリゾルバーやミドルボックスとは何なのか。フルサービスリゾルバーについては、ざっと考えても以下のような状況で作られたサーバー上で動いているものが想定される。例えば、担当者が設定内容を理解せず、インストーラーのデフォルト設定そのままに設定されたサーバーでは、動いているフルサービスリゾルバーのDNSSEC検証が有効になっている可能性も十分に考えられる。そのため、過去の作業実績を調べ、徹底した見直しをすべきであろう。
- 業者が設置してそのままになっているサーバー
- 学校などで昔、誰かが設定し、そのまま使われているサーバー
- インストーラーによるデフォルト設定のまま使っているサーバー
もう一方のミドルボックスについては、Conrad氏が説明で述べたものを記載する。これらのミドルボックスは、大きなDNSパケットやIPフラグメンテーションを起こしたDNSパケットをきちんと処理できるかということが重要なポイントになる。
- ファイアウォール
- カスタマーの場所に設置されるルーター
- パケットフィルタリング装置
- 権威DNSサーバーとカスタマーエッジ（ネットワークの範囲）の間にある各種装置
DNSにかかわる技術者は、自身や自社が関係したサーバーで動作しているフルサービスリゾルバーを最新にし、その上で、サーバーから外部までのネットワーク上のミドルボックスの状況を確認すべきだろう。
フルサービスリゾルバーで大きなDNS応答を受け取れるかは、例えば以下のサイトで確認できる。一番右側のコラムの4つ目までが緑色であればテストにパスしているので、9月19日のDNS応答サイズの増大については安心していいだろう。
DNSの大切さは、もっと知られた方がいい
DNS（Domain Name System）は、インターネットにとって重要な基盤技術の1つである。インターネットでは通信相手は最終的にIPアドレスで指定されるが、IPアドレスはネットワーク側の事情で変更される可能性がある。そのため、相手を指定したり自分のアドレスを相手に教えたりするのには、ドメイン名のほうが都合がよい。この「ドメイン名」を、いつでも、そしてどこでも使えるようにするために、DNSは無くてはならない存在なのだ。DNS無くして、いまのインターネットは存在しえないと言えるだろう。
また、利用者から見た場合、フルサービスリゾルバーが使えないのは、インターネットそのものが使えないことと同じになる。名前解決により、通信相手のIPアドレスを得るということができなくなるからだ。インターネットの基盤を支える仕組みだからこそ、DNSの大切さはもっと知られたほうがいい。筆者はそう考えるが、いかがだろうか。
DNSSECは、DNS応答を受け取った側が、「DNSレコードの出自（送信元で登録したデータであること）」と「完全性（データの欠落や改ざんのないこと）」を検証できるようにするための仕組みである。つまり、受け取ったDNS応答が「本当に正しい」ものかどうかを検証可能にすることで、DNSのセキュリティを向上させるための拡張機能である。
そのDNSSECは現在、普及途上であり、Google Public DNSや米国大手のComcastといった欧米の一部ISPを除き、DNSSEC検証の普及率は高くない。しかし、電子署名やS/MIME、PGPなど、セキュリティ確保のために重要な情報をDNSに載せるためのプロトコルはすでに標準化されており、それらの利用にはDNSSECによる保護が前提となっている。
DNSSECはインターネットにとって重要になっていく技術であり、2010年にDNSSECの運用が開始されてから初となる今回のルートゾーンKSKロールオーバーは重要なマイルストーンの1つなのである。
次回は、ルートゾーンKSKロールオーバーの概要を技術的に説明していく予定である。
[*1]……DNSSEC検証を行うリゾルバーのこと。リゾルバー（resolver）は名前解決（name resolution）を行うソフトウェアプログラムであり、代表的なものにフルサービスリゾルバー（キャッシュDNSサーバー）がある。
[*2]……DNSSEC検証を行う際に、信頼の連鎖の起点となる情報。バリデーターごとに設定される。
[*3]……フルサービスリゾルバー（JPRS用語辞典）
[*4]……RFC 5011：DNSセキュリティ拡張（DNSSEC）におけるトラストアンカーの自動更新（JPRSによる日本語訳）
[*5]……ミドルボックスとは、通信の間（middle）に位置する、通常のルーティング以外の動作をする装置（box）のことである。