Webシステム運用担当者のこれからのテーマの一つが、DNS（Domain Name System）の運用になることは間違いないだろう。DNSサーバーが管理するドメインの情報を勝手に書き換える「DNSキャッシュ・ポイズニング」への対策が求められるようになるからだ。これは一筋縄ではいかない。

　DNSは「nikkeibp.co.jp」などドメイン名から「202.214.174.229」といったIPアドレスを検索するシステムで、インターネットの根幹をなす。ルートドメインを頂点に、末端のDNSサーバーに至る階層構造を構成している。それぞれのDNSサーバーはキャッシュを保持することで、クライアントからのリクエストに対する素早いレスポンスを実現するのだが、そのキャッシュを書き換えてしまうのが、DNSキャッシュ・ポイズニングという攻撃である。

　DNSのぜい弱性が注目されるきっかけとなったのは、2008年7月にダン・カミンスキー氏が国際セキュリティ会議「Black Hat」で行ったプレゼンテーションである。カミンスキー氏は、DNSのぜい弱性を突くことで、クライアントからのアクセスを偽のIPアドレスに誘導できることを明らかにした。俗に「カミンスキー攻撃」と呼ばれるこの手法は反響を呼び、同年9月には国内でもIPA（情報処理推進機構）が注意喚起を行っている。実際に被害が発生したとの報道もある。

　カミンスキー攻撃を防ぐのに、まずやらなければならないのがDNSサーバーに対するパッチの適用と設定変更である。BINDをはじめDNSサーバーはそれぞれパッチを提供している。多くのWebシステム運用担当者は既に実施済みだろう。だが、これは一時しのぎに過ぎない。「DNS＆BIND」（オライリー）の共著者でDNSに詳しいクリケット・リウ氏（米Infoblox アーキテクチャ担当副社長）は「DNSSECの実装が不可欠だ」と指摘する。

　DNSSECとは「DNS Security Extension」の略で、DNSのセキュリティ拡張機能である。クライアントからのリクエストに対する応答を秘密鍵で署名した上で返し、クライアントはそれを公開鍵で検証する（詳しくはこちら）。

　カミンスキー氏のプレゼンから1年半が経ち、米国では政府のシステム（.gov）を中心にDNSSECの導入が始まっている。また、ルートドメインは2010年7月1日までに対応することになっており、ccTLD（country code Top Level Domain）でも「.se（スウェーデン）」「.cz（チェコ）」「.ch（スイス）」「.li（リヒテンシュタイン）」「.th（タイ）」などが既に対応済み。「.jp」も2010年12月までに対応する予定だ。今、DNSSEC対応が着々と進められているところなのである。

　最終的には、DNSを構成するすべての階層でDNSSECを導入することが求められる。現時点ではまだ導入の実数は少ないと見られるが、2009年のDNSSECの導入は前年比で400％増えたとする調査結果もある。ここへ来て急激に増えているのだ。

　DNSSECの歴史は90年代にさかのぼる。しかし、今日に至るまで本格的な導入の動きはなかった。10年以上も放置されてきた理由は、放置してもあまり支障がなかったこともあるが、何より運用が煩雑になるからである。「運用の手順はNIST（National Institute of Standards and Technology：アメリカ国立標準技術研究所）のガイドラインに示されている。その分量は16ページにのぼり、公開鍵は定期的に交換する必要がある」（リウ氏）。NISTのレコメンデーションでは、デフォルトで30日ごとに鍵を交換することになっている。しかも、手順の途中で待ち時間が発生するなど、それぞれの手順の意味を分かっていないと設定ミスを起こしやすい。

　InfobloxなどDNSの運用を簡単にする製品も登場している。それらを導入するのも一つの手だろう。いずれは対処しなければならない課題だ。DNSの見直しは早いに越したことはない。