Skip to main content
Resources

登録データの確認に関するポリシー

このページは以下の言語でもご覧いただけます。

すべての翻訳されたコンテンツおよび文書の英語版が公式版であり、英語以外の言語の翻訳版は情報提供のみを目的として作成されたものです。

登録データポリシーの実施に必要な変更を反映するため、2024年2月21日に更新。このポリシーは、以前は「Whoisデータの確認に関するポリシー」と呼ばれていました。契約当事者は2024年8月21日から更新された本ポリシーを実施することが可能であり、遅くとも2025年8月21日までには実施する必要があります。

レジストラは、少なくとも年1回、現在の登録データを登録名所有者に提示し、不正な連絡先情報を提供した場合、ドメイン名登録が取り消される事由となり得ることを登録名所有者に通知する必要があります。登録名所有者は、登録データを確認し、修正する必要があります。


注記

はじめに:登録データの確認に関するポリシー(RDRP)(旧称、Whoisデータの確認に関するポリシー)は、2003年3月27日にICANNのコンセンサスポリシーとして採択されました。ICANN認定レジストラは、認定されたすべてのトップレベルドメインで、自身がスポンサーとなる登録について、RDRPに準拠する必要があります。遵守要件の詳細は以下の通りです。

ポリシー採択までの過程:RDRPは、ICANN理事会の決議03.41でコンセンサスポリシーとして制定され、 2003年3月27日のICANN理事会での13-1-0の投票により採択されました。2003年2月20日の21-3-0の投票により、分野別ドメイン名支持組織(GNSO)の評議会が、コンセンサスポリシーとして確立するよう提言したWhois問題に関する4つのポリシーの1つです。

GNSO評議会と理事会の投票は、Whois情報の正確性およびバルクアクセスに関する、GNSO評議会のWhoisタスクフォースの最終レポートに基づいて行われました。このレポートには、影響を受けるグループの間にあった意見の一致と不一致の数、影響を受ける可能性のあるグループの見解を十分に代表するために利用したアウトリーチプロセス、および提案されたポリシーに対する理由付きの賛成と反対の内容、およびかかる主張の強さが記録されています。

このレポートは、2003年3月11日にICANNのWebサイトに、一般からのコメントの募集付きで掲載されました。一般からのさまざまなコメントが届き、理事会が検討しました。また、このレポートについて、2003年3月26日にリオデジャネイロで開かれたICANN公開フォーラムのセッションで議論されました。

決議03.42に従い、2003年6月16日、このポリシーが採択されたことがすべてのレジストラに通知されました。

このポリシーの発効日から、各レジストラは、レジストラがスポンサーになっている各登録について、作成の応答日の前に、かかる登録の登録名所有者にRDRP通知 (以下に記載) を提供する必要があります。例として、契約日が2003年10月31日の場合、レジストラは、自身がスポンサーとなる登録のために、RDRP通知を以下のスケジュールで提供する必要があります。

2003年10月31日が契約日の場合
ドメイン名 作成日 RDRPの通知期限
example.com 1995年10月14日 2004年10月14日(以降は、毎年10月14日まで)
example.biz 2003年6月25日 2004年6月25日(以降は、毎年6月25日まで)
example.info 2003年6月15日 2004年6月15日(以降は、毎年6月15日まで)
example.net 1997年11月12日 2003年11月12日(以降は、毎年11月12日まで)
example.org 1993年1月1日 2004年1月1日(以降は、毎年1月1日まで)
example.example.name 2002年12月31日 2003年12月31日(以降は、毎年12月31日まで)

(注:作成日が2月29日の場合、登録のRDRP通知が提供される日は、うるう年ではない年には3月1日までとなります。)

RDRPの通知に含むべき内容:各RDRP通知には、登録データポリシーのセクション6に従ってレジストラが収集し、登録ごとにレジストラのデータベースに含まれているデータ要素のコピーが必要です。また、登録契約の条件に基づき、不正な連絡先情報を提供した場合、ドメイン名の登録が取り消される理由になり得ることを登録名所有者に説明する記述も必要です(レジストラ認定契約、セクション3.7.7.2を参照)。

RDRP通知を提示する方法と提示先:RDRP通知は、Web、ファックス、郵便、電子メール、またはその他の適切な手段で提供できます。少なくとも登録契約の言語を含む、1つ以上の言語で提供できます。

文書の要件:このポリシーに基づき送付された各RDRP通知について、レジストラはRDRP通知のコピー、あるいは日時と内容を記録している電子データベースのいずれか一方を保持する必要があります(レジストラ認定契約、セクション3.4を参照)。レジストラは、レジストラ認定契約の通常の条件に従い、ICANNがこれらの記録を検査できるようにするものとします(セクション3.4.3を参照)。前に説明した要件を満たすRDRP通知が、登録作成日の応答日(契約応当日当日または契約日の後)の前年のある時期に提供されたことを、レジストラが示すことができる場合、登録に対して適切な通知が提供されているICANNは見なします。

RDRP通知の見本:必要な通知をレジストラが用意するのをサポートするため、ICANN では以下のRDRP通知の見本を用意しています。


[サンプル】登録データの確認

 

大切なお客様へ

このメッセージは、ドメイン登録に関連する連絡先データを最新の状態に保つための、ご連絡です。当社の記録には以下の情報が含まれています。

Domain: example.com
Registrar Name: IANA_RESERVED

Registrant:
Name: Internet Assigned Numbers Authority (IANA)
Address: 4676 Admiralty Way, Suite 330
City: Marina del Rey
State/Province: CA
Country: US
Postal Code: 92092

Technical Contact:1
Name: Internet Assigned Numbers Authority (IANA)
Phone: 310-823-9358
Email: res-dom@iana.org

Original Creation Date: 11/01/2001
Expiration Date: 11/01/2001

Nameserver Information:
Nameserver: a.iana-servers.net.
Nameserver: b.iana-servers.net.
Nameserver: c.iana-servers.net.

上記の情報に不正確な点があれば、当社のWebサイトで訂正してください。(ご確認になった結果、すべての情報が正しければ、特に何もしていただく必要はありません。)登録契約の条項に基づき、不正な連絡先情報が提供された場合、ドメイン名登録を取り消す理由となる場合があることにご留意ください。

よろしくお願いいたします。

敬具
ICANN認定レジストラ

レジストラントの観点から見た、RDRPに関するよくある質問はここから閲覧できます。


1 注: 登録データポリシーのセクション6に従って技術担当の連絡先が収集される場合。

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."