現実になってきたDNSSEC、しかし関係者は手探り状態？

　東京・秋葉原の富士ソフトアキバプラザで開催された「Internet Week 2010」で25日、DNSに関連する3つのセッションおよびBoFが行われた。今回は、それらの中から、DNSSECに話題を絞ってお伝えする。

●現実になってきたDNSSEC

　DNSSEC（Domain Name System Security Extensions：DNSセキュリティ拡張）とは、DNSの安全性を高める技術の1つで、検索を依頼した側が、受け取ったDNSレコードの出自と完全性（改ざんのないこと）を検証できるようにする仕組みのこと。そのような技術が脚光を浴びる理由は、インターネットの利用者を悪意のある第三者から守るために必要であるからに他ならない。

　現在のDNSは、その内部でやりとりされる情報を、基本的に正しいものとして扱っている。そこに目をつけ、利用者を悪意のあるサイトなどに誘導することを目的として、本物と区別がつかない偽造した応答をキャッシュDNSサーバーに送りつけるということが行われている。いわゆる、「キャッシュポイズニング攻撃」と呼ばれるものだ。キャッシュDNSサーバーがそうした偽の応答を受け取ってしまうと、そのサーバーの利用者が危険な目に遭うことになる。

　もちろん、悪意のある第三者はむやみに攻撃するわけではない。目的が金銭であるため、金融やEC関連サイトが主として狙われる。それを防ぐためには、偽の応答を排除しなければいけない。DNSSECは、そのための現実解として期待されている。

日本レジストリサービスの民田雅人氏

　午前中に行われた、日本レジストリサービス（JPRS）の民田雅人氏によるDNSSECの基礎から運用ノウハウまでを扱ったセッション「DNSSECチュートリアル～実践編～」は、そのタイトル通りに極めて現実的な話でまとめたものだ。その中でも重要なポイントは、いかにして確実な運用をしていくかという部分にある。何かあるたびに人間がいちいち設定していたのでは事故が起こる可能性が高い。自動化できる部分は極力自動化することが確実な運用を実現するために必要となるが、それをDNSサーバーソフトウェアである「BIND」でどのように行うかなどが詳しく説明された。

　また、うまくいくケースばかりでなく、失敗するケースやリスクなどにも言及した。DNSSECでは絶対時間を使用するため、系全体での時刻同期が必須であること。運用の際には、きちんとした手順を踏む必要があること。親と子の関係が今までとは比較にならないぐらい密接になることなどを挙げ、それに従わなかった場合にどのようなことが起こるかが示された。

　内容が具体的であったためか、質疑応答では会場からさまざまな質問が上がった。例えば、自動化をBINDの機能で行う場合と、有用なツールである「OpenDNSSEC」を使った場合の違いなどである。その回答としては、OpenDNSSECの方が細かな指定ができるが、インストールが大変である。結局は、管理・運用のコストとの兼ね合いなので、事情によって選択することになるというものであった。

　興味深い内容としては、DNSSECを後押しするものは「KIDNS（Keys In DNS）」かもしれないという話題である。KIDNSとは、デジタル証明書をDNSレコード中に格納するための技術提案である。これは、ドメイン名の一致が重要となる証明書では、DNSを使用してデジタル証明書を配布する方がよいのではないかという考え方から来ている。既存のモデルでは、あるCA局を信用すると、そのCA局によって発行される証明書全体が信用されることになり、特定の証明書だけを信用することができないという理由もある。

　従来は、DNS自体の信頼性が高くなかったこと、そして512オクテットのサイズ制限があったことなどがネックとなっていたが、DNSSECの導入が進み、それらの課題がクリアされつつあることで議論が活発になってきたようだ。

　いずれにしても、DNSSECの設定と運用には、技術力と正確なオペレーションが要求されることが明確になりつつある。従来のように、「とりあえず動く」というレベルで満足していると取り残されることになるかもしれない。

●関係者は手探り状態

　午後のセッション「DNS DAY」では、例年通り、多様な発表が行われている。その中の1つ「DNSSECアップデート」のパネルディスカッションでは、それぞれの所属組織を離れ、司会に石田慶樹氏、パネリストに山本功司氏、伊勢幸一氏、高田美紀氏、豊野剛氏が登場。関係者としての本音が語られた。

　冒頭で石田氏は、このディスカッションが事業者視点で、DNSSECに関する検討のための材料を提供することを目的としてることを宣言し、「やることのメリットは少ないが、やらないことによるデメリットが大きい」ことの説明を行った。

　パネルのトップバーターは、山本氏。その立場をキャッシュDNSサーバー運用者として考えを述べた。それを要約すると、次のようになる。

　まともに運用されているキャッシュDNSサーバーであれば必要なアップデートなどはされているはずなので、すでにDNSSEC対応になっていると考えられる。そうであれば設定などはむしろ簡単だし、それなりのCPUを使っていればリソースがすぐに切迫するとは思えない。その意味では、すぐに署名検証（バリデーション）を有効にしてもいいような気がするが、よくよく考えるとそうでもない。

　その理由は、DNSSECの導入当初は多くのゾーンで設定不備や鍵更新（ロールオーバー）の失敗などがあることが想像されるからだとする。ISPのキャッシュDNSサーバーで名前解決に失敗すると、大多数のユーザーにとって「インターネットが使えない」とか「ネットが落ちた」状態に見えることから、トラブルシュートやカスタマーサポートが大変になってしまう。そのため、バリデーションをするキャッシュDNSサーバーをオプトインで要望する顧客に提供するとか、主要なトップレベルドメイン名で鍵更新が無事に終わったことなどを見ながら時期を待つかという選択をすることになるのかもしれない――。

　続いて、伊勢氏が権威DNSサーバーの運用者として考えを述べた。要約すると、次のようになる。

　権威DNSサーバー側では、DNSSECを導入することで、設備投資の増加、開発およびメンテナンスコストの増加、運用フローの複雑化といった負担が発生する。ミスによる被害は甚大だが、それに比してサービス提供による増収は見込めない。

　しかし、私たち自身もDNSSECを勉強し始めて、やっと最近になって具体的に理解できるようになったことを考えると、早めに始めて導入するリスクを把握し、導入しないリスクも把握することが重要ではないか。そこには、できないよりできたほうが強いということ、できない者の言うことには信憑性がない（「あなたができないだけでしょ」と言われるのが関の山）ということもある。レジストリとISPのキャッシュDNSサーバーが対応してから慌てふためくのは避けたいし、どうせやるのなら先駆者としてやると考えたほうがいいのではないか。今だったら何とかなる。本格導入が進んだあとでは言い訳ができない――。

　ここでの共通点は、導入当初は設定や運用で必ずミスが出る。それにどう向き合うかということを述べていることだ。実際、DNSSECで名前解決に失敗するとそのドメイン名にアクセスできなくなるため、その事態を想定し備えなくてはいけない。以降、各パネリストによる発言が重ねられ、会場からも多くの質問や意見が寄せられたが、その一部を紹介する。

　「どうしていいか分からずにスタックしている人がいるが、リスクとコストを考えて経営判断しなくてはいけない」「DNSSECは設定して終わりということではなく、サービスを提供し続ける限り継続的な運用となる。業務のフローとして作り込まないといけない」「永続的な管理をどのように行っていくか。付帯する業務も含めて考えるべき」「問題はオペレーター。誰かができるということと、会社としてできるというのは違う。人材の確保が重要になる」「今でも数多く存在する設定の不備（Lame Delegation）を抱えたままのドメイン名がどのようになるだろうかという心配がある」「キャッシュDNSサーバー利用者からお金は取れないが、権威DNSサーバーへのドメイン名登録者からいただくということは考えられないだろうか」「中途半端なところは、いっそのことDNSの運用を信頼できる事業者に任せるできではないだろうか」「導入のメリットよりも、導入しないリスクを考えるべき」

　DNSSECの導入は世界的な流れであり、それを無視することはできない。今回の話を総合すると、いずれは対応しなければいけないのだから、大変なことがあるとしても、早い段階から取り組んだほうがメリットを得られる。技術的には早くから経験を積み、事業継続性という観点から手遅れにならないようにすべきだろうと言うことができる。おそらく、今後はDNSを運用する事業者の力量が問われるようになるのは確実なようだ。DNSSECは、DNSの運用のあり方や、アウトソースなどのビジネス化を進めるきっかけになるかもしれない。