JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト


ドメイン名関連会議報告

2007年

RIPEがICANNに対し、公式にDNSルートゾーンへの署名実現を要請へ

~ RIPE 54 Meetingの話題から ~

2007/06/04

RIPE 54 Meeting(以下、RIPE 54)が2007年5月7日から5月11日までの5日間にわたり、エストニアの首都タリンで開催されました。会場となったSokos HotelViruは旧市街に隣接した近代的なホテルで、旧ソ連時代にKGBが諜報活動の拠点に利用していたという噂もあり、会期中の話題のひとつとなっていました。

今回のRIPE 54にはヨーロッパ地域のネットワーク関連の専門家を中心に、約300名ほどの参加がありました。前回のFROM JPRSで取り上げたCENTRがヨーロッパ地域におけるccTLDレジストリの連合体であり、参加者間の議論と情報交換の場であるのに対し、RIPEはより広いインターネットコミュニティ全体をその対象としており、議論や情報交換のみならず、インターネット全体として取り組むべき課題や活動に関する合意形成や提言を行う場としても機能しています。

FROM JPRSでは今回の会議で取り上げられた話題のうち、DNSに関する話題を中心に、注目すべき内容をご紹介します。

RIPEの旗
RIPEの旗

RIPEとRIPE NCC


RIPE Meetingでは毎回、RIPE NCCが実施しているさまざまな活動について報告されています。ここでRIPEとRIPE NCCの違いについて簡単にご紹介します。

RIPEは「Reseaux IP Europeens(*1)」の略称で、フランス語で「ヨーロッパのIPネットワーク」を意味しています。RIPEはヨーロッパにおけるオープンなネットワークコミュニティとして、1989年に活動を開始しました(*2)。

RIPEが発足し、インターネットにおいてその活動を進めていくにつれ、IPアドレスやAS番号といった共通資源の管理や、広域ネットワークに関する各種調整活動を行うための、中立的な専門機関の必要性が認識されました。

そこで、このような活動を専門的に行うための「Network Coordination Centre(ネットワーク調整センター: NCC)」として、RIPE NCCが1990年に計画され、1992年4月に発足しました。RIPE NCCの本部はオランダのアムステルダムに設置され、ヨーロッパと中東における地域レジストリ(RIR)の役割を担っています。

(*1)
正式にはRの後のeとpの後のeにアクセント記号(´)が付く。
(*2)
The History of RIPE
http://www.ripe.net/ripe/history.html

RIPE NCCにおけるDNSサービスの状況


RIPE NCCでは、インターネットの根幹にかかわる重要なDNSサーバの管理運用を行っています。たとえば、RIPE NCCに割り振られているIPv4/IPv6アドレスの逆引きゾーンを管理するDNSサーバや複数のccTLDのセカンダリサーバ、ルートサーバのひとつであるK.root-servers.net(以下、K-root)などです。

これらのサーバが提供しているサービスの安定性をより高めるため、RIPE NCCでは2006年12月にDNSサービスを専門的に扱う部門を新設しました。今回、同部門のマネージャに就任したBrett Carr氏から、RIPE NCCによるDNSサービスについて報告がありました。

今回の報告では、各DNSサーバのハードウェアやOSの更新状況、RIPE NCCが管理する逆引きゾーンへのDNSSECの導入状況、K-rootの現状と今後の増強計画などが発表されました。K-rootでは現在実験的に行っているIPv6サポートを実用サービスのレベルに移行する準備をしているとのことで、IPv6においてもIPv4と同様、IP Anycast技術の導入も視野に入れているようです。

また逆引きDNSに関する不適切な設定のチェックシステムについて、開発状況が報告されました。現在すでにプロトタイプが稼働しており、次回のRIPE 55Meeting開催前の実稼働が予定されています。このプロトタイプをRIPE NCC配下の逆引きゾーンのひとつである193.0.0.0/8に対してテスト稼働させたところ、対象となる約23,000のDNSサーバのうち約15%に何らかの不適切な設定が見つかったとのことでした。

DNSSECの展開に向けた取り組み


2006年にスウェーデン(.se)がDNSSECの商用サービスを、ブルガリア(.bg)がDNSSECによるゾーンデータの署名を開始しました(詳細につきましてはバックナンバーvol.72「ICANNリスボン会合報告(第3回)」をご参照ください)。

DNSSECでは上位のゾーンから下位のゾーンに対し「信頼の連鎖(chain of trust)」を順に形成することにより、名前空間全体の信頼性を保証します。しかし現状では、最上位のルートゾーンがDNSSECに対応していないため、ユーザがDNSSECを利用するにはDNSSECに対応したTLD(上記の例では.seや.br)の公開鍵をDNSキャッシュサーバに個別にインストールし、定期的に更新しなくてはなりません。

このような状況でDNSSECを展開するためには、こうしたTLDの公開鍵を安全に格納・公開および利用するための仕組みが必要になります。信頼できる組織が各TLDの公開鍵を集中管理・公開することで、ユーザは各TLDのサーバを巡回することなく必要な鍵を入手できるようになるというメリットも生まれることから、今回のミーティングでは、RIPE NCCで公開鍵を格納するためのリポジトリ(貯蔵庫)の運用をしてはどうか、という案が提起されました。

しかしこのような形での運用はあくまで短期的な解決方法です。将来的にTLDの上位ゾーンであるルートゾーンがDNSSECに対応した場合、ユーザはルートゾーンの公開鍵のみをDNSキャッシュサーバにインストールし、定期的に更新するだけでDNSSECを利用できるようになるため、リポジトリそのものが不要になります。

会場では、こうしたリポジトリをRIPE NCCが運用することの是非といったポリシー的な側面、現状においてルートゾーンがDNSSECに対応していない中、いかにDNSSECの普及を図るのが現実的なのかといった運用的・普及的側面の双方から活発な議論が行われました。

その結果RIPEにおいて、この問題を速やかに検討するため新たにタスクフォースを立ち上げることになりました。さらに数人のメンバーがこの担当としてさっそく名乗りを上げ、問題解決に向けた機運の高まりが強く感じられました。

DNSルートゾーンへの署名実現を要請へ

また今回のミーティングでは長期的な問題を見据え、ICANNに対しルートゾー ンのDNSSECによる署名を早期に実施するよう、RIPEとして公式に要望を出すこ とが合意されました。会場でまとめられた意見の全文(*3)の参考訳を以下に 掲載します。

「DNSSEC展開に関する前進の欠如は、インターネットの安定性と安全性を徐々 にむしばんでいる。(DNS)運用者と実装者は、将来長期的な問題を引き起こす であろう、一時的かつ短期的な解決を強要される。RIPEコミュニティはICANN に対し、ルートゾーン署名のためのさらなる努力と改善を強く要望する。」

IP Anycasについて報告するJPRSの佐藤新太
IP Anycasについて報告するJPRSの佐藤新太

DNSにおけるIP Anycastの導入効果


JPRSからは、佐藤新太がJP DNSで運用しているIP Anycastとその計測内容を紹介しました。前回報告したCENTR Technical Workshopの発表ではDNSサーバにIP Anycastを適用する動機や考慮すべき課題にポイントを置いたのに対し、今回の発表では技術者向けに、計測により判明したIP Anycastの導入効果にポイントを置きました。特に、ニューヨークでJP DNSの拠点を運用した際のIP Anyacstの挙動については、図解による詳細な分析と紹介を試みました。

会場からは、世界レベルでの計測によりIP Anycastの評価を行う場合、各地域のインターネットエクスチェンジ(IX)等の協力を得ることで、今よりもより広域的に出来るのではないかとのコメントがありました。

ヨーロッパ地域におけるデータセンターの現状と課題


DNSの話題から少し離れますが、ここでデータセンターの現状課題についてご紹介します。

インターネットの急速な発展とサービスの多様化により、データセンターに対する需要が急激に高まっています。この状況はヨーロッパ地域においても同様であり、今回のミーティングではヨーロッパ地域におけるデータセンターの現状と課題についてのセッションが開催され、情報交換と議論が行われました。

データセンターの規模=電力

データセンターではこれまで、設置されるラックの数や場所の広さによって規模が決まることが一般的でした。しかし近年のサーバの機能向上に伴う消費電力の増加により、現在では電力量がデータセンターの能力を図る上での最大の要素になってきています。

今回のセッションでは、電力を確保するため自らのラックスペースに隣接する形で使用予定のないラックスペースを購入し、電源設備のみをラックスペースに引き込んで使用するといった事例も出始めているという報告がありました。

発熱と冷却のジレンマ

このように書くと「電源設備のみを追加購入すればよいのではないか」と考える方がいるかもしれません。しかし、データセンターに限らず大量の電気を消費する場合、それに応じた熱も発生するため、設備の密集度を無制限に上げることは不可能です。

また、最新の技術、例えばCPUのマルチコア化やメモリ、ディスク等のアクセスの高速化によりラック1台あたりの発熱量が加速度的に大きくなってきており、それに伴う冷却設備の強化も必要になっています。発表された例では現状、2.5Wの電力を用意した場合、機器にはそのうちの1.0Wしか使えず、残りの1.5Wは冷却設備にあてる必要があるとのことでした。

問題解決に向けた取り組み

以前からこのような問題に対応するため、低消費電力型・低発熱型のサーバ機器やネットワーク機器の開発、あるいはより効率的な冷却設備の開発といった、データセンターの提供者の側に立った解決方法が模索されてきました。

今回のミーティングではそれに加え、参加者の多くを占めているデータセンターの利用者の立場から、ネットワークのインフラとコンテンツのインフラには別な要求があるはずであり、データセンター側でこれらの要求に応じた形で機材を適切に準備することも検討の価値があるのではないか、というコメントが寄せられました。

前述の通りRIPE Meetingは議論や情報交換のみならず、インターネット全体として取り組むべき課題や活動についてもターゲットとしており、今回の話題はその代表的なものです。特にデータセンターの問題はヨーロッパにおいては国際問題かつ経済問題でもあり、RIPEに代表されるコミュニティの場における活動の重要性は、今後ますます高まっていくでしょう。

次回のRIPE 55 Meetingは2007年10月にアムステルダムで開催される予定です。


本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。