 |
 |
記事検索 |
イベントレポート |
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
DNSシステムの最新動向を東京大・江崎浩教授らが解説 |
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
インターネットにおけるインフラの1つとして欠かせないDNSだが、最近はいわゆるフィッシング詐欺の手法の1つとして“DNSスプーフィング”や“キャッシュポイズニング攻撃”などが話題となっている。また、スパム対策技術の1つであるSPF（Sender Policy Framework）やDomainKeysなど新たなDNSの利用形態が現われており、DNSに求められる信頼性はさらに高まっている。 そんなDNSの最新動向について、「Interop Tokyo 2005」で10日、「DNSホットトピックス」と題したコンファレンスが開かれた。日本レジストリサービス（JPRS）の藤原和典氏、東京大学情報基盤センターの関谷勇司氏という実際にDNSを運用している2人に加え、コーディネータを務めた東京大学大学院情報理工学系研究科教授の江崎浩氏がさまざまな側面から解説した。 ● 現在のDNSサーバーソフトのパフォーマンスは？
シナリオとしてはENUMの場合を想定した2つのシナリオと、JPドメインのTLDを想定したシナリオの計3つ（詳しくは以下を参照）を用意して実験を行なったという。ちなみに試験用サーバー機としてはPentium 4 3GHzにメモリ2.5GB、OSはFreeBSD 4.11を用いている。 1）上位のDNS（Tier1）では1つのゾーンファイルに全てのIP電話のエントリを記述し（最大で約2億番号）、下位のDNS（Tier2）では1つの電話番号ごとに1つのゾーンを生成する。 この場合、Tier1ではdjbdnsを除く3ソフトが1,000万番号（2,000万エントリ）を保持した状態で2万～3万qps程度のクエリーに対応できるが、BIND系はデータのロード時間が5分ほどなのに対しNSDはロードに30分以上時間がかかるため、BIND8/9を用いてシステムを組むのが妥当だという。一方Tier2では、ゾーンファイルが1つのファイルにまとまっているdjbdnsが一転して有利となり、パフォーマンスでは劣るもののデータ読み込みの早さからBINDやNSDよりも適当であるとの結果が出たとのこと。 2）Tier1では電話番号の局番ごとにエントリを記述し（最大約15万個）、Tier2では局番ごとにゾーンファイルを生成してエントリ（最大1万個）を記述する。 この場合（Tier1は1と同様の結果なので省略）、Tier2ではBIND8のみが1万エントリのゾーンを1,000ゾーン読み込んだ状態で3万qps以上の性能を発揮したとのこと。NSDとBIND9もデータの読み込みそのものは1,000ゾーンまで可能だが、クエリーに対する応答時のメモリ消費の関係で500ゾーンを超えると応答性能ががくんと落ちるという結果が出ている（djbdnsはさらにそれよりパフォーマンスが低い）。 3）辞書から自動的に生成したドメイン名を利用して、各ドメインごとにネームサーバー2つ（各サーバーに対しIPv4アドレスを1つずつ指定）を記述する。 条件としては最初のTier1の条件に近いが、この場合ソフトの種類に関係なく約500万ドメインでメモリ量が4GB（32bit CPUマシンの限界）に到達するとのこと。応答性能も基本的にはTier1の時と同様の結果が出ているが、データのロード時間がソフトに関わらずほぼ同じ（100～500秒程度でばらつきはある）なのが異なる点となっている。 以上のデータを踏まえて、藤原氏は会場からの質問に対し「今から一般の企業の方がDNSを移行するのなら、お勧めはBIND9」との見解を語った。また、パフォーマンス面でも「CPUをOpteronに変えれば、500万～1,000万エントリの環境下で7万qpsぐらいの速度は出せる」と藤原氏は語り、万が一、前記の調査結果の環境でパフォーマンスが不足する場合でも、サーバー機を変更するなどの方法でさらなるパフォーマンス向上は可能だとの見解を示した。 ● 分散データベースとしてのDNSの将来像
江崎氏は「最近は『何でもかんでもDNSに入れてしまえ』という動きがあるが、そもそもDNSはインターネットに接続していないと使えないもの」と前置きした上で、分散データベースとして必要な6つの条件として「Location（位置）」「Duplication（重複性）」「Fragmentation/Aggregation（分割/集約）」「Failure（耐故障性）」「Function（機能）」「Scale（規模性）」を挙げた。この中でDNSは、Locationの透過性が不足している、Scaleの面で上位サーバーに負荷が集中しやすい構造になっているなど、分散データベースとして考えると不完全な存在であるとの見解を示した。 江崎氏は近年、RFC3650～3652で規定される「Handle System」など、DNSの代替を目指した新たなプロトコルやディレクトリサービスが複数登場してきていることを指摘し、「特に今後、アドホック環境への対応などを考えると、DNSを今後どうしていくべきか改めて考え直す必要があるのではないか」と参加者に呼びかけていた。 関連情報 ■URL Interop Tokyo 2005 http://www.interop.jp/
（ 松林庵洋風 ）
- ページの先頭へ-
|
