3.

第3章

国際化ドメイン
国際化ドメイン名
ドメイン名の導入及び導入及び実装に実装に関する取組
する取組み
取組み状況

59

第1部

第3章

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及び導入及び実装に実装に関する取組
する取組み
取組み状況

国際化ドメイン
国際化ドメイン名
ドメイン名の導入及び導入及び実装に実装に関する取組
する取組み
取組み状況

3.1. 国際化ドメイン
国際化ドメイン名
ドメイン名の導入における導入における課題
における課題と課題と解決策
国際化ドメイン名とは、これまで英数字とハイフン（いわゆる 7bit ASCII）しか使えなかったドメイン名に、漢字やひらがな、カタカナといった日本語や、アラビア文字などのマルチバイト文字を利用できるように国際化拡張するための技術であり、また、
これらのマルチバイト文字を使ったドメイン名そのもののことも指す。この国際化ドメイン名を導入することによって、ドメイン名のラベルに使用できる文字の種類が従来から飛躍的に増加することになる。

3.1.1. 国際化ドメイン
国際化ドメイン名導入
ドメイン名導入のための名導入のための前提のための前提とその前提とその仕組とその仕組み仕組み
国際化ドメイン名を実現するための方法およびそのために必要となる個々の技術は、IETF において標準化が進められ、2003 年 3 月 7 日、それぞれ RFC として発行された。それらは、国際化ドメイン名全体の枠組みを規定する IDNA（RFC3490）、国際化 ド メ イ ン 名 に お け る 文 字 列 の 正 規 化 の た め の 方 法 と し て の NAMEPREP（RFC3491）、入力された国際化ドメイン名を ASCII 文字列にエンコードするための技術としての Punycode（RFC3492）であり、これらの RFC の発行により各レジス
トリが国際化ドメイン名を本格的に導入するための準備が整ったこととなる。
これらの RFC として標準化された技術の大きな特徴は、既存のインターネット空間、
特に DNS 名前空間に大きな影響を与えないことである。既存のインターネット空間に大きな変更を伴う技術であっては、導入に際して無用な混乱や、最悪の場合、DNS
による名前解決が不可能になるなどといった事故を引き起こす可能性が高くなり、導入への妨げとなってしまう。したがって、国際化ドメイン名の技術の標準化作業を行う際には、既存の枠組みへの影響が最小限となるように注意が払われた。
具体的な仕組みとしては、ネームサーバ側でマルチバイトの国際化ドメイン名を直接扱うのではなく、ユーザ側のアプリケーションにおいて、その国際化ドメイン名を一定の法則に従って英数字から成るドメイン名に変換し、ネームサーバとの通信はこれまで通り 7bit ASCII だけで構成される文字列を用いるというものである。こうすることによって、既存のネームサーバソフトウェアに変更を加える必要はなくなり、またネームサーバから見た場合、扱うドメイン名は従来通りの 7bit ASCII の文字列として扱うことができ、既存のドメイン名空間に影響を与えずに済む。この技術は、ACE（ASCII Compatible Encoding）と呼ばれる。
この ACE の導入によって、既存の DNS プロトコルと互換性のある仕組みを実現することが可能となり、現行の DNS の仕組みを壊すことなく国際化ドメイン名を利用す
60

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及導入及び実装に実装に関する取組
する取組み
取組み状況

ることが可能となる。このため、TLD のネームサーバを管理するレジストリにおける実装、また、個々のドメイン名のネームサーバにおける実装は、純粋に技術的な観点から見るならば、それほど困難なものではないと言える。
技術的な観点から見た場合の課題はユーザ環境に見られる。ACE を用いることによって、ユーザ側のアプリケーションに国際化ドメイン名対応の仕組みを加えるだけで、国際化ドメイン名が利用できるようになると言えるが、これは、各アプリケーション・
ベンダーの実装に依存するものであり、国際化ドメイン名の技術標準化が完了した今、国際化ドメイン名の普及のためには、各アプリケーションへの実装が進んでいくことが重要である。

3.1.2. 国際化ドメイン
国際化ドメイン名
ドメイン名の技術標準
国際化ドメイン名を実現する 3 つの技術標準の概要は次のとおりである。
(1) IDNA（RFC3490）1
国際化ドメイン名を使って通信を行う際には、ASCII 文字列からなるドメイン名に変換を行った上で通信が行われることになるが、この変換の際に使われる技術と処理手順を規定しているものが IDNA(Internationalizing Domain Name in Application)と呼ばれる技術である。
この IDNA では、ユーザ側のアプリケーションで国際化ドメイン名の解釈を行うこと
や、入力された文字列を NAMEPREP という仕組みで正規化すること、既存の DNSとの互換性を保つために国際化ドメイン名を Punycode と呼ばれるアルゴリズムでASCII 文字列に変換することなどが定められている。
国際化ドメイン名を利用する際には、各アプリケーションはこの IDNA に従って国際化ドメイン名をネットワークに送出することになる。
(2) NAMEPREP（RFC3491）2
STRINGPREP（RFC3454）3を国際化ドメイン名に対して適用するため、その具体的な方法を規定したものが NAMEPREP である。
RFC3490
http://www.ietf.org/rfc/rfc3490.txt
2 RFC 3491
http://www.ietf.org/rfc/rfc3491.txt
3 RFC3454
http://www.ietf.org/rfc/rfc3454.txt
1

61

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及び導入及び実装に実装に関する取組
する取組み
取組み状況

文字列の文字種や互換文字の統一、ラベル区切り文字の変換などが行われる。
具体的な例を挙げると、たとえば日本語の場合は、アルファベットの大文字・小文字は全て小文字に、全角英数字は半角に、半角カナは全角カナに統一される。また、全角の「．
」や句点「。
」は半角の「.」に変換されるなど、文字の正規化が行われる。
(3) Punycode（RFC3492）4
国際化ドメイン名で使用される Unicode による文字列を、ASCII 文字のみからなる文字列に変換するためのアルゴリズムを Punycode と呼ぶ。
国際化ドメイン名の検討段階では、ACE（ASCII Compatible Encoding）変換のための方式の一つである RACE（Row-based ACE）と呼ばれるアルゴリズムが利用されていたが、RACE よりも優れた方式として AMC-ACE-Z (Adam M Costello 氏が考案した 26 番目の変換方式の意) と呼ばれる方式が提案され、標準として採用されることになった。その後、この AMC-ACE-Z は考案者により Punycode と名付けられた。
国際化ドメイン名を表すプレフィックスとして、 RACE では「bq--」が使われていたが、 Punycode では「xn--」が国際化ドメイン名を表すプレフィックスとして規定されている。

3.1.3. 国際化ドメイン
国際化ドメイン名
ドメイン名における言語問題
における言語問題
IETF における国際化ドメイン名の標準化作業の結論として、
2003 年 3 月 7 日に IDNA
（RFC3490）、NAMEPREP（RFC3491）、Punycode（RFC3492）の計 3 つの RFCが発行され、技術的には国際化ドメイン名は一定の結論に辿り着いた。
しかし、上記 3 つの RFC は、「文字」の持つ性質にのみ基づいた技術標準であり、「言語」の概念に対する配慮はなされていない。
（ドメイン名は本来「言語」の概念を含まない「識別子」として設計されている。
）
言語の中には、等価または等価に近い意味を持つ文字が存在する場合があり、このよ
うな中で国際化ドメイン名の登録に特段の制約も設けない場合には、サイバースクワ
ッティング、あるいは、誤解や混乱を招くような文字の組み合わせで登録がなされるとの懸念がある。
特に、中国、台湾においては、繁体字（e.g. 國）と簡体字（e.g. 国）の問題があり、
4

RFC3491
http://www.ietf.org/rfc/rfc3491.txt
62

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及導入及び実装に実装に関する取組
する取組み
取組み状況

どの文字とどの文字を等価とすべきかについても議論となっている。また、ccTLD と異なり「国」との関連性を持たない gTLD において「言語」概念をどのように扱うべ
きかについても大きな問題となっていた。
これらの問題の解決については技術標準に頼るべきではない（技術標準に言語や文化に基づいた問題を持ち込むべきではない）という考えが強く、上記のような問題は技術標準とは別の形で解決を図っていく方向にある。その解決策の方法として考え出されたのが、次に説明する IDN-admin ガイドラインおよび ICANN ガイドラインである。

3.1.3.1. IDNIDN-admin ガイドライン5
このような状況を受け、JET（Joint Engineering Team；JP、KR、CN、TW の各
NIC で構成される技術検討グループ）を中心に検討され、インターネット・ドラフトとして IETF に提案されたのが「Internationalized Domain Names Registration and
Administration Guideline for Chinese, Japanese and Korean」（以下、「IDN-admin
ガイドライン」）である。
なお、この IDN-admin ガイドラインは 2004 年 4 月 14 日に RFC3743 として正式に発行され、現在では各レジストリにとって国際化ドメイン名を健全に運用するための重要な指針となっている。
この IDN-admin ガイドラインであるが、文字通り、中国語、日本語、韓国語（これらを総称して「CJK」と言う）のための国際化ドメイン名登録管理のためのガイドラインであり、その主な内容は次のようになっている。
(a) IDN ラベルは 1 つまたは複数の「言語」と関連づけて登録する。
IDN ラベルは技術的には Unicode 文字列であり、あらゆる「言語の文字」の組み合わせが可能な単なる識別子である。本来、ラベルには何らかの「意味」が求められるものではないが、IDN ラベルは、特定の言語を使った「名前」や「フレーズ」である
場合が多いのも事実である。そこで、IDN ラベルを 1 つまたは複数の「言語」と関連づけて登録することにより、ユーザの混乱回避に役立つ可能性がある。
例えば、「国沢」という IDN ラベルを登録する場合、それが「日本語」なのか「中国語」なのかを指定することになる。
(b) ある IDN ラベルが登録された場合、そこに含まれるすべての「等価文字」は、そ
5

RFC3743
http://www.ietf.org/rfc/rfc3743.txt
63

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及び導入及び実装に実装に関する取組
する取組み
取組み状況

の登録者のために予約される。
予約された文字列は、名前解決されない状態となるが、登録者が希望すれば「別名」として使用することが可能となる。なお、「等価文字」は言語毎に決められる。
例えば、「国」と「國」が等価文字、「沢」と「澤」が等価文字と定められている場合 、「国沢」を登録すると「國澤」「国澤」「國沢」が予約されることになる。
(c) 等価文字が存在する言語においては、推奨文字を決めてそれを IDN ラベルで使用する。
これにより、エンドユーザが、名前解決できる国際化ドメイン名を正しく予測できる可能性が高まる。
(d) ゾーン管理者は、予約された等価文字列の使用についてさらなる制限を加えても良い（ゾーンレベルのポリシーは、IDN-admin ガイドラインの範疇外）。
(e) ある IDN ラベルとその予約された等価文字列は指定された言語において一つのパッケージとみなす。
ドメイン名の移転や削除もこのパッケージ単位で行われることになる。
例えば、
『
「国沢」
「國澤」
「国澤」
「國沢」
』というパッケージがあった場合、このうちの一つだけをとって移転や削除をすることはできない。
この IDN-admin ガイドラインの位置づけとしては、IDNA や NAMEPREP、
Punycode といった IDN 関連の RFC のひとつ上のレイヤにあたるものとして考えられている。したがって、IDN-admin を採用しようとするレジストリは、まず国際化
ドメイン名の各 RFC に準拠した上でこの IDN-admin を導入し、さらに IDN-adminで定義することが求められている各言語毎の等価文字表を作成し、その表に基づいて
国際化ドメイン名の登録管理を行うこととなる。
具体的には、IDN-admin ガイドラインを採用して国際化ドメイン名を導入する各レ
ジストリは、国際化ドメイン名として登録可能な文字と、またどの文字とどの文字を等価なものとしてみなすのかということを定義した、等価文字表を作成し、それをIANA（Internet Assigned Numbers Authority）に届け出る必要がある。現在、IANAのページには 7TLD（13 言語）のテーブルが登録されており、JP ドメイン名で利用されている日本語のテーブルも登録されている。
このように、当初は中国語、日本語、韓国語のためのガイドラインとして作成された
64

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及導入及び実装に実装に関する取組
する取組み
取組み状況

IDN-admin ガイドラインであるが、上記のように現在はそれ以外の各国においても、
国際化ドメイン名を導入する各レジストリにとって重要なガイドラインとなっている。
3.1.3.2. ICANN ガイドライン
上記のような状況の中、ICANN でもこの問題を解決するための動きがとられた。
ICANN では、国際化ドメイン名の導入に伴って、ユーザに混乱が広がる恐れや新たなサイバースクワッティングが発生する恐れが無いわけではないとし、そのため、各レジストリが国際化ドメイン名を導入する際には、慎重かつ責任ある態度で臨む必要があり、現行の ICANN-レジストリ間の契約でも、レジストリが国際化ドメイン名の登録受付を開始する前に、ICANN が認可を行う必要性が規定されている。しかし、
ICANN の責務の範囲は、レジストリレベルでの国際化ドメイン名実装に対して細部にわたる管理を行うところまでは含まれていないため、ICANN がこの件に関して契約上の責任を果たすには、どのような基準を適用すべきかということが問題となっていた。
そこで、ICANN はレジストリレベルでの国際化ドメイン名実装に対して過度な介入を行うべきではなく、あくまで軽度なアプローチをとるべきであるとした立場から、こうした考えを前提として、以下のようなガイドラインが設けられることとなった。
これが「IDN 実装のためのガイドライン」であり、同ガイドラインに準拠した IDN
レジストリは、その国際化ドメイン名登録にあたり今後、取り扱う言語に固有の登録・管理規則を採用することとなった。
このガイドラインは、国際化ドメイン名登録を行う契約レジストリが合意すべき 4 つの必須要件と、
特に gTLD レジストリに強く推奨する 2 つの勧告事項からなっている。
なお、最新のガイドラインは 2003 年 6 月 20 日に発行されたバージョン 1.0 である。

「IDN 実装のためのガイドライン」（1.0 版）6
1) IDN を実装する TLD レジストリは、RFC3490、3491 および 3492（以下、集合的に「IDN 標準」と呼ぶ）に定める技術要件に厳格に準拠した上で実装をしなければならない。
2) TLD レジストリが IDN 標準を実装する際には、Unicode で規定されているすべてのコードポイントの中から許可されるものを明確にするという方法をとらなければならない（レジストリが明確に許可していないコードポイントは禁止されている、とい6

ICANN Guidelines for the Implementation of Internationalized Domain Names
http://www.icann.org/general/idn-guidelines-20jun03.htm
65

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及び導入及び実装に実装に関する取組
する取組み
取組み状況

うことを意味する）。
3) TLD レジストリが IDN 標準を実装する際には、以下を実行するものとする。
a. 登録された各国際化ドメイン名を一つまたは一連の言語に関連付ける。
b. 取り扱う言語に固有の登録・管理規則（文書化され公開されたもの）を採用する（登録されたドメイン名に関連付けられた言語における等価な異体文字を持つすべてのドメイン名を予約するなど） 。
c. ある特定の言語の登録・管理規則が異体文字テーブルから利点を得るとレジストリが判断した場合は、その言語での登録は、適切なテーブルが利用可能である場合のみ許可する。
4) 各レジストリは、各言語に固有の登録方針（レジストリが適切であると判断する場
合は、異体文字テーブルを含む）を策定するために、関係者と協力して取り組むものとする。これは、世界中の DNS ユーザの利便性のために IDN 実装へ向けて一貫したアプローチをとるという目的を実現するためのものである。レジストリは共通の問題に取り組むために、例えば ICANN の IDN Registry Implementation Committee のような特別委員会、地域グループおよび世界的なフォーラムを通して互いに協力するものとする。
5) TLD レジストリが IDN 標準を実装する際には、少なくとも初期の段階においては、
ドメイン名のラベル（セカンドレベルドメインなど）内の文字を、一つの言語または一連の言語に関連付けられた文字のみに限定すべきである。
6) TLD レジストリ（およびレジストラ）は、IDN 登録で対象とするすべての言語による情報提供およびサービス提供をすべきである。

66

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及導入及び実装に実装に関する取組
する取組み
取組み状況

3.2. 国際化ドメイン
国際化ドメイン名
ドメイン名の動向
3.2.1. おもな TLD における国際化における国際化ドメイン
国際化ドメイン名
ドメイン名の導入状況
3.2.1.1. .com/.net（.com/.net（VeriSign,Inc）
VeriSign,Inc）の導入状況
VeriSign,Inc は、2000 年 11 月、テストベッドという位置付けにて.com/.net/.org の国
際化ドメイン名の登録を開始した（その後、.org の国際化ドメイン名は、.org レジス
トリの PIR 移管に伴い、VeriSign,Inc の管理下ではなくなる）。このテストベッドの第一目的は、IETF における国際化ドメイン名の標準化作業への貢献とされたが、登録料は通常どおりに課金された。なお、IETF における標準化作業が当初の予想よりも長引いたこともあり、登録された国際化ドメイン名のその後の更新料請求は、数度にわたって延期された。
テストベッドは 3 つのフェーズに分けて進められた。第 1 フェーズは「レジストラの準備期間」である。国際化ドメイン名を扱うレジストラは別途そのための認可を
VeriSign,Inc から受けなければならず、運用のためのテストを受けた後、認可されるという手続きがとられた。
（2005 年 2 月現在、VeriSign,Inc の下で国際化ドメイン名を取り扱うレジストラの数は、57 社7である。
）第 2 フェーズは「国際化ドメイン名の登録」である。これは文字どおり国際化ドメイン名の登録であるが、その一方で DNSのゾーンファイルへの設定はまだされないという段階である。登録されたドメイン名
は「Registry Hold」というステータスとなり、他の人が登録できないものとの位置付けがなされた。第 3 フェーズは「国際化ドメイン名の名前解決」である。これは、登録された国際化ドメイン名を DNS ゾーンファイルに設定し、実利用できる状態に置くということを意味するが、既存のインターネットの名前空間への影響を考慮し、<国際化ドメイン名>.mltbd.com という形で第 3 レベルに登録された文字列（国際化ドメイン名）を置くという措置がとられた。
第 3 フェーズに入った後、VeriSign,Inc は国際化ドメイン名を促進するために、2 つの対策をとっている。
(1) i-Nav プラグイン
国際化ドメイン名は、レジストリ側が対応しても、エンドユーザのクライアント側（各種のアプリケーションソフトウェア）が対応しなければ利用することができない。国VeriSign,Inc Find IDN Registrars
http://www.verisign.com/products-services/naming-and-directory-services/namingservices/internationalized-domain-names/page_001397.html

7

67

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及び導入及び実装に実装に関する取組
する取組み
取組み状況

際化ドメイン名の標準化が定まらない段階においては、アプリケーション・ベンダーが対応する可能性も小さく、この状態では、国際化ドメイン名を登録し、DNS のゾー
ンファイルに設定したとしても実際には使えないものとなってしまう。VeriSign,Incはこの状況に対して、自ら「i-Nav」というプラグインを開発。利用できる環境は一部に限定されているものの、そのプラグインをブラウザ（Win 98, ME, NT, 2000, XP
環境下の Internet Exporler 5.0, 5.5, 6.0）にインストールすることにより、アドレス
バーへの国際化ドメイン名の入力で、目的の Web サイトにアクセスできる環境づくりを実現した。また、同プラグインを利用することで、Outlook, Outlook Express を使って国際化ドメイン名を使ったメールアドレスにメール送信ができるという環境も実現した。なお、DNS のゾーンファイルにおいては、<国際化ドメイン名>.mltbd.com という形式にて設定されているものの、このプラグインを使う場合には <国際化ドメイ
ン名>.com という入力で適切な変換がなされるようになっている。
(2) Web Based Navigation
VeriSign,Inc は 2003 年 1 月より.com/.net を対象に Web Based Navigation というサービスを開始した。これは、国際化ドメイン名に対応していないブラウザから <国際化ドメイン名>.com、<国際化ドメイン名>.net へのアクセスがあった場合、DNSを管理するレジストリ側でそれを感知し、そのアクセスユーザに対して、国際化ドメ
イン名対応環境（i-Nav プラグイン）を案内する Web ページを表示するというものである。
その後、国際化ドメイン名は、2003 年 2 月に、3 つの RFC の発行によって標準化作業が完了したが、先に述べた言語問題があるため、レジストリは、技術標準への準拠とは別に ICANN ガイドラインへの対応が迫られることとなった。
これに対して VeriSign,Inc は、その対応作業を進め、2003 年 10 月 13 日、ICANNに対して、対応方針を伝えると共に国際化ドメイン名の正式サービス開始の認可を求めるレターを送った。この結果、ICANN は 2003 年 12 月に VeriSign,Inc を認可。
VeriSign,Inc は、
12 月 13 日より RACE から Punycode への移行作業を開始した。2004
年 4 月 23 日には従来の RACE でのドメイン名の登録受付を終了、Punycode でのみ登録を受け付けるようになった。
一方、VeriSign,Inc が運用するネームサーバの応答に関しては、Punycode への移行開始と共に、Punycode による名前解決の要求に応答するように変更が加えられたが、RACE による名前解決要求にも応答するように並行した運用が行われており、ほぼ移行作業が完了したと見られる現在においても、一部のドメイン名に関しては RACE での名前解決がまだ可能な状態となっている。
なお、ICANN が定めるガイドラインへの対応についてであるが、2003 年 10 月 13
68

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及導入及び実装に実装に関する取組
する取組み
取組み状況

日に国際化ドメイン名の登録をユーザに提供するための承認要請を ICANN に提出したものの、ICANN からは現時点においても承認は下りておらず、そのため IANA のデータベースにも.com および.net の言語テーブルは登録されていない状況である。
3.2.1.2. .org（.org（Public Interest Registry）
Registry）の導入状況.org の国際化ドメイン名は、2003 年 1 月の.org レジストリの PIR への移管以降、新規の登録受付および既存の登録ドメイン名の変更が一切できない状態とされていた。
その後、2003 年 12 月、レジストラに対して、既存の国際化ドメイン名を一切廃止し、今後その登録はしない旨のアナウンスが突然出されるという事態が発生したが、レジストラ等の強い反対により、その方針が覆されるという状況になっている。
このように紆余曲折のあった.org の国際化ドメイン名だが、2005 年 1 月 18 日付のプ
レスリリースでドイツ語文字のウムラウト( a o および u の変音文字)を使用
した国際化ドメイン名の登録を開始したと発表した。PIR では、さらに 10 の言語(デンマーク語、ハンガリー語、アイスランド語、韓国語、ラトビア語、リトアニア語、
ノルウェー語、ポーランド語、スウェーデン語およびタミル語)を使用した国際化ドメ
イン名の導入を 2005 年の第 3 四半期に計画中としている。

3.2.1.3. .info（.info（Afilias
Afilias）
as）の導入状況
2004 年 3 月 16 日、.info を管理している Afilias 社は、ドイツ語文字のウムラウト( ao および u の変音文字)を使用したドメイン名の登録を開始、翌日 3 月 17 日 13:00（協定世界時）の時点で、13,000 件を超えるドイツ語文字を使用したドメイン名が登録されたことが発表された。
なお、3 月 16 日から 4 月 14 日の間に登録されたドメイン名については、紛争の発生に備え、レジストリによりロック状態に置かれた。紛争が発生しなかったドメイン名については、その後ロック状態が解除され通常の使用が可能になるという仕組みである。また、4 月 14 日以降に登録されたドメイン名については、ロックされることなく通常の登録が行われた。
現在のところ、サポートする言語はドイツ語のみとなっている。

3.2.1.4. .museum（.museum（MuseDoma）
MuseDoma）の導入状況.museum を管理している Museum Domain Management Association（MuseDoma）
は、2004 年 1 月 22 日、国際化ドメイン名の登録を開始したと発表した。
当初対応するのは、一部のヨーロッパ系言語（デンマーク語、ノルウェー語、スウェ
69

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及び導入及び実装に実装に関する取組
する取組み
取組み状況

ーデン語）のみだが、MuseDoma では、グローバルコミュニティのニーズにこたえるため、できるだけ早急に対応する文字を拡大する姿勢を見せており、現在ではドイ
ツ語、フランス語、ポーランド語、スペイン語など、計 15 の言語をサポートしている。
3.2.1.5. .biz（.biz（Neulevel）
Neulevel）の導入状況.biz を管理している NeuLevel,Inc.は、ドイツ語文字のウムラウト ( a o および
u の変音文字)を使用した国際化ドメイン名の登録を 2004 年 10 月 12 日より開始
した。.museum、.info に続き、ICANN の定めるガイドラインに沿った形での国際化
ドメイン名が導入される gTLD としては、この.biz が 3 番目の TLD となった。
3.2.1.6. .jp（
（JPRS
.jp（日本）日本）（JPRS）
JPRS）の導入状況.jp の国際化ドメイン名への取組みは、JP ドメイン名の登録管理業務が社団法人日本
ネットワークインフォメーションセンター（JPNIC）によって行われていた時代にまで遡ることが出来る。
1999 年 5 月に JPNIC 内に iDNS 調査研究タスクフォースが設立されたのを皮切りに、本格的に国際化ドメイン名実現に向けた取組みが開始されることになる。
JPNIC ではその後も検討を進め、2000 年の 11 月には、
「汎用 JP ドメイン名登録等に関する技術細則」が制定され、日本語 JP ドメイン名として利用可能な文字が明確に定義された。このことにより、国際化ドメイン名を導入するための前提がまずは一つ整ったことになる。
続いて同じく 11 月に、日本語 JP ドメイン名のエンコード方式として ACE（ASCII
Compatible Encoding）という変換方式の一種である RACE（Row-based ACE）と呼ばれる技術を用いる方式で、日本語 JP ドメイン名運用試験のフェーズ 1 が開始された。
もっとも、このフェーズ 1 においては、実際に各種アプリケーションを利用して日本
語 JP ドメイン名を利用するというものではなく、日本語 JP ドメイン名が DNS にどのような形で設定・運用されるのかを確認するための環境を提供するという基本的なものであった。
そして、このフェーズ 1 の結果を受けて、2001 年には日本語 JP ドメイン名の登録が開始された。日本語 JP ドメイン名は汎用 JP ドメイン名として受け付けられ、2001
年 2 月には優先登録が、4 月には同時登録が開始され、実験段階から実際に登録が可能となるという次のステップへと移行した。
70

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及導入及び実装に実装に関する取組
する取組み
取組み状況

しかし、登録は開始されたものの、IETF などによる国際化ドメイン名の技術標準化にはまだ時間がかかっており、そのためまだテスト的な意味合いも強い部分が残っていたのも事実であり、検討と運用が同時に行われるような状態がしばらく続くこととなった。
その後、2001 年 3 月には ICANN に IDN Committee が設立されるなど、IDN に関する検討も徐々に進展し、現在標準となっている ACE や NAMEPREP、IDNA といった技術が主流とみなされるような状況となったことから、徐々にではあるが国際化
ドメイン名の実用化に向けた環境が整うようになってきた。
そして、JPNIC は 2001 年 5 月に日本語ドメイン名運用試験のフェーズ 1 を終了し、フェーズ 2 を開始した。このフェーズ 2 では、汎用 JP ドメイン名として登録された
日本語 JP ドメイン名について、RACE を用いた方式での名前解決が可能となり、実際に登録した国際化ドメイン名を使って名前解決をすることが可能となった。
その後、JPNIC から JPRS へと JP ドメイン名の登録管理業務が移管された後も、JPRS において日本語ドメイン名に関する検討は続けられ、2003 年 3 月の国際化ドメ
イン名の技術標準を規定した 3 本の RFC（IDNA:RFC3490、NAMEPREP:RFC3491、
Punycode:RFC3492）の発行、および 2003 年 6 月に ICANN から発表された「IDN
実装のためのガイドライン」を受け、2003 年 6 月 30 日に日本語ドメイン名運用試験のフェーズ 2 終了をアナウンスした。
実際のフェーズ 2 終了は 2003 年 7 月 10 日に行われ、9 月 3 日までかけて日本語 JP
ドメイン名のサービスを RFC に準拠したサービスへと移行させるための作業が行われた。移行にあたっては、次の 3 つのステップを踏むことによって、ユーザの混乱を最小限に抑えるための努力が払われた。
(1) JP DNS での RACE と Punycode の併用期間開始（7 月 10 日）
JPRS が運用している.jp の DNS サーバに、これまでの RACE に加えて Punycode でもドメイン名が登録されるようになった。これにより、RFC に完全準拠した、
Punycode で名前解決を行うアプリケーションからも日本語 JP ドメイン名の利用が可能となった。
(2) InternetExplorer 用 plug-in ソフト(i-Nav)の内部動作切り替え（7 月 30 日）
JPRS が配布しているブラウザ用のプラグインソフトである i-Nav の内部動作について、RACE 優先から Punycode 優先へと切り替えが行われた。
(3) JP DNS での RACE の運用終了（9 月 3 日）
.jp の DNS サーバから RACE の設定の削除が行われた。
これにより、JP ドメイン名の RFC への準拠作業は完全に終了したことになる。
71

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及び導入及び実装に実装に関する取組
する取組み
取組み状況

現在、.jp では携帯電話からの国際化ドメイン名を使ったアクセスのためのサイトを用意したりするなど国際化ドメイン名の普及に力を入れており、.jp は世界でも最も国際化ドメイン名を利用する環境が整っている TLD のひとつであると思われる。
3.2.1.7. .kr（
.kr（韓国）韓国）（Korea（Korea Network Information Center）
Center）の導入状況.kr を管理している KRNIC(NIDA:韓国情報通信開発振興庁)は、2003 年 8 月 19 日から国際化ドメイン名の登録を開始した。
国際化ドメイン名の登録にあたっては、混乱を避けるために 3 段階の登録期間が設けられた。
まず、1 段階目の期間(8 月 19 日から 6 週間)には公共機関、ブランド、商号名などを元にしたドメイン名の登録が受け付けられた。
次に、2 段階目の期間(10 月 7 日から 2 週間)には、住民登録証や事業者登録証を元にドメイン名の登録を受け付けた。
この１段階目と 2 段階目で重複した申込みがあれば抽選で登録者を決める方式を取り、これらの手順が全て完了してから、最後に 3 段階目として通常の先願制による登録受付が開始された。
3.2.1.8. .pl（
（NASK.pl（ポーランド）
ポーランド）（NASK：
NASK：Research and Academic Computer Network）
Network）の導入状況
2003 年 9 月 11 日に国際化ドメイン名の登録を開始。当初はポーランド語のみの登録受付であったが、2003 年 10 月 6 日にはドイツ語文字のウムラウト ( a o および u の変音文字)を利用したドメイン名の登録受付も開始した。
その後もラテン文字やギリシャ文字、ヘブライ文字、アラビア文字など次々とサポートする言語を増やしており、2004 年 2 月 26 日にはキリル文字のサポートも開始している。現在 IANA に登録されている言語テーブルは 4 つとなっており、gTLD、ccTLDを併せた全ての TLD の中で最も多い登録となっている。
3.2.1.9. .th（（ThNIC.th（タイ）タイ）（ThNIC）
ThNIC）の導入状況
2004 年 7 月からタイ語での国際化ドメイン名の登録を開始している。

72

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及導入及び実装に実装に関する取組
する取組み
取組み状況

3.2.1.10. .de（
（DENIC.de（ドイツ）
ドイツ）（DENIC eG）
eG）の導入状況
2004 年 3 月から国際化ドメイン名の登録を開始、従来の 7bit ASCII で表現される 37
文字に加え、新たに 92 文字がドメイン名のラベルとして利用できるようになった。
利用可能な文字の一覧は、DENIC の Web ページで公開されている。
3.2.1.11. .ch/.li（（SWITCH.ch/.li（スイス／
スイス／リヒテンシュタイン）リヒテンシュタイン）（SWITCH Teleinformatics Services）
Services）の導入状況
SWITCH は.ch（スイス）と.li（リヒテンシュタイン）のレジストリを兼ねている。
2004 年 3 月から国際化ドメイン名の登録を開始している。
新たに登録可能となった文字として、SWITCH の Web サイトでは 31 文字の変音文字が挙げられている。
3.2.1.12. .at（
（NIC.AT.at（オーストリア）
オーストリア）（NIC.AT Internet Verwaltungs
Verwaltungs und
Betriebsgesellschaft m.b.H）
m.b.H）の導入状況
2004 年 3 月から国際化ドメイン名の登録を開始している。
従来の 7bit ASCII の文字に加え、新たに 34 文字がドメイン名のラベルとして利用可能になっている。

3.2.1.13. .dk（
.dk（デンマーク）
デンマーク）（DK（DK Hostmaster A/S）
A/S）の導入状況
dk の 登 録 規 則 （ RULES FOR REGISTERING, ADMINISTERING ANDRESOLVING CONFLICTS IN CONNECTION WITH DOMAIN NAMES UNDER
THE .DK TOP LEVEL DOMAIN (Version no. 09 of 30 November 2004)）8の「1.3.
基本」の b 項によると、登録可能文字の追加については次のようなルールとなっている。
1.3. 基本b. デ ン マ ー ク ド メ イ ン 名 の 文 字 セ ッ ト は 、 www.difo.dk お よ び
www.dk-hostmaster.dk の Web サイトにていつでも一般に見られるものとする。文
字セットの拡張は、DINFO（Dansk Internet Forum）との協議の上、最低 1 ヶ月の予告期間をもって、DK Hostmaster によって行われる。なお、変更部分が有効とされるにあたっては、事前に新規文字セットが十分な技術力によって確実にサポートされることとする。また、正当な疑義の申し立てであると認められる範囲内において、提案されている変更に対して一般の人々がコメントを述べる機会を設けるものとする。
8

http://www.difo.dk/regler/version09.en.pdf
73

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及び導入及び実装に実装に関する取組
する取組み
取組み状況

なお、登録可能文字については、以下の URL にて公開されている。
Character set for Danish domain names
http://www.difo.dk/regler/Tegn-01-01-2004.pdf
3.2.1.14. .lt（
.lt（リトアニア）
リトアニア）（KTU（KTU Information Technology Development Institute）
Institute）の導入状況
2003 年 3 月 30 日から国際化ドメイン名の登録を開始している。
登録可能な文字については、以下の URL にて示されている。
Allowed characters in .lt second level IDN domain name Unicode representation
http://www.domreg.lt/en/nutar/allowed_characters.pdf
3.2.1.15. .se（
（NIC
.se（スウェーデン）スウェーデン）（NICNIC-SE）
SE）の導入状況
2003 年 10 月より、5 つの文字（å、ä、ö、ü、é）を登録可能文字として追加する形
で IDN の登録を開始している。

3.2.1.16. .tw（
（TWNIC.tw（台湾）台湾）（TWNIC）
TWNIC）の導入状況
2003 年 11 月 17 日より、Punycode を用いる形での、RFC に準拠した IDN 登録サー
ビスへと移行を行った。
3.2.1.17. .cn（
（CNNIC.cn（中国）中国）（CNNIC）
CNNIC）の導入状況.cn では、従来から「.中国」
、
「.公司」
、
「.网絡」という３つの中国語 TLD の下に CDN（Chinese Domain Name：中国語ドメイン名）が登録できるようになっており、さらに、「.中国」には「.CN」の CDN がバンドルされる形になっていた。
しかし、国際化ドメイン名のトップレベルドメインはまだ ICANN で承認されておらず、したがって上記 3 つの中国語 TLD はルートゾーンには含まれていないものと考えられる。
このように、
国際化ドメイン名に関してはやや独自の路線を取っていた中国であるが、2005 年 1 月 17 日から海外からの「中国語.cn」の形での国際化ドメイン名の登録を開始したと発表した。これにより、他の TLD で行われている国際化ドメイン名のサービスと同様に、セカンドレベル以下にマルチバイト文字列を登録出来るようになった。
なお、この登録受付開始に関しては、CN ドメイン名の国外での登録受付を行ってい
74

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及導入及び実装に実装に関する取組
する取組み
取組み状況

る Neulevel からプレスリリースが出されている。
参考 URL:
NeuLevel Introduces Chinese Language Internationalized Domain Names (IDNs)
In China’s .CN Domain
http://www.neulevel.biz/press/press_release/IDN.CNrelease1-18-05.pdf
3.2.1.18. .hu（
（ISZT.hu（ハンガリー）
ハンガリー）（ISZT Kht）
Kht）の導入状況
登録規則によると、通常の ASCII 文字に加えて 9 文字のハンガリー語の文字が登録可能となっている。
参考 URL:DOMAIN REGISTRATION RULES AND PROCEDURES
http://www.domain.hu/domain/English/szabalyzat.html
3.2.1.19. .is（
（ISNIC.is（アイスランド）
アイスランド）（ISNIC - Internet Iceland ltd.）ltd.）の導入状況
2004 年 7 月 1 日から国際化ドメイン名の登録受付を開始。登録が認められる文字として、従来の ASCII 文字に加えて新たに 10 文字が追加された。なお、通常の登録に先立って、2005 年 1 月 1 日までがサンライズ登録期間とされた。

75

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及び導入及び実装に実装に関する取組
する取組み
取組み状況

3.2.2. 国際化ドメイン
国際化ドメイン名
ドメイン名におけるその他
におけるその他の動き
3.2.2.1. アプリケーションのアプリケーションの国際化ドメイン
国際化ドメイン名
ドメイン名への対応
への対応
国際化ドメイン名の普及に向けて何よりも必要なのは、各アプリケーションの国際化
ドメイン名への対応である。いくら国際化ドメイン名の登録が増加しようとも、実際にそのドメイン名を利用できないのであれば利用者にとって魅力的なものとはなりよ
うもなく、またそのような状況で登録者が増加し続けるということも考えにくい。
したがって、アプリケーションの国際化ドメイン名への対応は非常に重要な要素であるが、その対応具合はアプリケーションによってまちまちである。
現在、一番対応が進んでいるのは Web ブラウザである。これはインターネットユーザの多くにとって、最もドメイン名に接する機会が多いのが URL の一部としてのドメ
イン名であろうことを考えると、ある意味最も国際化ドメイン名への対応が望まれる
ソフトウェアであると言える。
その Web ブラウザの対応状況であるが、Microsoft Windows 上で動くブラウザとしては、The Mozilla Foundation が提供している Mozilla と Firefox、Mozilla の成果物を利用している Netscape 社の Netscape、Opera Software 社が提供する Opera などが標準で国際化ドメイン名に対応している。
また、
Mac OS 上で動く Web ブラウザとしては、
OS に標準で提供されている Safari、
The Mozilla Foundation が提供している Camino などで国際化ドメイン名を利用することが可能である。
上記以外の OS としては、Linux や FreeBSD といった PC-UNIX 系の OS でも上記
Mozilla などを利用することが可能であり、国際化ドメイン名の利用にあたって特段の不都合は無いと言えよう。
しかし、これら多くの Web ブラウザが国際化ドメイン名に対応しているとはいえ、最も多くのユーザが利用していると思われる OS 上で稼働し、かつ最も多くの人が利用しているであろう Web ブラウザは国際化ドメイン名に標準では対応していない。
現 状 、 Microsoft Windows の 標 準 ブ ラ ウ ザ で あ る Internet Explorer で は 、VeriSign,Inc および JPRS が提供する i-Nav プラグインを追加でインストールしなけ
れば国際化ドメイン名を利用することができない。実際のプラグインのインストール
作業は非常に簡単だとはいえ、多くの一般ユーザにとっては標準で利用できないという状況が、国際化ドメイン名利用への壁を非常に高いものにしてしまっているのは事

76

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及導入及び実装に実装に関する取組
する取組み
取組み状況

実であろう。
Microsoft 社は早い段階での InternetExplorer の国際化ドメイン名への対応を公言しているが、国際化ドメイン名の利用環境を整え、より広い普及を推進するためには、是非とも早期の対応が望まれるところである。
Web ブラウザ以外のアプリケーションにおける、国際化ドメイン名への対応状況については、Web ブラウザほど進んでいないのが現状である。一部の FTP クライアント
やメールクライアントなどで対応しているものが見受けられるが、Web ブラウザほどの対応状況になるにはまだまだ時間がかかるものと思われる。
一般ユーザにとっての国際化ドメイン名の利用目的を考えた場合、まず最初に Webの URL としての利用が最も要望が高いと思われるが、URL として国際化ドメイン名を利用するようになれば、次にそのドメイン名をメールアドレスとしても利用したいという要望が出てくると考えるのが自然である。そういう意味では、Web ブラウザの対応が進むと同時に、メールクライアントにおいても国際化ドメイン名への対応が進
むことが、国際化ドメイン名の普及に向けて非常に重要である。
メールクライアントについても、Web ブラウザ同様 i-Nav プラグインを利用すること
により国際化ドメイン名を利用することは可能であるが、本来であればこれもプラグインなどの追加ソフトのインストール作業無しに利用可能であることが望ましいと言える。
また、ドメイン名の問題とは若干話がそれてしまう部分もあるが、国際化ドメイン名の普及にあたっては、メールアドレスのユーザアカウント部分9や URL 表記におけるディレクトリ10やファイル名11部分にマルチバイト文字が使えるようになることも、国際化ドメイン名の普及とは非常に関係の深い重要な問題であると言える。
この部分は、
現在 OS 依存となっていて、各 OS によって利用の可否が異なっているが、ユーザの利便性を考えた場合、何らかの共通のルールが作られることが望ましい。
そこで IETF で検討が続けられた結果、URI（Uniform Resource Identifier：インタ
ーネット上のリソースを一意に特定できる名前の仕組み。URL もこれに含まれる）に関する新たな技術標準が RFC として発行された。新しく発行された RFC は
RFC398612と RFC398713で、特に RFC3987 が国際化ドメイン名との関連が深い RFC

9○○○@example.co.jp といった場合の○○○の部分。
http://www.example.co.jp/○○○/index.html といった場合の○○○の部分。
11 http://www.example.co.jp/○○○.html といった場合の○○○の部分。
12 http://www.ietf.org/rfc/rfc3986.txt
13 http://www.ietf.org/rfc/rfc3987.txt
10

77

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及び導入及び実装に実装に関する取組
する取組み
取組み状況

である。この RFC では IRI（Internationalized URI）が規定されており、URI に日本語などのマルチバイト文字を利用するための技術標準が定められている。
この RFC 発行により、国際化ドメイン名がより一般的に、利用しやすくなるための環境がまたひとつ整ったと言えよう。
なお、VeriSign,Inc が提供している情報によると、現在国際化ドメイン名に対応している主なアプリケーションは以下のものとなっている。
これを見てもわかるように、国際化ドメイン名に積極的に対応しているのは、
Microsoft Windows 上で動くアプリケーションが多いようである。

ソフトウェア種別

サポート OS

製品名

Web ブラウザ用 Plug-in

i-Nav

Windows

Web ブラウザ

CaminoMac OS X

Epiphany

Linux,etc

FirefoxWindows,Mac OS X,Linux,etc

GaleonLinux,etc

Konqueror

Linux,etc

MozillaWindows,Mac OS X,Linux,etc

Netscape Navigator

Windows,Mac OS X,Linux,etc

Opera

Windows,Mac OS X,Linux,etc

SafariMac OS X

電子メールソフト

FoxmailWindows

FTP クライアント

Core FTP

Windows

FTP Voyager

Windows

Secure FTP

Windows

Smart FTP

Windows

NextFTP

Windows

Absolute Telnet

Windows

Secure NetTerm

Windows

Merak MailServer

Windows

PHlyMail

Windows

VisNetic MailServer

Windows

TELNET/SSH クライアント

電子メールサーバソフト

78

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及導入及び実装に実装に関する取組
する取組み
取組み状況

（参考：IDN-Enabled Applications
http://www.verisign.com/products-services/naming-and-directory-services/namingservices/internationalized-domain-names/page_002201.html）

3.2.2.2. その他
その他の問題2005 年 2 月 7 日から 8 日にかけて、国際化ドメイン名に対応している主要なブラウ
ザに、国際化ドメイン名を利用してフィッシング詐欺が可能となる脆弱性があるという報道が各所でなされた。
これは、デンマークの Secunia から出された以下のセキュリティアドバイザリが発端となって報道されたものである。
セキュリティアドバイザリ（Opera について）
http://secunia.com/advisories/14154/
セキュリティアドバイザリ（Konqueror-KDE について）
http://secunia.com/advisories/14162/
セキュリティアドバイザリ（Mozilla,Firefox,Camino について）
http://secunia.com/advisories/14163/
セキュリティアドバイザリ（Safari-Mac OS について）
http://secunia.com/advisories/14164/
セキュリティアドバイザリ（Netscape Navigator について）
http://secunia.com/advisories/14165/
セキュリティアドバイザリ（i-Nav プラグインについて）
http://secunia.com/advisories/14209/
また、Secunia では以下の検証用のページも用意された。
検証用ページ
http://secunia.com/multiple_browsers_idn_spoofing_test/
上記のページの中にある、検証用リンクを国際化ドメイン名対応ブラウザでクリック
すると、一部の文字をアルファベットではなくアルファベットに似せた別の文字で構成したドメイン名を利用したページへと誘導される。
（具体的にはアルファベットの aがキリル文字のаに置き換えられている）
79

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及び導入及び実装に実装に関する取組
する取組み
取組み状況

この場合、Web ブラウザはドメイン名としては正しいドメイン名を表示しているのだから、よくある URL 欄の偽装などとは違い、ブラウザの URL 欄やステータス欄にもこのドメイン名が表示される。
また、URL 偽装などを見抜くために注意するポイントとしてよく挙げられる SSL 証
明書の表示についても、本来のドメイン名がそのまま表示されているため、これを見ても異常に気付くことは無いと思われる。
このことから Secunia ではこの問題を国際化ドメイン名が持つ脆弱性であると捉えたのだと思われるが、ICANN や各レジストリといったインターネットコミュニティの大勢はこの判断に懐疑的である。
もともと、この問題は元の文字とよく似た文字を使ってユーザを混乱させるというものであり、国際化ドメイン名特有の問題であるとは言い難い。従来の 7bit ASCII のみ
でドメイン名が構成されていた時代から、数字の「1」と小文字の「l」、数字の「0」と小文字の「o」などといった紛らわしい文字の組み合わせは存在し、またそれらを使ってユーザを本来とは異なるサイトに誘導するという問題は広く知られていた。
これらはユーザの視覚を混乱させることによりユーザを特定のサイトに誘導することを狙ったものであり、国際化ドメイン名の使用上の欠陥や脆弱性に起因するものとは言い難い。技術的な問題ではなく、あくまでも使われ方の問題である。
ただし、使われ方によっては非常に紛らわしい文字の組み合わせが発生すること、またその紛らわしい文字の組み合わせが従来の 7bit ASCII のみによるドメイン名と比べて国際化ドメイン名の導入後は増えるということは十分認識されており、その問題に対する対応策は国際化ドメイン名の導入当初から検討されてきている。
その対応策が、先に述べた IDN-admin ガイドラインと ICANN ガイドラインであり、これらのガイドラインに沿った国際化ドメイン名の運用をレジストリが行うことにより、似通った文字をドメイン名に使うことによりユーザが混乱させられる可能性が激減するようになっている。
具体的には、これらのガイドラインを採用することにより、ドメイン名のラベルに複数の言語を使うことが抑制され、その結果、複数の言語の文字からなる不自然なドメ
イン名の登録ができなくなる仕組みである。
現在、.jp をはじめとして国際化ドメイン名を導入しているほとんどのレジストリでは
上記の IDN-admin ガイドラインおよび ICANN ガイドラインを導入済みであり、実際にこのように紛らわしい国際化ドメイン名を利用した詐欺などが発生する可能性は
80

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及導入及び実装に実装に関する取組
する取組み
取組み状況

極めて低いものと考えられる。
また、各ブラウザについても対策が検討されており、Mozilla や Opera などでは、国際化ドメイン名を持つ URL にアクセスした場合は、URL 欄に Punycode でドメイン名を表示するなどの方法により、問題が起こる可能性を軽減することが検討されている。ただし、この場合ユーザには Punycode に変換されたドメイン名が見えることになり、国際化ドメイン名のメリットのひとつである「わかりやすさ」が損なわれてしまう可能性がある。
そこで、Opera などでは一律に Punycode 表示にするのではなく、.jp や.kr のように登録にあたって厳格なポリシーを採用している TLD のドメイン名を表示する際には、マルチバイト文字のまま表示する方向で検討中とのことである。
なお、この国際化ドメイン名に関する脆弱性の問題については、各所から声明が出されている。
主なものは以下の通り。
ICANN Statement on IDN Homograph Attacks and Request for Public Comment
http://www.icann.org/announcements/announcement-23feb05.htm
株式会社日本レジストリサービス
国際化ドメイン名（IDN）のフィッシング詐欺脆弱性について
http://xn--wgv71a119e.jp/access/phishing.html
APTLD Statement
Regarding Phishing Using Homographs among IDNs
http://www.aptld.org/newsite/meeting/2005/02_Kyoto/file/idn-phishing.html
CENTR Statement on IDN Homograph Attacks
http://www.centr.org/docs/2005/02/homographs.html
3.2.2.3. まとめ
国際化ドメイン名を巡る動きとしては、非常に活発になってきているというのが最近の印象である。
各 TLD において国際化ドメイン名のサービスが開始されていることもあるが、ブラウザなどのアプリケーション分野において国際化ドメイン名のサポートが進んできていることも大きな要因として挙げられる。

81

第1部

第 3 章 国際化ドメイン
国際化ドメイン名
ドメイン名の導入及び導入及び実装に実装に関する取組
する取組み
取組み状況

実際、登録数を見ても国際化ドメイン名の登録数はどの TLD でも順調に増加しているようであり、また TV や雑誌の CM などで実際に国際化ドメイン名が使われてきているのを目にする光景も増えてきた。国際化ドメイン名を利用したフィッシング詐欺に関する脆弱性に関する報道なども、それだけ国際化ドメイン名が実際に使われることが増えてきたからこそ、これだけ話題になったのだと思われる。
しかしながら、一方でまだまだ国際化ドメイン名に対して否定的な見方をする人間が多いのもまた事実である。特に理由として多いのが「利用できる機会が少ない」「対応
しているアプリケーションが少ない」「ASCII 文字列でも特に困らない」などである。
このことからわかるように、国際化ドメイン名が今後さらに普及していくためには、
アプリケーションの対応のさらなる充実とともに、従来の 7bit ASCII のみからなるドメイン名では実現するのが難しかったような国際化ドメイン名ならではの利用法が広く世間に浸透することが重要であると考えられる。

82