ニュースレターNo.28/2004年11月発行

レジストラ変更の新ポリシーが2004年11月12日より施行

2004年11月12日、gTLDドメイン名のレジストラ変更に関する新ポリシーが施行されました。ここでは、新ポリシーの概要をご紹介します。

ICANNによって策定されたgTLDドメイン名のレジストラ変更に関する新ポリシーが、2004年11月12日より施行されました。この新ポリシーは、gTLDドメイン名の登録者がより円滑に登録先レジストラの変更を行えるよう、手続の統一化および明確化を図り策定されたものであり、2004年11月12日以降に行われるすべてのレジストラ変更に適用されます。

なぜ新ポリシーが導入されたの？

ドメイン名登録者が、登録先レジストラを現在のレジストラから別のレジストラに変更したい場合、登録者は変更先の新レジストラに対してレジストラ変更要請を行い、新レジストラは、変更手続を進める前に、確認のために登録者から許可を得ることになっています。また、現レジストラも、任意で登録者に意思確認を行います。

従来のポリシーでは、こうした登録者に対する意思確認のプロセスが明確化されておらず、レジストラ側の対応が統一されていなかったために、登録者への意思確認が十分になされないまま、知らない間に第三者によって不正にレジストラ変更が行われるといった問題が一部で発生していました。

また、現レジストラが変更要請を拒否する際の基準も不明確であったことから、現レジストラが不当に変更拒否をしたり、プロセスを遅延させているといった批判が、他のレジストラから寄せられるケースもありました。

こうした問題が表面化してきた2001年以降、ICANNにおいて問題解決のための検討が続けられ、レジストラ変更の手続を統一化・明確化するための新たなポリシーが策定されることになりました。その後2003年4月になって、検討結果をまとめたポリシー勧告がICANN理事会によって採択され、さらに2004年7月、手続の詳細を定めた文書が新ポリシーとして発表されました。

新ポリシーによってなにが変わるの？

新ポリシーでは、以下のような仕組みが新たに導入されています。

●第三者による不正なレジストラ変更を防止するための仕組み

標準書式の使用
新ポリシーでは、レジストラが登録者（または管理担当者^☆1へ意思確認を行う手順を統一し、下記の標準書式を使用することが定められています。

Form GR（Standardized Form for Gaining Registrars）
http://www.icann.org/transfers/foa-auth-12jul04.htm
（新レジストラが、登録者（または管理担当者）に対してレジストラ変更を許可するかどうか確認する際に使用。登録者（または管理担当者）が指定の期日までに指定の方法によって返答した場合のみ、レジストラ変更の手続が進められる。）
Form LR（Standardized Form for Losing Registrars）
http://www.icann.org/transfers/foa-conf-12jul04.htm
（現レジストラが、任意で登録者（または管理担当者）に対してレジストラ変更の意思確認を行う際に使用。）

※レジストラは、自らの責任で標準書式を英語から別の言語に翻訳して使用することができます。

本人確認の導入
　登録者（または管理担当者）が新レジストラに対してレジストラ変更の許可を行う際には、電子署名や電子メールアドレス（電子的方法による場合）、または、パスポートや運転免許証（郵便などの電子的でない方法による場合）などによって本人確認を行い、変更要請が登録者（または管理担当者）本人からなされた真正なものであることを証明する必要があります。
連絡担当者の規定
　登録者からレジストラ変更要請を受けた新レジストラが、登録者に標準書式を送付してレジストラ変更の許可を求めた際には、登録者およびWhoisに記載されている管理担当者のみが「レジストラ変更の連絡担当者」として、レジストラ変更を許可もしくは却下する権限を持ちます。
認証コード（AuthInfo Code）の使用
　「.org」「.biz」「.info」といった、レジストリがEPP^☆2を採用しているgTLDの場合、レジストラ変更要請を行う登録者は、当該ドメイン名に割り当てられている認証コード（AuthInfo Code）を現レジストラから取得し、変更要請の真正性を証明するための材料として新レジストラに提出する必要があります。

●レジストラ変更に伴う紛争を解決するための仕組み

現レジストラまたは新レジストラのいずれかが、レジストラ変更要請がポリシーの規定通りに取り扱われていないと判断した場合には、「レジストラ変更における紛争処理方針」（TDRP）に基づいて紛争処理手続を開始することができます。

Transfer Dispute Resolution Policy（TDRP）
http://www.icann.org/transfers/dispute-policy-12jul04.htm

新ポリシーでのレジストラ変更プロセスは？

新ポリシーでのレジストラ変更は、以下のプロセスで進められます。

登録者（または管理担当者）が新レジストラにレジストラ変更を要請する（レジストリがEPPを採用しているgTLDの場合は、認証コード（AuthInfo Code）を提出）。
新レジストラは、当該ドメイン名のWhois情報が有効であるか確認した後、登録者（または管理担当者）に連絡を取り、レジストラ変更を許可するかどうか確認する（その際、標準書式「Form GR」を使用）。
登録者（または管理担当者）は、レジストラ変更を許可（もしくは却下）する旨の返答を行う。その際、本人確認が必要となる。
新レジストラは、レジストラ変更要請が真正であることを確認した後、レジストリに対しレジストラ変更の要請を行う。
レジストリは、新レジストラからの要請を受け取り次第、現・新双方のレジストラに通知を行う。
現レジストラは、レジストリからの通知を受領した後24時間以内に、任意で登録者（または管理担当者）に対してレジストラ変更の意思確認を行う（その際、標準書式「Form LR」を使用）。

※現レジストラがレジストリに対し5日以内に返答しなかった場合は、レジストラ変更を承認したものとみなされる。

レジストリはレジストラ変更処理を行い、双方のレジストラに通知する。
新レジストラは、登録者にレジストラ変更手続が完了した旨を通知する。

（JPNICインターネット政策部　入交尚子）

参照URL

レジストラ変更に関する新ポリシー（2004年7月12日）: http://www.icann.org/transfers/policy-12jul04.htm
レジストラ変更に関する情報ページ: http://www.icann.org/transfers/

☆1　管理担当者：: 現レジストラもしくはレジストリのWhoisに、当該ドメイン名の管理担当者（Administrative Contact）として記載されている者
☆2　EPP：Extensible Provisioning Protocol: レジストリ・レジストラ間の通信において登録者情報のやりとりが可能なプロトコル