特別企画
ネット史上初めての「KSKロールオーバー」が始まる、名前解決できなくなる前にDNSサーバーなど設定確認を！ 今年9月は特に注意
「Internet Weekショーケース in 名古屋」の発表から
2017年6月22日 12:00
DNS（Domain Name System）は、階層別にドメイン名とIPアドレスを変換（名前解決）することで、インターネットのアクセスを可能にしている。このDNSの一番上位の階層にある「ルートゾーン」の設定に対し、それを管理するICANN（The Internet Corporation for Assigned Names and Numbers）が今年の夏から来年の春にかけて重要な更新を実施する予定だ。これにともない、インターネットの名前解決にも支障をきたす＝インターネットに接続できない状況が起こりえる可能性もあるという。
このような問題が発生すると一般のインターネットユーザーにまで波及する可能性があるが、この事実をどれだけ多くのネットワーク運用者が認識しているだろうか？ 認知がまだまだ行き届いていないこともあり、一般社団法人日本ネットワークインフォメーションセンター（JPNIC）の主催で6月1日に開催したカンファレンス「Internet Weekショーケース in 名古屋」でも、これに関する注意喚起を行った。
同カンファレンスにおける米谷嘉朗氏（株式会社日本レジストリサービス）と末松慶文氏（九州通信ネットワーク株式会社）の発表をもとに、今後どのようなことが起こるのか、どんな対策が必要か、詳しく解説していきたい。
ルートゾーンにどんな変更が加えられ、誰に影響するのか？
通常、DNSの応答が詐称されると、偽のウェブサイトに誘導されたりメールを横取りされたりしてしまう。それを防ぐために考えられたのが、電子署名を用いてDNSの応答が正しいことを検証する「DNSSEC」だ。DNSSECでは、ルートゾーン情報の電子署名鍵（KSK：Key Signing Key）の公開鍵（トラストアンカー）を持てば、誰もがルートDNSサーバーからのDNS応答の正しさを検証できる。
今回、ICANNによって行われるのは、このルートゾーン情報に対するKSKを、一連の作業によって更新（ロールオーバー）するということだ。
ルートゾーンには、ルートゾーンのレコードに署名する鍵（ZSK：Zone Signing Key）と、そのZSKに署名するKSKとがある。ZSKは3カ月に一度更新されているが、KSKは今まで一度も更新されたことがない。本来は5年に1回更新することになっているのだが、ルートゾーンにDNSSECが導入されてから7年、今回初めて更新がなされる。今までに誰も経験したことがない更新であるために注視が必要であり、世界中の関係者によって、この2年間、非常に綿密にKSKの更新について計画がなされ、やっと実施できる段階に入ってきたとのことだ。
「うちはDNSSECを使っていないから大丈夫」と侮るなかれ。DNSSECを利用していなくても影響を受けるのだ。
では一体、どのような影響が、誰に対してあるのだろうか？ 影響を受ける対象者は、大きく分けて次の3タイプがあるという。
- DNSキャッシュサーバー（フルリゾルバー）の運用者
- 権威DNSサーバーの運用者
- 顧客のネットワークを運用しているシステムインテグレーター
「IPフラグメント」で名前解決が出来なくなる可能性、その確認方法とは
次に、KSKの更新によって、どんな影響が出るのか？ 1つは、DNSの応答の「IPフラグメントが発生する」ということだ。
IPフラグメントが発生し、パケットが欠落するなどすると、DNSSEC検証の有効・無効問わず、名前解決ができなくなる。ルートの名前解決できないと、そこから先の名前解決も失敗するため、ユーザーからするとインターネット全体が使えないように見えてしまう。
このIPフラグメントは、DNSSECの公開鍵（DNSKEY）を含むパケットが、鍵の更新中には応答サイズが通常の倍以上に増加するために起こる。扱える応答サイズは512バイトというのが1つの壁だということだが、「512バイト以上のUDPパケットを扱えるか、すなわち、EDNS0に対応しているか」、また、「IPフラグメントしたUDPパケットを扱えるかどうか」が肝になるということだ。
DNSSEC検証を有効にしているDNSサーバーの運用者の場合は、さらに注意が必要だ。IPフラグメントにより、DNSKEYが受け取れなくなる可能性もあったり、トラストアンカーが更新されなかったりする可能性が出てくる。それによっても名前解決はできなくなる。
特に、ユーザーを抱えている企業や組織にこれが起こると大変困ったことになる。そのため、それが起こるのかどうかを、今すぐに、そして後述する重要ポイントの「事前に」確認することが本当に必要だという。IPフラグメントで名前解決に成功するかしないかは、次の方法で簡単に確認できるとのことだ。DNSパケットが通るすべての通信経路を確認して、可能な範囲で検証することが必要である。
- ウェブでの確認方法「DNSSEC Key Size Test」
（このサイトでチェックをし、チェックボックスの4つ目まで緑だったらOK） - コマンドラインでの確認方法
dig +bufsize=4096 +short rs.dns-oarc.net txt
ここで不具合があったというときに、何をすべきなのだろうか？
IPフラグメントは、DNSサーバーと関係ないネットワーク中継機器で起こる。どこで失敗しているかの特定は、ネットワークの構成が実にさまざまなケースがあるため、複雑かつ責任分解点も難しいところだという。確認のポイントとしては、自分の近いところから、ハードウェアとソフトウェアの両面から見ていくこと。後述する重要な日付で実際に問題が起こったときには、各ベンダーのサポートを即座に受けられないなど、問題の解決に時間がかかる可能性がある。今の段階でベンダーやシステムインテグレーターと確認し、それでも原因が分からない場合には、上位のISPに相談するなどが有効だ。手順については確立したものがあるわけではないので、もしそういう知見を得た場合には、いろいろな場やコミュニティでシェアするのもよさそうだ。
ちなみに、IPv6ではOKだけれど、IPv4だったら問題があったなどという例もあるそうなので、両方のトランスポートでテストをやってみて欲しい。
問題はいつ起こるのか？
さて、KSKロールオーバーがいつ実施されるかということだが、来月7月1日から、来年の3月31日までに一連のプロセスとして実施されるとのことだ。実際に鍵が更新されるのは10月11日。詳しくは以下のスライドを見て欲しい。
IPフラグメントが起こるのは10月11日のタイミングではなく、スライド左側の赤で囲んだところが重要なポイントである。9月19日に、DNSKEYを含んだ応答が1400オクテット（1400バイト）を超え、ここでIPv4/IPv6ともにフラグメントが起こってくる。10月11日には鍵が更新されるが、DNSサーバー自体に何か不具合があると、この時点で「あっ」ということになる。なお、12月20日や2018年1月11日は、9月19日を乗り越えられれば特に問題ではないとのことだ。
トラストアンカーの更新によって起こる影響
今回は、鍵長と鍵のアルゴリズムの変更はない。KSKロールオーバーの実施は前述の通り初めてのことであるが、もしアルゴリズムロールオーバーも同時に行われた場合もっと複雑だった可能性があるので、今回は不幸中の幸いと言える。
トラストアンカーの更新で影響を受ける対象としては、DNSSEC検証を有効にしたフルリゾルバーの運用者である。トラストアンカーの更新に失敗した場合、署名検証が失敗し、名前解決できなくなるためである。
トラストアンカーを更新する方法は、手動更新、RFC5011に基づく自動更新、BIND9の機能であるdnssec-validationオプションをautoにすることで更新を行うなど複数の方法がある。
トラストアンカーの更新にあたってまずは確認して欲しいのは、BIND9の場合、named.confのところのオプション。dnssec-enableオプションがyesなのかnoなのか見てもらいたい。また、dnssec-validationオプションに関しても、yesなのかnoなのかautoなのか確認する必要がある。最近のBIND9では、両方ともyesがデフォルト。「うちはDNSSECを使っておらず影響ない」と思い込んでいたとしても、実際は設定が有効になっているケースがあると聞いている。ぜひ確認してもらいたい。
dnssec-validationがautoの場合、BINDに含まれる鍵を用いて確認するので、新しい鍵かどうかを確認してほしい。 基本的にはnamed.confで指定しているbind.keysファイルが更新されているかどうか確認していただきたい。なお、最新のbind.keysは以下のページで公開されている。
このほか、Negative Trust Anchor（NTA）というものがある。これは、指定したドメイン名のDNSSEC検証をしないようにする機能だ。最新のBIND 9.11や有償のサブスクリプション版でこの機能が使える。しかし、この機能は有効となる時間に限りがあり、デフォルトでは指定してから1時間、設定変更したとしても1週間が最大となるため、永続的に使えるわけではないので注意が必要だ。
また、nta-recheckという機能があり、NTAで指定したドメイン名に対して定期的にDNSSEC検証を行い、結果に問題なければNTAの設定を自動的に解除するので、注意が必要だ。ただ、この機能を無効にすることもできる。また、フルリゾルバーとして、BINDではなくUnboundを使うことも増えてきたが、このUnboundでもNTAは実装されている。DNSSEC検証が有効な環境であれば、トラブル対応に備えるという意味でNTAの利用方法は要確認だ。
その他の注意点としては、DNSSECで問題が発生した時にすばやく検知するため、普段からキャッシュサーバーを監視し、各種統計情報をとることが重要だ。普段からDNSSEC検証の失敗数を監視するなどトレンドを把握し、有事のときに短時間で対応できるようにしたい。スタブリゾルバーからルートゾーンのDNSKEYを問い合わせ、署名検証が問題なくできているかどうか監視することも重要だ。また、万が一に備えて、NTAのようなDNSSEC検証を停止する手順を整備しておくのも大事。さらにはフルリゾルバーの予備機をコールドスタンバイにしている場合には、当然トラストアンカーが更新されないため、注意が必要とのことだ。2015年開催の「Internet Week 2015」でも、鍵の更新方法についてプレゼンがあったので参考にしてほしい。
- 今日から始めるDNSSECバリデーション
（この中の「Root KSK（鍵署名鍵）更新に対応する方法」配布資料を参照）
最後に
いろいろな知識がないとKSKロールオーバーの対応は大変だが、情報はそろってきているとのことなので、適宜、前述の資料も確認して欲しい。繰り返しになるが、重要な日付を迎える前に事前確認と準備を確実に行うことが必要だ。準備をしておけば憂いなし。そうした対策を自組織で進めていただきたい。