JANOG26開催

DNSSECのインパクトは？オペレーター必携の「道具」とは？

2010/07/20

　7月8日、9日の2日間に渡って、インターネット技術者やネットワークオペレーターの集う「JANOG 26 Meeting」が東京・恵比寿にて開催された。インターネットを運営するために必要な情報交換やネットワーク事業者の課題についてディスカッションする場として開催されてきたものだ。

　26回目のミーティングとなるJANOG26では、IPv4アドレス在庫の枯渇を前にいよいよ注目が集まるIPv6の導入、運用にまつわる話題から、インターネットエクスチェンジ（IX、通信事業者の接続点）の取り組みを紹介するパネルディスカッション、あるいは国際化ドメイン名などネットワークオペレータ以外にもかかわってくる話題があれば、一方で国際通信を支える海底ケーブルをテーマにしたセッションがあるなど、多岐にわたった。

　この記事ではその中から、導入が進みつつあるDNSSECが及ぼすインパクトを紹介した「動かしてみましたDNSSEC」、そしてエンジニアにとって最も身近な「道具」を取り上げた「見せます。わたしの道具箱」の内容を紹介する。

DNSSEC導入のインパクトは？

　DNSSEC（Domain Name System Security Extensions）は、DNSサーバが返答する情報の確実性を保証するために生まれた仕様だ。DNSサーバが返す応答に署名を加え、その内容が確かにDNSサーバから出され、しかも改ざんされていないことを証明する。

　DNSは、IPアドレスとドメイン名の変換を行ってインターネットの根幹を支えている。だが、2008年に指摘されたDNSポイズニング攻撃によって、DNSに根本的な問題があることが明らかになった。この攻撃では、DNSキャッシュサーバの情報を書き換えることで、ユーザーがそれと知らないうちに、目当てとは別のサイトに誘導される恐れがある。だがDNSSECを導入すれば、DNSキャッシュポイズニング攻撃などを根本的に防ぐことができる。

　DNSSECの仕様自体は以前から存在し、BIND9では早くから対応していたが、なかなか導入が進んでいなかった。しかし2010年以降、少しずつ浸透し始めている。7月15日には、ルートサーバがDNSSECの運用を開始することになった。また、.jpのほか、.comや.netなど主だったTLDも、2010から2011年にかけての導入を計画している。

　ただ一方でDNSSECには、署名が付加される分、既存のDNSに比べてパケットサイズが増大し、結果としてサーバへの負荷が高まるといった課題が指摘されていた。「動かしてみましたDNSSEC」では、JPRS（日本レジストリサービス）が主催し、複数のISPやベンダが参加して行われた「DNSSEC 技術実験」の結果を踏まえ、サーバにどの程度のインパクトが加わるのか、具体的な数値を紹介した。

左からJPRSの民田雅人氏、NTTコミュニケーションズの濱口一真氏、NECアクセステクニカの川島正伸氏

　NTTコミュニケーションズの濱口一真氏は、DNSSEC技術実験で、キャッシュサーバ側でDNSSECを実装した場合の検証結果を紹介した。キャッシュサーバの環境は、Intel Xeon E5405 2GHZ（4コア）、メモリ8GBというもので、DNSソフトにはBIND 9.7.0-p2を使用し、約20万クエリを流し続けたときにどの程度の負荷がかかるのかを検証した。

　この結果、DNSSECの署名のある、なしで、CPU使用率に明らかに差が生じた。メモリ使用率も同様で、「同じクエリを投げているにもかかわらず、約3倍メモリ使用率が増加した。物理的にメモリを増強しなければならないなど、いろんな懸念が出てくる」（濱口氏）。1クエリ当たりのデータサイズ自体も大きくなるため、帯域についても同様に負荷が高まり、4倍という結果になった。また、JPRS側のサーバからDNSキャッシュサーバへのトラフィックだけでなく、逆向きのトラフィックも増大することにも注意が必要という。

　もちろんこれは、あくまで実験環境でのテストであり、一概にこのような負荷上昇が生じるとまではいえないが「データサイズが増大し、CPU使用率やメモリを圧迫することが判明」（同氏）。今回はシンプルな構成での検証だったが、今後、負荷分散装置など、現実に利用されている機器を挟んだときの挙動についても検証していきたいという。

　続いて、NECアクセステクニカの川島正伸氏が、SOHO向けおよび一般家庭向けブロードバンドルータ側の対応状況についてプレゼンテーションを行った。こういったブロードバンドルータの多くはDNSプロキシ機能を搭載しているが、これらが正しくDNSSECを処理できるのか、が論点だ。

　検証は、「DNSSECで用いられる各種フラグをきちんと処理できるか」「EDNS0に対応し、512バイト以上のパケットを処理できるか」「サーバからの応答にTCビット（Truncated bit）が立っていた場合、TCPへのフォールバックをきちんと行えるか」などの項目について実施された。

　結果、RFC5625（DNSプロキシの実装ガイドライン）に則ってきちんと処理を行える「イケてる実装」があった一方で、イケてない実装も見つかった。例えば、512バイト以上の応答パケットを512バイトで切り詰めてしまい、切り詰めたことを示すTCビットも立てないため、TCPへのフォールバックを行うことができない実装があったという。

注：なお、ブロードバンドルータなどを対象にしたDNSSECへの適合性を確認できるツールがNIC.CZにより公開されている（http://www.dnssectester.cz/）。

　いずれにせよ、「DNSSECがなくとも、IPv6の導入によるAAAAレコード増加や、その他レコードの増加により応答パケットサイズは肥大化傾向にある」（川島氏）ことは間違いないようだ。クライアント側がどれだけDNSSECのパケットを投げるかは未知数だが、ブロードバンドルータはRFC5625に従い、なるべくそれらを透過的に扱うように実装しておくに越したことはない。

　最後にJPRSの民田雅人氏が登場し、権威DNSサーバ側でDNSSECを実装したときの負荷について説明した。Xeon E5540 2.53GHz（×2）とPentium III 1.26GHzという2種類の環境を使い応答性能を比較したが、通常のDNSよりもDNSSEC、それもNSEC方式よりもNSEC3方式の方が、サーバの処理能力が落ちることが明らかになった。具体的には、存在する名前を応答する場合で平均で10～20％、特にNSEC3方式を用いて不在応答を返す時には50％以上処理能力が落ちる結果になったという。同時に、権威DNSサーバからのDNS応答パケット自体のサイズが5～8倍程度に増加することも見えた。

　今後、主要なTLDでDNSSECの普及が進めば、やり取りされるパケットサイズが増え、「上位のルータの帯域がもたなくなる可能性もある。いち早く仕様設計や帯域などを見極めていく必要がある」と民田氏。「早めにやっておく方が負荷が少なくて済むと思う。後からやろうとすると大変」（同氏）と、改めて対応を促した。

優れものの道具を披露、「見せます、わたしの道具箱」

　ネットワークオペレータの仕事は、コンソールの前に座ることだけではない。時には空調の効いたデータセンターの中で、サーバを設置してネットワーク機器とつないだり、あるいは炎天下の屋外でケーブルを張り巡らしたり……といった肉体労働を強いられることもある。

　そんなときに作業をスムーズにしてくれる優れものの「道具」とは――JANOGのメーリングリストで盛り上がっていたこのテーマが、ミーティング会場に登場。登壇者がそれぞれ自慢の「道具」を持ち寄って披露した。

イッツ・コミュニケーションズの芦田宏之氏、ブロケードコミュニケーションズシステムズの菊池之裕氏、佐野務氏、ハートビーツの馬場俊彰氏

　イッツ・コミュニケーションズの芦田宏之氏は「現物を持ち込むので、いざというときのことを考えて現場に近い東京開催を狙って企画した」といいながら、持参の道具袋を紹介した。

　その中には、パッチパネルに多数の光ケーブルが接続されているときでも目的のケーブルだけをつまめるピンセット状の道具や、少し離れた場所からでも作業を行える、ちょっと長めのUSBケーブルなどが収納されているという。また、手を怪我しないためのグローブ、怪我をしてしまったときに備えたばんそうこう（実際には、持ち歩いていないときに限って怪我をするというが……）なども必須だそうだ。「大袋、小袋に分けて必要な物をまとめるのがコツ」（芦田氏）とか。

　続くブロケードコミュニケーションズシステムズの菊池之裕氏がまず取り出したのは、7インチのXGAモニタだ。「USB接続のものと違って影響を与えないので、Linuxなどの出力を見るのに意外と重宝する」そうだ。ほかに、外部通信を行うためのポータブルWi-FiにUSBキーボード、マウス、そしてもう1つ取り出したのがiPad。この上でターミナルソフトのiSSH、myRoutersProを動作させて接続確認に使っている。

　佐野務氏は、UTPケーブルの被膜を取るケーブルストリッパやケーブルチェッカなど、「現場の匂い」のする工具もろもろを紹介した。現場ではこれを、帆布製のバケツ状バッグに入れて持ち歩くのが便利だという。

　「ドライバでねじを駄目にした経験、ありませんか？　ねじに合っていないものを無理やり使って駄目にする場合が多い。まず仕様を考えて、それに合った道具を考えることが大事。これは何にでも応用が利くこと」（佐野氏）。

　最後の馬場俊彰氏（ハートビーツ）は、GNU Screenとイー・モバイルによる接続環境が必須だと述べた。トラブルは場所も時も問わずにやってくる。「駅のホームで障害対応したことある人、いますよね？」（馬場氏）。

　馬場氏はまた、iPhoneにターミナルソフトの「TouchTerm」を載せ、データセンターなど現場での動作確認に活用しているという。ほかに、VirtualBoxやKVMをベースにした仮想環境を開発、検証用に使っているほか、Dropboxの有益な使い方も紹介した。ここに.bashrcや.emacsを置いておき、作業対象のサーバに放り込めばすぐに立ち上がるという優れ技である。