PR

山本　和彦

肥大化するDNSを守ろう

　ここで，なぜ国際化ドメイン名ではなく，キーワード・サービスを私が推進しているのか，その理由を述べよう。

　国際化ドメイン名が多くの問題を抱えていることも大きな要因だが，最大の理由は今あるDNSのしくみが破綻するのを避けたいからだ。

　DNSとは，コンピュータ同士の通信に使うIPアドレスと，人間が覚えやすい半角英数字の名前（ドメイン名）の対応関係を管理するしくみである。DNSがなければ，メールを送受信したりWebページを閲覧するといった今のインターネット・アプリケーションが成り立たない。それほど重要な基盤技術なのである。

　DNSが扱うデータ量は時々刻々と増え続けている。この膨大なデータを，インターネットという広大なネットワークに分散した多数のサーバーが管理している。実のところ，これだけ大規模な分散型データベースがどうしてうまく動いているのかもよくわっていない。「インターネットの奇跡」と表現する技術者もいるほどだ。

　もちろん今も動き続けているDNSには，巨大なデータを分散して管理できる工夫が盛り込まれている。例えば，管理するサーバー群の構成をツリー構造に分散させ，それぞれのサーバーを多重化できるようにすることで，一つのサーバーにアクセスが集中するのを防いでいる。

　また，ドメイン名からIPアドレスを検索するクライアント（リゾルバ）側も，問い合わせ結果を一時的に保存しておくことで，問い合わせ件数を減らすように工夫している。

　しかしながら，DNSの全体像を把握することは困難である。系統的な性能評価も始まったばかりだ。最悪の場合，DNSはもうすぐ性能限界に達するかもしれない。

　少なくとも，新しいドメイン名が登録されるごとに，DNSは性能限界に近づいているのだ。そして，DNSが破綻すれば，インターネットそのものが滅んでしまう。私の主張は，「DNSは絶対に守るべき環境」であるということに尽きる。

　このように考えれば，DNSへ登録するドメイン名は，必要最小限にすべきである。会社は製品ごとにドメイン名を登録するのではなく，本来の目的通り，会社名のみを登録すべきだ。こうしておけば，新たにインターネットへ参加する会社のために，ドメイン名を残しておける。また，DNSに追加すべき機能（例えばセキュリティや公開鍵の配送）を，実現するための余地も生まれる。

矛盾に満ちた国際化ドメイン名

　次に国際化ドメイン名の問題点を洗い出しておこう。国際化ドメイン名では，文字コードとしてUnicodeを利用する。Unicodeでは，中国，日本，韓国の漢字が統合されるので，文字コードだけではどの言語か確定しない。しかし，国際化ドメイン名の標準化を進めているIDN分科会では，言語情報をどのように指定するかが，まだ決まっていない。

　言語情報がなくても，例えばjpドメインは日本語であると割り切って考えることは可能である。しかし，comやnetドメインなどの汎用トップ・レベル・ドメイン（gTLD）はどうするのだろうか。

　日本語ドメイン名を管理する日本レジストリサービス（JPRS）では，半角と全角や区別しにくい記号などから予想される混乱を避けるために，ドメイン名に利用できる日本語文字を制限している。言語を区別しないでgTLDでこのような制限を設けるためには，Unicode全体としての文字制限を考えなければならない。

　また，既存のDNSと互換性を持たせるため，国際化ドメイン名を使う場合，DNSサーバーへ検索要求を送るときは，半角英数字の文字列（ASCIIアスキー文字列）に変換することが IDNで合意されている。しかし，この変換方法も決まっていない。

　変換方法が決まっても，安易にその情報を公開するわけにはいかない事情もある。変換方法が一般に公開されれば，国際化ドメイン名の登録受付前に，変換後のASCII文字列のドメイン名が取得されてしまう可能性があるからだ。

図5　国際化ドメイン名の変換規則例（『国際化ドメイン名について』，情報処理2001年5月号より）
既存のDNSと互換性を保つため，国際化ドメイン名を使う場合，ドメイン名からIPアドレスを検索するときは，一定の規則に基づいて日本語などの文字列をアルファベットの組み合わせに変換して，通常のドメイン名と区別するために先頭にあらかじめ決められている文字列を付加する。ネットワーク・ソリューションズが2000年11月に開始した国際化ドメイン名の事前登録受付では，この変換規則が事前に知れ渡り，変換後のアルファベットによる文字列のドメイン名が不正取得されてしまった。
　実際，ネットワーク・ソリューションズ社（NSI）が2000年11月に始めた国際化ドメイン名の登録受付の前に，不正取得されてしまう事件が起こった。当時は，通常のドメイン名と国際化ドメイン名を区別する「先頭の文字列」と，変換方式が公開されていた。このため，変換後のASCII文字列を予測して，それを登録したのである（図5[拡大表示]）。

　この教訓に基づいて，IDNでは最終的な「先頭の文字列」を公開していない。しかし，これでは国際化ドメイン名に対応すべきWebブラウザや電子メール・クライアント・ソフトを開発することができない。

　アプリケーションが国際化ドメイン名に対応する難しさはほかにもある。例えば，

日経NETWORKへは＜A HREF= "http：//www.日経NETWORK.jp/"＞ここ＜A＞をクリック。

のような記述がWebページのHTMLデータ中にあったとしよう。通常，HTMLファイルはシフトJISなどの文字コードで記述される。ところが，国際化ドメイン名はUnicodeで記述することが決まっている。すると，「A HREF」以降のURLはUnicodeで記述すべきだろう。

　この結果，シフトJISのファイル中にUnicodeの文字列があるという，複雑なファイル形式になってしまう。このような特殊なファイルをアプリケーションが扱うのは，大変なことなのだ。

　多くの問題を抱える国際化ドメイン名の最終的な仕様は，この6月に決まると言われていたが，12月へと延期され，今では12月に仕様決定することも危ぶまれている。