今回のテーマは「国際化ドメイン名(IDN:Internationalized Domain Name)」。要はいわゆる「日本語ドメイン」などを実現する仕組みのことなのだが、日本語ドメイン自体まだあまり普及したとはいえない状況の上、このIDNが原因とされるWebブラウザのセキュリティホールの話題が騒がれるなど、ここのところIDNにやや逆風が吹いている感がある。そこで今回は、そもそもIDNとはどのような仕組みで実現されているのか、なぜIDNがセキュリティホールとして騒がれたのかという点についてまとめてみたい。
■IDNを実現する仕組みとは?
IDNの定義については冒頭で述べたとおりなので、今回はまずIDNがどのように実現されているかという仕組みの部分から解説していこう。
そもそもインターネットのドメイン名については、DNSの基本的な仕組みを規定したRFC1034/1035の中で「アルファベットのA-Z(大文字・小文字は区別しない)、数字の0-9、“-”、“.”」以外の文字は使えないことになっている。そのため、BINDやdjbdnsなどの広く普及しているDNSサーバーソフトでも、それ以外の文字をドメイン名としてDNSレコードに定義した場合の動作は基本的に保証されていない。ではなぜ日本語ドメインが利用できるのかというと、そこで登場してくるのが「Punycode」という仕組みだ。
このPunycodeとは、ひらたく言ってしまうと「漢字やひらがな・カタカナなどの文字をドメイン名に使う場合に、それらの文字列を一定の規則に従ってアルファベットと数字でできた文字列に変換する」仕組みの一種だ。IDNを使う場合は、DNSサーバー上にこのPunycodeで変換した後のドメイン名(例:「インプレス.jp」→「xn--eckzbzevd7a.jp」)を使って情報を登録するようにする。これにより、DNSサーバーソフト自体には全く変更を加えることなく、IDNが利用できる仕組みになっている。
ここで「もし『xn--eckzvzevd7a.jp』というドメイン名を“たまたま”登録しようとした人がいたら、ドメイン名がバッティングしてしまうんじゃ……」と思ったあなた、その指摘は鋭い。しかし実際にはそのようなことは起きない。現在では、ドメイン名の頭に「xn--」という4文字が付くドメインは「これはIDNのためのドメインですよ」と自動的に判断されるように、ドメイン名を管理する国際組織であるICANN(Internet Corporation for Assigned Names and Numbers)の方であらかじめ決められているからだ。そのため、もしユーザーが「xn--」で始まるドメイン名を直接登録しようとしても、それは全て却下されるようになっている。
このように、DNSサーバー側ではIDNの導入に伴い一切ソフトを変更しないで済む代わりに、クライアント側では原則としてWebブラウザやメールソフトなどのアプリケーションが個別にIDNに対応しなくてはならなくなった。例えば、ユーザーがWebブラウザのアドレス欄にIDNを打ち込んだ場合、ブラウザはその入力内容をPunycodeの変換規則に従ってアルファベットと数字による文字列に変換した上で、DNSサーバーに問い合わせを行なう。IDNに対応するには、各アプリケーションがPunycodeへの変換機能を内部に持つ必要があるのだ。
この「アプリケーション側が個別にIDNに対応しなければならない」という点がネックとなり、IDNの普及は今のところ予想ほどには進んでいない。例えばInternet Explorerはいまだに(プラグイン等を使わない限り)IDNには未対応だし、携帯電話等に搭載されているWebブラウザでもIDNに対応しているものはほとんどない。
■IDNの「セキュリティホール」とは2つの問題が複合したもの
しかし、Mozilla SuiteやFirefox、OperaなどIDN対応のソフトは着実に増えつつあるし、実際の利用例も増加している。そんな中起こったのが先日のセキュリティホール騒動だったわけだが、いったい何が問題だったのか。
これは一言で言ってしまえば「ブラウザの見た目の問題」と「ドメインレジストリの登録ポリシーの問題」の2つが重なったものだ。具体例を見てみよう。
1)www.example.com
2)www.еxample.com
1)は普通の英数字のドメイン名。2)は最初の「e」がロシア文字の「е」になっているドメイン名だ。この2つのドメイン名をWebブラウザで表示した例を見ると、日本語版Windowsでは区別がつきやすいが、英語版のWindowsではほとんど区別ができない。OSやWebブラウザが使用するフォントによっては、この2つが同一のアドレスに見えてしまうというのが1つ目の問題だ。
|
|
日本語版Windowsでの表示例。「www.example.com」(上)と「www.еxample.com」(下)の区別はつきやすい
|
英語版Windowsでの表示例。「www.example.com」(上)と「www.еxample.com」(下)の区別はほとんどつかない
|
しかし、このような「紛らわしいドメイン名」のリンクをクリックした場合でも、「本来ユーザーが意図していたアドレス」に自動的にジャンプするか、もしくは「そのアドレスは存在しません」としてエラーになってくれれば問題はない。ここでもう1つ問題なのが、「このような『紛らわしいドメイン名』について、レジストリ側が登録を許してしまう」可能性があることだ。もし悪意を持つユーザーが「紛らわしいドメイン名」を取得することができるようだと、それこそそのドメイン名を利用したフィッシング詐欺などが行なわれかねない。
日本語.jpドメインを管理するJPRSでは、「この問題については既に対策済み」と発表しているが、中にはこのような「紛らわしいドメイン名」の登録を未だに許しているレジストリがないとも限らない。しかし今まで述べてきたことを裏返せば、たとえ「紛らわしいドメイン名」が登録されていたとしても、見た目でそれが区別できるようになっていれば問題は回避できる、ということになる。
そこでWebブラウザ「Firefox」のバージョン1.0.1では、URLの直接入力やリンクでIDNを利用したサイトに飛んだ場合に、IDNをPunycodeに変換した後のアドレスを表示するように仕様が変更された。こうすることで、万が一IDNを利用した「怪しいサイト」にアクセスしてしまった場合でも、URLのところに「xn--」で始まるアドレスが表示されるため、見た目ですぐに問題があることがわかる、というわけだ。
とはいえこのような問題も、実際にIDNのユーザーが増加していろいろな利用例が出てきたからこそ出てくるもの。逆に言えばもっとIDNを利用することで、このような問題を早めに明るみに出して、問題の芽を早いうちに摘み取ることも可能になるという側面もある。マイナス面だけに目を向けて、IDNの可能性を摘み取るようなことがないよう、一ユーザーとしては願っている。
■関連記事
・ 国際化ドメイン名がフィッシングに悪用される問題~Secuniaなどが指摘(2005/02/08)
・ IDNの“脆弱性”はブラウザではなくレジストリ側の運用面の問題~JPRS(2005/02/09)
・ ICANN、IDNを悪用したURLの“偽装”問題について声明(2005/02/24)
・ Mozilla Japan、「Firefox 1.0.1」日本語版公開(2005/03/14)
(2005/03/31)
|
佐藤 晃洋
1975年北海道旭川市生まれ。某通信事業者での法人営業(という名の現場調査員)を経て、現在は通信・ネットワーク関連を主な専門分野とするテクニカルライター。ついでになぜか煎茶道の師範もやっている。 |
- ページの先頭へ-
|
|
|
Copyright ©2005 Impress Corporation, an Impress Group company. All rights reserved. |
|