ドメイン名関連会議報告
2007年
ヨーロッパのccTLDコミュニティにおける最新動向
~ 第16回 CENTR Technical Workshop報告 ~
2007/05/29
第16回となるCENTR(Council of European National Top-Level Domain Registries)Technical Workshopが、2007年5月6日、エストニアの首都タリンで開催されました。CENTRはヨーロッパ地域におけるccTLDレジストリの連合体で、現在54のccTLDがMemberとして参加しています。
CENTRはヨーロッパ地域を活動の主眼としながらも、ヨーロッパ地域以外のccTLDやgTLDもその活動に参加することができます。JPRSはCENTRのAssociate Memberとして、長年にわたり議論と情報交換にかかわってきました。
今回のワークショップには過去最大の45名が参加し、さまざまなテーマについて活発な議論と情報交換が行われました。FROM JPRSでは、この中から特に注目すべき内容について報告します。
CENTRはヨーロッパ地域を活動の主眼としながらも、ヨーロッパ地域以外のccTLDやgTLDもその活動に参加することができます。JPRSはCENTRのAssociate Memberとして、長年にわたり議論と情報交換にかかわってきました。
今回のワークショップには過去最大の45名が参加し、さまざまなテーマについて活発な議論と情報交換が行われました。FROM JPRSでは、この中から特に注目すべき内容について報告します。
CENTR(Council of European National Top-Level Domain Registries)Technical Workshop会場の様子
IANAのTLD向け機能のサービスレベルについて
4月11日にお届けしたFROM JPRS増刊号「ICANNリスボン会合報告(第2回)」で、ポーランドのccTLDレジストリであるNASKなどの支援により、IANAの処理を自動化する仕組みとしてeIANAが構築され、サービスが改善されつつあるとお伝えしました。今後さらにIANAのサービスを改善していく必要があるとの声があるものの、現在IANAのTLD向け機能にはサービスレベルが規定されておらず、自動化によりサービスが改善されたとしても、達成度や目標などが不明確であるという根本的な課題があります。
そのような背景から、今回はこの部分についての議論が行われました。サービスレベルを定義するにはどのような内容や項目が必要か、そしてそれぞれの項目のサービスレベルはどのように決定すべきか、さらにIANAがそれを満たせなかった場合にはどうするかなどについて、特に技術的観点から意見交換されました。
前述のように今回の議論は、NASKによるeIANAシステムの開発に端を発しています。会場からは、このような具体的な実装を基にした形でサービスレベルを定義するよりも、IANAの機能に対してTLDが実際に必要と考えるサービスレベルを定義した方がよいという意見も多く寄せられました。今回の議論では最終的な結論は出ませんでしたが、今後何らかの形でTLDからのサービスレベル要求がまとめられ、提案されることが考えられます。
これまでインターネットは長年にわたり、関係者間の善意により機能してきました。しかし、インターネットの社会的要求が増し、インフラとしての側面を持つにつれて、TLDとICANN/IANAの間においても、契約関係やサービスレベルの明確化による系統的な管理運用が模索される方向にあります。このような状況も、インターネットの成熟を示すものの一つであるといえるでしょう。
OARCの活動について
OARC(Operations, Analysis, and Research Center)はDNSに関する運用、分析、研究活動を行う組織で、DDoSやセキュリティ問題などからDNSインフラの運用を守るためのコーディネーションセンターの役割も担っています。今回のワークショップにはOARCの責任者であるKeith Mitchell氏が招かれ、OARCの活動内容や最新情報が紹介されました。
今年2月に起きたルートサーバへのDDoS攻撃(2月22日付FROM JPRS増刊号「NANOG39 Meeting報告」で紹介)以降、OARCの活動には世界的に注目が集ま っています。今回のワークショップでは今後CENTRとOARCが協働し、各DNSサーバの連絡先情報を共有することで、有事の際などにより迅速な形で対応できる体制の構築の可能性が話されました。
JPRSもDNSの安定運用に取り組む立場として、以前よりOARCの活動に参加してきました。今後もOARCの活動に関する情報をお知らせしていきます。
ギリシャにおけるIDN(国際化ドメイン名)の利用状況
今回のワークショップではギリシャ(.gr)のレジストリから、.grにおけるIDNの利用状況に関して以下の報告がありました。
- 2005年7月4日にIDNの登録を開始
- 現時点で約8,500のIDNの登録がある
- 登録を受け付けるのは「ギリシャ文字.gr」のみ。ギリシャ文字と別の文字の混在は禁止
- 登録の際にvariants(*1)やhomograph(*2)を同時に予約し、混乱や悪用を防ぐための対策を取っている(後述)
- これらのvariantsやhomographは、元の登録者のみが有効化できる
- (*1)
- variants
異体字。たとえば、日本における辺と邊と邉のように、読みと意味は同じで字体だけが異なる文字や単語。
- (*2)
- homograph
同形異字。同じ、あるいはきわめて類似した形であるが、文字種・意味が互いに異なる文字や単語。
ギリシャ語ではアクセント記号をつけて表す単語であっても、それらの単語を大文字で記述した場合、アクセント記号をつけません。そのため、あるギリシャ語のIDNが登録された場合、アクセント記号のみに相違があるIDNをすべてvariantsとみなして予約し、元の登録者のみが予約されたドメイン名を有効化可能とする運用を行っているとのことです。
また、ラテン文字とギリシャ文字の間で同型となる文字(例えばラテン文字のEとギリシャ文字のΕなど)については、ドメイン名登録時にhomographとして予約し、フィッシングなどの悪用を防止する対策を実施しているとのことでした。一部のラテン文字とギリシャ文字の間では対応が一対一ではなく多対多になるため(*3)状況はより複雑なものとなり、レジストリでは該当するものすべてを登録時に予約しているとのことでした。
登録者からの申請によりvariantsやhomographを有効化する場合、.grでは原則としてDNAME(*4)を使用し、登録者側でのDNSサーバの設定を不要としているとのことです。DNAMEを実運用で使用しているレジストリは珍しいため、会場では登録者がこの仕組みを理解しているか、DNAMEに関するトラブル・異常が起きていないか、などの質問が寄せられました。会場での報告によると、登録者がvariants/homographを有効化する際に、その90%がDNAMEによる有効化を選択している(残り10%は通常のdelegationによる有効化)とのことで、また特に目立ったトラブルは報告されていないとのことでした。
- (*3)
- 発表によると、多対多となるのは以下の場合とのこと
(1)ラテン文字のh、n、vとギリシャ文字のη、ν
(2)ラテン文字のu、yとギリシャ文字のυ
- (*4)
- DNAME
あるドメイン名を、そのサブドメイン名空間すべてを含んだ単位で別のドメイン名に対応づけるためのDNSリソースレコード/技法。例えば、example.jpをexample.comに対応づけるDNAMEリソースレコードを記述すると、example.jpに属する全てのドメイン名(例えばtest.example.jp)は、DNS検索時にexample.com(この例ではtest.example.com)に自動的に対応づけられる。
IP Anycastについて発表するJPRSの佐藤新太
IP Anycastの適用と効果の検証
JPRSの佐藤新太から、DNSサーバにIP Anycastを適用する際に考慮すべき課題とその効果の計測・検証の手法について発表し、実例としてJP DNSの1つであるA.DNS.JPに、実際にIP Anycastノードを追加した際の効果を検証した結果を紹介しました。
会場からは、IP Anycastの効果を実際に見られたのは興味深い、他のTLDの状況も見たいといった反響がありました。TLDとしてこのような情報を発表することはあまり行われておらず、IP Anycastの運用実績を持つJPならではの情報提供ができたと考えています。
本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。