新たなドメインの展開〜汎用ドメイン/多言語ドメイン
特にここ数年、DNSではgTLDの新たなドメイン名の創設などの話題には事欠かない。また日本においても、大変大きな変化が押し寄せている。こうした新たな段階に入ったドメイン名の最新動向についてまとめてみよう。
●汎用ドメイン
汎用ドメインとは、「atmarkit.jp」など、従来まで組織種別や地域別ドメイン名しか用いてこなかった「.jp」ドメインにおけるSLDを、利用者が自由に取得できるようにしようというものである。今年春ごろに登録が開始されたというニュースを聞いた読者も多いだろう。一言でいえば、「.jp」ドメインにおける「.com」ドメインなど、gTLDを指向したイメージのあるドメイン要件となっている。
「.jp」ドメインとしての特性から、取得者の要件としては日本国内に居住する個人や団体に限られるものの、業種などの資格要件はなく、自由に取得できる。また、従来の組織種別や地域別ドメインとは異なり、一個人や組織で複数のドメインを登録可能だ。すでに組織種別や地域別ドメインを別途取得していても問題ない。
すでに述べたが、汎用ドメインの登録管理ではJPRS(日本レジストリサービス)に移管され、JPRSが認定したレジストラが実務を代行するという新しい試みも行われている。これまで日本では実施されてこなかった新しいドメイン管理の仕組み作りの試金石ともなることだろう。
●多言語ドメイン(日本語ドメイン)
汎用ドメインとほぼ時期を同じくして導入されつつあるのが多言語ドメイン(IDN:Internationalized Domain Name)だ。レジストラの広告などでは、「日本語ドメイン」「日本語.com」「日本語.jp」などと表記されるが、実際には日本向けだけの仕組みではない。多言語を考慮した、汎用的なDNS機能の追加として考えられている。
多言語ドメインは「アットマークアイティ.jp」など、従来ASCIIのみでしか表現できなかったgTLD(「.com」「.org」「.net」)とjpドメインのSLD名を、多言語環境へ展開するための仕組みである。日本語/韓国語/中国語/アラビア語などのネイティブな文字コードを、URLやメール・アドレスなどに使用できることを目指している。仕様を主導しているのは、IETFのInternationalized Domain Name(IDN)ワーキンググループである。
しかしながら、多言語ドメインではネイティブな文字コードをそのまま使用するわけではない。それでは英語圏のユーザーとの整合性の問題も発生しかねないため、ちょっとしたトリックでこれを回避しようとしている。多言語ドメインでは、各国のネイティブ言語をUTF8などで表現し、これにACE(ASCII Compatible Encoding)と呼ばれるUTF8からASCIIへのエンコードを施す。つまり最終的には、これまでのドメイン名とコード上は同一(ASCII)の表現にして、DNSへの登録や利用を行うこととなっている。
従来の多言語ドメインに対応していないアプリケーションなどから見ると、単なる意味不明な文字列が設定されたドメイン名に見えることだろう。しかし、このままでも使用できないこともない。多言語ドメイン対応アプリケーションでは、このドメインが多言語ドメインであることを検知、デコードして、WebブラウザのURL部分やメーラのメールアドレス部分に表記することになる。入力を受け付ける場合は、その逆だ。つまり、これまでの直接的なドメイン入力や表示機能に、もう1階層だけ仮想的な変換機能が加わらなければならない、ということになる。また、実際に使用されるドメイン名では大文字と小文字は区別しないなど、単なるコード変換だけでは対処できない問題もある。こうした書式を統一する「正規化(Name Preparation)」機能も必要になる。
これらの機能*4によって、登録された多言語ドメインを欧米圏のユーザーでも共有できる可能性を、最低限残すことができる。
*4JPNICでは、多言語ドメインの評価キットを開発、提供しており、例えば「ping」や「tracert」コマンドを多言語ドメイン機能に対応させることができる。Windowsでも簡易に試用できるうえ、DUDEやRACEの各種ACE方式にも対応している。下記のURLを参照してほしい
http://www.nic.ad.jp/jp/topics/archive/2001/20010604-01.html
> set type=any > bq--3cnnqxhwlrfq.jp Server: [210.128.152.27] Address: 210.128.152.27 bq--3cnnqxhwlrfq.jp internet address = 210.128.152.68 bq--3cnnqxhwlrfq.jp nameserver = dns0.ibps.ne.jp bq--3cnnqxhwlrfq.jp nameserver = dns1.ibps.ne.jp bq--3cnnqxhwlrfq.jp primary name server = dns0.ibps.ne.jp responsible mail addr = postmaster.ibps.ne.jp serial = 2001060402 refresh = 7200 (2 hours) retry = 3600 (1 hour) expire = 604800 (7 days) default TTL = 86400 (1 day) bq--3cnnqxhwlrfq.jp nameserver = dns0.ibps.ne.jp bq--3cnnqxhwlrfq.jp nameserver = dns1.ibps.ne.jp dns0.ibps.ne.jp internet address = 210.128.152.26 dns1.ibps.ne.jp internet address = 210.128.152.27 >
だが、多言語ドメインの仕様は、実はまだ確定されていない。問題になっているのは、エンコード/デコードの手法だ。ACEには、実際には複数の方法が提案されている。RACE(Row-based ASCII Compatible Encoding)、BRACE(Bi-mode Row-based ASCII-Compatible Encoding)、DUDE(Differential Unicode Domain Encoding)など乱立している(2001年12月のIETF総会で標準化の見通しが出された。追記を参照のこと)。
DUDE方式 | dq--j0a2s3otevcqfiks6q3.jp |
---|---|
RACE方式 | bq--gcrmhsg67sx2fjggum.jp |
BRACE方式 | 3inc5k7xy7x4b6eji-8q9.jp |
表4 各方式で「アットマークアイティ.jp」をエンコードしてみた。方式によってこれほど見事に異なる。なお、「dq--」や「bq--」などの先頭文字列は、エンコード方式を示す目印だ。ただし正式決定時には変更される予定だ |
実は、「.com」ドメインなどの登録管理を行うVGRSやJPNICでは、昨年度から多言語ドメインの登録受け付けを行っており、実際にテスト・ベッドと呼ばれるテスト・フェーズでDNSゾーン登録も開始している。VGRSでは、すでに350を超える言語でのテスト登録が可能だ。ただし、ACE方式が確定されていなかったため現在はRACE方式を暫定的に採用している。ACE方式が確定され、標準化(RFC化)され次第、RACEから標準方式に切り替えてテストから運用へ移行することを、VGRSを管理するVeriSign社が発表している。JPNIC(またはJPRS)も、おそらくjpドメインにおいて同様の経緯をたどることになるだろう。
だが残念ながら、正式にACEが決定しDNSに登録されたとしても、これだけでは多言語ドメインが使える環境にはならない。その後アプリケーション側の対応が行われなければならないからだ*5。ACEなど、変換機能をクライアント側に実装する方法とサーバで対応する方法が考えられるが、いずれにせよ、現在の主要製品ではほとんど対応できていない*6。完全に多言語ドメインが普及するには、いましばらくの時間がかかりそうだ。
*5本来考えられている方法とは異なるが、2001年6月にVeriSign社はIE 5.x以上で多言語ドメインが利用できるようになったと発表した。これは、IEに日本語などが入力された場合、検索を指示されたと判断してMSNサーチのサイトが検索結果を自動的に返答するのだが、文字列の最後が「.jp」などの場合には多言語ドメインであると見なして、ACEエンコード(現在はRACE方式)によりURLを自動生成し、そのWebサイトへ導くという方法だ
画面1 IE5のアドレスバーに「セガ.jp」(「www.セガ.jp」ではない。また「http://〜」も付けてはいけない)と入力すると、自動的にセガのサイトへリダイレクトされる。アドレスバーでは、RACEでエンコードされたURLになっているのが分かるだろう
もちろん、Webブラウザ(しかもIEのみ)で有効なものだが、ほんの少し多言語ドメインを体験してみたいという方には手ごろな方法だろう。
*6筆者が確認する限り、Webブラウザでは現在Opera 6.0(Windows版で確認)がネイティブでRACE方式に対応しているようだ。ただし、これもDUDE方式が正式に採用された時点で、次バージョンなどでの対応が必要になることだろう
最終回の次回は、実際にドメインを構築するうえで必要になるであろう、さまざまな前提条件やヒントについて見てみたい。
Copyright © ITmedia, Inc. All Rights Reserved.