イベントレポート
Internet Week 2013
新gTLDに伴う.home/.corp問題、オープンリゾルバーなど2013年のDNS総ざらい
（2013/12/4 14:00）
東京・秋葉原の富士ソフトアキバプラザで開催された「Internet Week 2013」において11月28日、DNS関連の最新情報を共有・議論するためのセッション「DNS DAY」が行われた。盛り沢山であったプログラムの中から、今回は「Name Collisionに関する話題」と「DNSの評価と計測の話」から選んだ2つの話題を中心にレポートする。
「DNS Update」に「DNSSEC Update」が追加
日本DNSオペレーターズグループ（DNSOPS.JP）代表幹事／日本インターネットエクスチェンジ株式会社の石田慶樹氏の司会で始まった「DNS DAY」最初のプログラムは、恒例の「DNS Update」。内容としては、ほぼ例年通りの「Root DNS Servers」「JP DNS Update」「逆引き/NIR update」「Cache Server Update 2013」「DNS Update～ドメイン名関連～」に加え、「DNSSEC Update」が加わったのが新しい。それだけ、各TLDにおけるDNSSEC対応が順調に進んできているということだろう。特に、新gTLDにおいてはIPv6とDNSSECへの対応は必須とされていることから、DNSSECに関係する情報はますます重要になっていくはずだ。
DNS Updateを通して目についたのは、ルートサーバーにおいて新gTLDの増加に対する影響がこれから顕在化してくるであろうこと、JP DNSにDNSリフレクター攻撃対策として「DNS RRL（Response Rate Limiting）」を導入中であること、キャッシュDNSサーバーへのユーザーからのクエリ（DNS問い合わせ）は引き続き増加傾向にあること、TLDにおけるDNSSEC対応が進んでいることといったあたりである。
求む、名前衝突に対する情報提供
続くプログラムは、ICANN理事のKuo-Wei Wu氏と一般社団法人日本ネットワークインフォメーションセンター（JPNIC）の奥谷泉氏による「内部ネットワークで利用している名前との衝突（Name Collision）」である。これは、新gTLDの導入により、例えば社内などで既存のTLDと重複しない前提で利用している名前との衝突が考えられることから、その情報提供を呼びかける目的で行われたものだ。
では、その衝突とはどのようなものなのだろうか。これは、ICANNによる新gTLDの審査から承認へのプロセスの中で新たに指摘された問題である。この話は少し分かりにくいので、例示を使った説明のスライドで解説していく。以下のスライドは、DNS-OARC（The DNS Operations, Analysis, and Research Center：DNSの運用・分析・調査研究などを通じ、DNSをより安全で高品質なものとすることを目的とした非営利組織）によるルートサーバーへの検索状況を示したものだ。
このスライドからは、.comや.netといった正規のgTLDに続いて、“.local”や“.home”といったインターネット上には存在しないはずのTLDへの名前検索が検索上位に来ているのが見てとれる。ネットワークの設定をした方であれば想像できると思うが、LANなどでローカルなドメイン名を設定しなければならない時、インターネットで使われていない文字列として“.local”や“.home”といった名前を使って設定したことはないだろうか。そして注目すべきは、スライドにある上位17件のうち、実に11件が存在しないTLDに対するものであり、しかも“.home”と“.corp”に至っては新gTLDとして申請されたドメイン名と衝突（Collision）しているという点である。
このように内部ネットワーク用に設定した名前と新gTLDが衝突した場合、内部ネットワークでの通信を前提とした情報が外部ネットワークで名前検索・参照されるようになることによる情報漏えいなどのセキュリティ上の影響や、名前解決そのものの動作に問題が生じる可能性がある。そのほか、内部での利用を前提として発行されたサーバー証明書が新gTLDの名前と一致した場合、証明書が証明するサーバーと同じ名前の全く別のサーバーがインターネット上に存在してしまうことになり、証明書の根幹にかかわる不適切な状況が発生してしまうことが懸念されている。
問題が発生した場合、利用者に最も認知されやすいものは、引きたい名前が引けなくなるという状況だろう。例えば、社内で.corpをローカルドメイン名として使っている時に.corpというgTLDの名前検索をしようとしても内部のネットワークの名前として識別されパブリックな名前空間を検索できない可能性があり、その逆の挙動も考えられる。一例を挙げると、Microsoftでは、同社のソフトウェアを利用した名前設定の例として“.corp”を使用している（「DNS 名前空間の計画」、http://support.microsoft.com/kb/254680）。この例に従い、この名前を自社のネットワークに利用している組織も一定数あると考えることもできる。加えて、この例以外にも、存在しないTLDを内部用として使用している組織が一定数存在する危険性も想定しておく必要がある。
もちろん、ここで述べたような影響が必ず発生するわけではなく、設定と環境に依存する面が多いこと、DNSに限らず、内部ネットワークと外部ネットワークを正しく認識せずに名前解決を行った場合、名前の衝突による問題が発生することは常にありうるということは知っておくべきだろう。内部ネットワークで利用されている名前が、インターネットのドメイン名として今後も存在しないとは限らないということもある。
こうした状況に対してICANNではすでに調査レポートを発表しており、リスク回避計画も発表している。また、上記の結果を反映して名前衝突のリスクが特に高いと考えられる“.home”と”.corp”の2つの新gTLDについて委任を無期限に保留することを決めたということである。
ICANNとしては、名前衝突の事例や影響について、観測できるパブリックな情報だけでは不十分だと考えており、何かしらの情報を持っている人からの連絡を広く受け付けているという。名前衝突の問題について知っている事例、現在実施している対策など、できる限り幅広い情報を提供していただきたいとのことであった。
オープンリゾルバー問題の解決はとても大変
3つめのプログラムは、「オープンリゾルバーに関する話題」である。インターネット全体への脅威となりえるオープンリゾルバーは無くすべきとしつつも、ここに登壇した方々の説明を聞く限りは、その実現は簡単ではないようだ。共通する課題として、過去の顧客が競合会社に移った後も設定を変えずにそのまま使い続けている、公式サービスとして運用していなかったはずのDNSサーバーが知らないうちにいろいろな人々に使われていたといった「自社の顧客でない人々による利用をどうするか」といったことが挙げられる。これは、古くからサービスを提供しているネットワーク事業者によく聞く話でもある。また、正規の顧客に対しても、社外にPCを持ち出した時に使うキャッシュDNSサーバーをどうするかといった点などがあるため、単純にフィルターを適用できないといった難しさがあるという話もある。
自社の顧客であれば連絡も取れるが、自社の顧客でない場合にはそもそも連絡を取ることが難しい場合も多い。正規の顧客ではないのに使えないことへのクレームが来ることや、関係しそうな事業者への事前通知など、上層部を含む所属組織全体を巻き込みつつ、長期戦を覚悟してオープンリゾルバーの段階的な閉塞を進めるといった、実担当者ならではの涙ぐましい苦労も語られた。
悪意がなく、知らずに使っていた利用者に不便を強いるのはできる限り避けたいという方針と、DDoS攻撃への悪用を避けるための適切なフィルターの適用をどこかで実施しなければならないという方針の落としどころはそれぞれの組織やISPの内部事情もあり、簡単には決められない。
DKIMによるDNS負荷はさほど大きくはない
DNS DAY最後のプログラムは、「DNSの評価と計測の話」。ここでは、その中から楽天株式会社／Japan DKIM Working Groupの安高元気氏による「DNSとメール―DKIM普及に伴うDNSの負荷影響―」と、日本レジストリサービス（JPRS）の阿波連良尚氏による「DNSの評価と計測の話―JP DNSへのRRLの導入―」の2つを取り上げる。
安高氏による発表は、DKIM（DomainKeys Identified Mail：電子署名方式の送信ドメイン認証）によるDNSの負荷の変化に着目したものである（実際には、DKIMに関する知識なども含めた広範囲な内容となっている）。社内に実験環境を作り、特にDNSについてどのような影響を及ぼすのかを実際に動作させて計測したということだ。
DKIMでは、送信側で電子メールに電子署名を付加し、受信側でその電子署名を照合するという方法でメールの認証を行う。署名に利用する公開鍵は、送信側のドメイン名を管理する権威DNSサーバーを使用して公開される。公開鍵は、FQDN（Fully Qualified Domain Name）に対するTXTレコードとしてDNSに登録され、受信側はメールを検証する際にDNS問い合わせにより公開鍵を得る。つまり、メールサーバーがメールの検証を行うたびにDNSに対する問い合わせが発生する。このことから、DKIMを使用するとDNSに対する負荷が上がるということを言われることがあるが、それはどの程度のものかということを確認することが目的の1つにあったという。
その検証の概要だが、DKIMの検証（Verify）のオン／オフ、2種類の鍵長（1024ビットと2048ビット）、512バイトを境とする2種類のパケットサイズ、そしてEDNS0のオン／オフを組み合わせたもので行っている。より具体的には、鍵長が長くなることによる影響を調べる「Case 1」と、鍵長のサイズが512バイトを超えることによる影響を調べる「Case 2」という形で、計5つのパターンを設定したということだ。そして、それぞれの状況下におけるキャッシュDNSサーバー単体の負荷影響を検証する。
実験の詳細はここでは解説しないが、結果を整理すると次のようになった。これらの結果は、ほぼ予想通りであり、個々の数字を見ても、キャッシュDNSサーバーに対して著しく負荷がかかるということはなかったと判断したということである。
- 鍵長が長くなるとレイテンシーおよびOutgoing Trafficが大きくなる
- 鍵長が長くなるとCPUの使用率は高くなる
- TCPフォールバックが起こるとレイテンシーが大きくなる
- 鍵長が512バイトを超えるとTCPフォールバックが起こりIncoming TrafficもOutgoing Trafficも増える
- EDNS0の処理が無いとCPU使用率は下がる
今後の課題として、実際の運用環境でのテストや、例えばBINDのバージョンによる差違の確認、異なるDNSソフトウェアの実装で試してみる必要があるということだが、少なくともキャッシュDNSサーバーに対する負荷はそれほど気にしなくてもよいのかもしれない。DKIMの導入に際し、DNSへの負荷上昇を心配している方々には明るい材料ではないだろうか。
応答制限よりも、応答生成の方が負荷が高い
阿波連氏による発表は、DNSリフレクター攻撃の概要と対策のおさらい、評価と計測の実例としてJP DNSサーバーへのDNS RRLの導入を説明したものだ。DNSリフレクター攻撃への対策としてはBCP 38（ingress filtering：イングレスフィルタリング、送信元を偽装したIPパケットの転送を防ぐ手法の1つ）の適用があるが、これは、インターネット全体での対策が必要となる。では、個々のDNSサーバーで対策するにはどうのようにすればよいのだろうか？ キャッシュDNSサーバーについては送信元IPアドレスに基づいてクエリの受け付けを制限するという対策を取ることが推奨されているが、権威DNSサーバーはインターネット全体をサービス提供範囲としているため送信元IPアドレスに基づく制限は行えない。そこで考え出されたのが、DNS RRLという対策である。
DNS RRLとは、DNSサーバーからの応答を制限するための技術である。下の図はDNS Updateの中でJPRSの水野貴史氏が示したDNSリフレクター攻撃への対応概念図だが、キャッシュDNSサーバーが送信元IPアドレスによる問い合わせのアクセス制限をするのに対して、権威DNSサーバーでは応答のレート（Rate）を制限する。簡単に言うと、同一とみなせるパターンの高頻度クエリに対して、単位時間あたりの応答の「回数」を制限したり、応答する「大きさ」を制限するということを行う。
DNS RRLが対象とするのは、送信元IPアドレスを詐称しやすいUDPによるクエリのみである。応答の回数と大きさを制限することで踏み台としての効果を小さくし、DoS攻撃の効果を低減することが目的だと言ってもいいだろう。阿波連氏によると、その導入にあたっては、事前に机上評価として、パラメータの調査と設定、挙動の理解、調整が必要なパラメータの洗い出し、各種パラメータの調整方針の決定と調整といったことを入念に行ったとのこと。もちろん、その後に続く機能面・性能面・運用面の評価を行う社内評価、影響を与えない状態での試験的な導入をするフィールド評価も十分に行っている。
では、DNS RRLの導入によって、期待する効果はどれほどあるのか、また、DNSサーバーにかかる負荷はどのように変化するのだろうか。結論を言ってしまうと、DNS応答性能を計測し、定められた処理性能を満たしていること、CPU使用率やメモリ消費の増加があらかじめ定めた基準値以下であること、長期間の動作でも問題が発生しないこと、通常クエリに対する応答が制限されないことのいずれもが確認されたという。応答制限については評価期間（1カ月）で8件のイベントを検出しており、クエリログの調査によってそのすべてが応答頻度を制限しても問題ないクエリであることが確認できたとのことだ。評価の結果、すべてのJP DNSサーバーに導入しても問題は発生しないと判断し、現在、各セカンダリ組織と協力してJP DNSに順次導入を進めているとのことである。
この報告の中で興味深い点は、以下に示したスライドにある性能評価のうちのリソース確認の部分、「応答を制限している状態では、RRLありの方がCPU負荷が低いと判明」と「応答制限よりも、応答生成の方が負荷が高い」と書かれている個所である。先の安高氏の発表の中にも「EDNS0の処理が無いとCPU使用率は下がる」という報告があったが、大きな応答を扱うことはDNSサーバーにとって処理コストが高いということだろう。
この結果から、DNS RRLのようにあらかじめ決められた所定のしきい値により単位時間あたりの応答の「回数」を制限したり、応答する「大きさ」を制限することはDNSサーバーにとって負担になるとは限らないということが明確になったとも言えるのではないだろうか。今や、権威DNSサーバーの管理においてDDoS攻撃の踏み台にされるリスクを考慮することは必須とも言える状況であり、その対策に頭を悩ませている管理者の方も多いことだろう。繰り返しになるが、阿波連氏の「応答を制限している状態では、RRLありの方がCPU負荷が低いと判明」と「応答制限よりも、応答生成の方が負荷が高い」という報告は、権威DNSサーバーへのDNS RRLの導入を検討している人々にとって重要な情報となるに違いない。