　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サービスを動作させないようにするという。

日本語JPナビを利用するドメインにWebアクセスがあった場合の挙動

同じくメール送信要求があった場合の挙動

　これ以外にも、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に何より求められるのは「ドメイン名の一意性」であることを考えると、筆者個人としてはこの判断は賢明だと思う。