あなたのキャッシュDNSサーバー、DNSSECしてますか？

　DNSの安全性を高める技術の1つ「DNSSEC（DNS Security Extensions）」が、日本のドメイン名である「.jp」でも2011年1月に導入される。前回、DNSSECの仕組みについて解説したのに引き続き、これを導入するために必要な対応について、「.jp」の登録・管理を行う株式会社日本レジストリサービス（JPRS）技術研究部の民田雅人氏とシステム運用部の坂口智哉氏に話を聞く。

●DNSSECを導入するには、誰が何をすればいいのか？

　まずは、DNSSECに関係する人々と、その役割はどのようになっているのか見ていこう。その詳細を追うと、例えばICANN（Internet Corporation for Assigned Names and Numbers）やルートサーバー管理者など、かなりの広範囲を見なくてはいけなくなる（図4）。それでは複雑さが増してしまうため、ここでは少し限定した形でその点を確認していこう。

図4　DNSSEC対応が必要な関係者

　DNSの安全性が高まるということは、ドメイン名の安全性が高まるということと同義である。そう考えると、自分が使用しているドメイン名をより安全にしたいというドメイン名登録者と、自分がアクセスするドメイン名に正しく導いてほしいエンドユーザーという2つの面から見るのが分かりやすいと思う。

　まず、ドメイン名登録者の場合だが、最初にすべきことは、自分が登録しているドメイン名にDNSSECを導入するか否かを決めることだろう。不要だと思えば今まで通りでかまわないが、DNSSECを導入すると決めた場合には、自分が登録しているドメイン名の権威DNSサーバー管理者に対して、DNSSECに対応してもらうよう依頼する必要がある。自分が利用しているホスティング事業者やSIerのサービスがDNSSECに対応しているか、提供されるサービスがどのようなものなのかといったことを含めて考えるといいのではないだろうか。

　では、DNSSECを導入するか否かをどのように判断すればいいのか？

　「基本的には、自分が登録しているドメイン名を利用するユーザーをどの程度まで守る必要があるかが基準になると考えていいと思います。例えば、顧客を偽のサイトに誘導されてしまうとどれくらい困るかということですね。個人情報やお金を扱うようなサイトを運営しているような場合には、積極的に検討してみてください。」（坂口氏）

　DNSの運用を外部に委託している場合は、その委託先と相談して任せる形になるが、企業や大学、ホスティング事業者など自前で権威DNSサーバーを運用している場合は、管理者がすることは意外と多い。

　暗号鍵として使う秘密鍵と公開鍵の生成と管理、秘密鍵を使った当該ドメイン名のゾーンへの署名、公開鍵の公開、上位のドメインへの鍵の登録、定期的な暗号鍵の更新とそれを用いたゾーンへの再署名、暗号鍵の切り替えに伴う整合性の確保など、かなりの作業量になる。自社運用の場合や、ホスティング事業者のように業務として多数の顧客を持っている場合では事情は異なるとは思うが、場合によっては自動化するための仕組み作りなどを考える必要も出てくるだろう。

株式会社日本レジストリサービスシステム運用部の坂口智哉氏「DNSSECは、インターネットを支える重要な基盤の1つであるDNSを安全にするものです。また、関係者も多岐に渡るため、JPRSとしても『DNSSEC.jp』のような他の組織とも連携して事に当たっていきます。皆さまのご理解とご協力をお願いいたします」

　次に、エンドユーザーの場合だが、必要なのは、自分がDNSSEC導入の恩恵に与ることができるか否かを知ることだろう。現状では、ユーザー自身が特に何かをしなくてはいけないということは無いようだ。

　「現在導入が進みつつある形は、DNSSECの検証をキャッシュDNSサーバーにおいて行う形であり、アプリケーションでの対応が必要ないため、ユーザーが特に何かをしなくてはいけないということはありません。将来的に、EV-SSLで用いられているようなアドレスバーに緑色を表示するというようなことをユーザー側の環境でするのであれば、例えばブラウザー側でDNSSECの検証を行う必要が出てくるかもしれませんが、現状ではそこまで求められていません。今のところは『何もしなくてよい』と言ってかまわないと思います。ただし、自分が使うことになるキャッシュDNSサーバーがDNSSECに対応しているかどうかは知っておくことと、DNSSECに対応していない場合にどうするか（他に移るなど）は自分の意志で決める必要があります。」（坂口氏）

　最後に、キャッシュDNSサーバー管理者の対応だ。

　「キャッシュDNSサーバーの管理者がすることは、DNSSEC対応のDNSサーバーソフトウェアを使い、DNSSECの検証機能を有効にし、ルートゾーンの公開鍵を得て設定するといった作業です。最近のDNSサーバーソフトウェアであれば、大抵はDNSSEC対応済みです。キャッシュDNSサーバーの側では、それほど多くの設定を必要とするわけではありません。ただし、DNSSECを導入すると検証処理のためにDNSサーバー自体の処理能力がより必要となります。権威DNSサーバーとやりとりする情報量も数倍になりますので、ハードウェアの増強が必要になる可能性も含めてパフォーマンスを検討することになると思います。」（坂口氏）

　DNSSECに関する有用な技術情報は、JPRSでも「DNSSEC関連情報」（http://jprs.jp/dnssec/） などで公開している。そちらも併せて参照いただきたい。

●厳格に管理されるルートゾーンの署名

　「.jp」以外でも、世界的に見れば、すでにDNSSECを導入済み、あるいは導入作業に着手したトップレベルドメイン（TLD）が増えてきていると言える。「.org」は導入済み、「.net」「.com」も2011年第1四半期の導入を予定している。

株式会社日本レジストリサービス技術研究部の民田雅人氏「DNSは、普段から縁の下の力持ち的な存在ですが、こういう機会にでも、ちょっと気にしていただけると嬉しく思います」

　ルートゾーンではすでに、協定世界時の2010年7月15日（日本標準時では7月16日）にDNSSECの正式運用が開始された。それに際して、ルートゾーンに署名する一連の厳格な手続きがキーセレモニーとして公開された。民田氏は、このキーセレモニーにTCR（Trusted Community Representatives：信頼されたコミュニティの代表者）として参加している。

　「ルートゾーンは、ICANNが管理し、実運用は米Verisignが行っていますが、そもそもルートはみんなのものであり、一部の誰かだけで何かをできてしまうようなことは避けなければなりません。暗号鍵が不正に使われては困るわけです。そのために、世界のインターネットコミュニティから信頼される代表が選出され、それぞれに役割が割り当てられました。TCRは、14人のCrypto Officersと7人のRecovery Key Share Holders、そしてBackup Crypto Officersの7人とBackup Recovery Key Share Holdersの6人を合わせた34人で構成されます。」（民田氏）

　民田氏は、このTCRの1人として選出されたわけだ。

　「私自身はCrypto Officers for the US West Coast FacilityとしてルートゾーンへのDNSSECの導入に伴うHSM（Hardware Security Module：DNSSECに使用する鍵を生成・保管する機器）を稼動させる役割を担当します。もちろん、私1人ではHSMを稼働させることはできず、稼働させるためには東西の拠点で、7人ずつ居るCrypto Officersが預かる鍵のうちの3つ以上が揃わないといけません。ここまで厳格にするのは、ICANNとして『ルートはみんなのもの』という姿勢を大事にし、明確にする目的を含んでいると考えています。」（民田氏）

　民田氏は、TCRに選出されたことについて「光栄なことだと思うし、責任も感じている」と語る一方、実際にキーセレモニーに参加した感想として、実に細かい手順まで規定されており、1つ1つのステップが確実に行われたかどうか確認しながら進行していくことに驚いたという。

　「電話やパソコン、デジカメなどの電子機器の持ち込みも一切禁止された一方で、キーセレモニーの様子はインターネットで世界に向けて中継されています。こうした管理の詳細は『ルートゾーンにおけるKSKの管理方法』（http://jprs.jp/dnssec/doc/root_tcr.html） などに記述してありますので、ご興味があればご一読ください。」（民田氏）