ICANNリスボン会合報告（第3回）

ICANNリスボン会合報告の最終回となる本号では、ccTLDにおける技術的話題を扱う「ccTLD Technical Meeting」と、インターネットのセキュリティと安定性に関する話題を扱う「SSAC（Security and Stability Advisory Committee）Open Meeting」を取り上げます。

また今回の会合では「DNSSEC for TLDs」と題し、TLDにおけるDNSSECの導入事例として、スウェーデン（.se）とブルガリア（.bg）の紹介がありました。これについても併せて報告します。

ccTLD Technical Meeting

ccTLD Technical Meetingでは、2006年12月にブラジルで開催されたICANNサンパウロ会合に引き続き、韓国、ポルトガル、カナダ、日本の各ccTLDレジストリより、それぞれのレジストリシステムの構成や運用の紹介などが行われました。

まず、韓国（.kr）からは、レジストリシステムの紹介に加え、DNS常時監視システムの開発についての紹介がありました。開発のきっかけは、2003年にSlammerウイルスの被害により韓国のインターネットが約36時間にわたってほぼ全面的に停止したことによるもので、それを機に、DNSを常時監視するシステムを独自で開発し、2006年から正式運用を行っているとの報告がありました。このシステムはIP Anycastサイトを含む各DNSサーバのリアルタイムのアクセス状況から個別のサーバの過去の任意のアクセスまでをグラフィカルなインタフェースで提供するもので、これによりDNSサーバへの異常なアクセスを早期に検知し、迅速な対応を行うことができるようになりました。

ポルトガル（.pt）からは、レジストリシステムおよびDNSサーバの構成の説明に加え、DNSのアクセス状況をリアルタイムに解析してデータベース化し、DNSサーバへのアクセス状況を効率的に把握するためのシステムを独自に構築したとの紹介がありました。

カナダ（.ca）からは、レジストリシステムのハードウェア更新に関する紹介がありました。2006年には、ストレージ機器とブレードサーバを用いたシンプルでコンパクトなシステムを構築し、2007年からはデータベース同期の仕組みを用いてバックアップ拠点の構築を行い、レジストリシステムの信頼性の向上を計画しているとの報告もありました。

最後に日本（.jp）からは、JPRSの佐藤新太がレジストリシステムとDNSの構成の紹介を行いました。また、IP Anycast海外拠点のテスト運用を行った際の計測データを元に、遠隔地の拠点追加によるアクセス状況の変動に関する説明を行いました。

参加者にはそれぞれのccTLDで実際に技術面や運用面を担っている技術者も多く、データベースの同期方法や、各ccTLDが構築しているシステムなどに関して多くの質問が寄せられました。また、DoS攻撃への対応手段としてIP Anycastの導入を検討しているccTLDも多く、これらについての意見交換も活発に行われました。

その他、2007年2月に発生した「ルートサーバへのDDoS攻撃」について、また、「レジストラの視点から見たccTLD」についての報告もあり、意見が寄せられました。

ルートサーバへのDDoS攻撃については、FROM JPRS増刊号「NANOG 38報告」もご参照ください。

DNSSEC for TLDs - TLDにおけるDNSSECの導入事例

DNSSECはIETFにおいてNSEC3（*1）プロトコルのRFC化の見通しが立ち、技術面での開発はほぼ完了しました。しかし、実際にDNSSECを普及させるための戦略はまだ明確になっていません。そこで、他に先駆けてDNSSECの実運用サービスを開始したスウェーデン（.se）とブルガリア（.bg）について、その経験を共有するための場が特別に設けられました。

特にスウェーデンではTLDレジストリのみならず、政府やISP、銀行といった複数の組織が共同で、インターネットの安全性を向上させるための重要な取り組みの1つとしてDNSSECの導入を行っており、その活動には興味深いものがあります。ここでは、今回発表された、スウェーデンにおけるDNSSECへの取り組みについて報告します。

.seのレジストリがドメイン名登録者に対して行った調査では、登録者のDNSSECサービスに対する興味は高く、DNSSECの導入によるある程度の費用負担増も可能であるという結果であったとのことでした。また、スウェーデンの4つの大手ISPがDNSSECに対応することにより、スウェーデン全体のブロードバンド利用者の80～90%をカバー出来るとのことで、ISPの協力によりスウェーデン全体へのDNSSECの導入を行うための下地は整っているとのことでした。

スウェーデンからは大手銀行であるSwedbankの担当者も参加しており、顧客をファーミングやフィッシングから守る手段の一つとしてDNSSECが有効であると考え、導入に前向きであるとの報告がありました。現在のDNS運用に比べると、DNSSECを用いたDNS運用には追加の工数がかかりますが、鍵管理の仕組みさえ理解できればそれほど大きな手間ではないと考えているとのことです。具体的な手法はまだ明確ではありませんが、2008年には何らかの形でサービスを開始する予定であるとのことでした。

このようにスウェーデンでは各機関が協力してDNSSECを導入することにより、ドメイン名の安全性を向上させようという試みが行われ始めています。しかし、DNSSEC導入における従来からの問題の1つである、DNSSECを一般利用者が利用する場合のアプリケーションの対応をどのように行うかについては、スウェーデン、ブルガリアにおいても未解決の状態であるとのことでした。

DNSSECはドメイン名とDNSの安全性を高めるための重要な技術です。今後もFROM JPRSでは、DNSSECに関する最新動向を随時報告していきます。

SSAC Open Meeting

SSAC（Security and Stability Advisory Committee：セキュリティと安定性に関する諮問委員会）からは、RSSAC（Root Server System AdvisoryCommittee：ルートサーバシステム諮問委員会）と共同で実施したルートサーバへのIPv6アドレスの追加に向けた活動と、現在進行中の幾つかの調査について報告がありました。

ルートサーバの安定動作に関する活動

ルートサーバがIPv6アドレスを持つにあたり、ルートサーバのアドレス情報を記載したhintsファイルと、DNSサーバ起動時にルートサーバのアドレスを確認するための初期問合せによる影響について検討されたことが報告されました。

ルートサーバがIPv6のアドレスを持った場合、初期問合せの応答は512バイト以上のサイズになりますが、一部のファイアウォール等では、DoS対策として512バイト以上の応答をブロックする場合があります。これがルートサーバへのIPv6導入にあたっての障害となるのではないかとされていましたが、これは設定変更により対応可能であるもので、IANAが日程を事前に十分周知した上で、IPv6の導入をすればよいという報告内容でした。これらの詳細は、SSAC Webサイトに掲載されている報告書をご参照ください。

一方、IDN TLDに関しては、SSACの観点として、今後セキュリティおよび安定性に関する影響があるかの確認を行い、10月には結果を報告書としてまとめる予定であるとのことでした。

ルートサーバの安定動作は、インターネットそのものの安定運用にとって必須条件の1つです。FROM JPRSでは今後も、本件に関する情報発信を行っていきます。

Whois spamに関する調査

Whoisでメールアドレスを公開することで、spamメールの受け取りが増えると言われていますが、その実態は明確になっていないため、TLDをまたいだ横断的な調査を実施することになりました。テスト用のメールアドレスを実際にWhoisで公開し、登録するTLDやレジストラによる違いなど、いくつかのパターンでテストを始めています。SSACではこのような調査を実施することによりWhoisの利用状況をより具体的に把握し、ICANNの場におけるWhoisも含めた情報公開のあり方の検討につなげるための活動も行っています。





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