「日本語JPナビ」に問題はないのか？（1/2 ページ）

　日本レジストリサービス（JPRS）は、この2月から日本語JPドメインの普及促進を主な目的として、「日本語JPナビ」（仮称）の導入を検討していることを1月19日に発表した。現在は導入に向けた意見を募集しているところである。

　このサービスの概要については別記事を参照していただきたいが、サービスの提供に当たって同社が管理するJPドメインのルートDNSを操作するため、未登録のドメインを自社のWebサイトに誘導しようとしたVeriSignの「SiteFinder事件」のようにならないかを懸念する声が一部にある。

　これに対し、同社はどのような対策を講じようとしているのだろうか。

SiteFinderの轍を踏まないための配慮の数々

　まずSiteFinderとの最大の違いは、日本語JPナビがあくまでも「既に登録済みの日本語JPドメイン」について、「ドメイン登録者の希望により提供される」サービスであるということだ。

　SiteFinderで問題になったのは、VeriSignが管理するgTLD（.com/.net）で未登録となっているドメインへの問い合わせ（DNS Query）があった場合、自動的に同社の管理するサーバ（以下「SiteFinderサーバ」）のIPアドレスを返答していたために、従来「存在しないドメイン」の確認にDNSを利用していたシステムが誤動作するなどの問題が発生していたことだ。

　だが、日本語JPナビでは問い合わせの対象となるのはあくまで「登録済みのドメイン」のみ。しかもドメインの登録者が希望しない限り、同サービスは提供されない。

　このため、JPRSでは同サービスの開始後、新規に日本語JPドメインを取得するユーザーについては登録時に同サービスの利用の有無を確認するほか、既存の日本語JPドメイン登録者についても、正式に同サービスの開始が決定した段階でJPドメインの登録を扱う指定事業者経由で同サービスを利用するかどうかの意思の確認を行う予定だ。

　また、SiteFinderにおいてはSiteFinderサーバ上でSMTPサービスが動作していたので、存在しないドメインに対しメール送信を行った場合にヘッダ・本文の送信が終わってから送信エラーが発生していた。このため、VeriSignが送信者のメールアドレス情報などを収集することが可能であったことも大きな問題となっていた。

　これに対しても、今回のサービスではDNSにダミーのMXレコード（Mail eXchangerレコード：メールを配送するホストの所在を示す情報）を登録することで、そもそもSMTP接続が行われないようにするほか、一部のMTA（Mail Transfer Agent）でMXレコードのアドレスへのSMTP接続が行えない場合、Aレコード（Addressレコード：ホスト名とIPアドレスの対応を示す情報）に示されたアドレスへの接続を試みるものがあることから（これはRFCの規定に違反している）、Aレコードで示されるサーバ（以下「JPナビサーバ」）ではSMTPサービスを動作させないようにするという。

　これ以外にも、VeriSignがIDN（Internationalized Domain Names：国際化ドメイン）登録者向けに行っている「Web Based Navigation（WBN）」サービスで、UTF-8以外のエンコード方式（Shift-JISなど）を用いた8bit表現でのDNS Queryも受け付けていることに対して、「ある8bit表現でのDNS Queryが（エンコード方式の異なる）複数のドメイン名に一致してしまう可能性がある」という批判がある。JPRSではこのことも考慮して「今回のサービスでDNS Queryを受け付ける8bit表現はUTF-8のみ」とすることを決定している。

　UTF-8のみとした結果、日本語JPナビを利用できる環境の中にWindows98/MEや、Internet Explorer 5.0/5.5が含まれないことになってしまったが、DNSに何より求められるのは「ドメイン名の一意性」であることを考えると、筆者個人としてはこの判断は賢明だと思う。

現段階でまだ煮詰まっていない点も多い

　このようにSiteFinder事件の二の舞にならないようにという意味での配慮は盛り込まれているものの、実際に同サービスを導入する局面を考えると、いろいろ気になる点も多い。

この記事の著者