Skip to main content
Resources

有効期限が切れたドメイン名の登録回復ポリシー

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

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

  1. 期限切れレジストラント

    1.1. 期限切れレジストラント(RAE)はその登録期間の満了の直前にドメイン名を更新する資格のある登録ドメイン名所有者であると定義されます。

    1.2. ドメイン名の登録がその満了に関連して登録データの修正を認可する登録契約書の条項に従って修正される場合、RAEはその修正の直前の登録ドメイン名所有者である法人または個人であると認められます。他の全てのgTLD登録とレジストラント間の移転においては、登録証明書を受け取る登録名保有者がRAEであると認められます。

  2. 登録の更新

    2.1. 期日のリマインダ通知

    2.1.1. あらゆるgTLD登録の満了に先立って、レジストラは少なくとも2回その期日について登録名保有者に通知する必要があります。そのうちの1つは期日のおよそ1か月前、もう1つはおよそ1週間前にされる必要があります。登録は登録契約の規定に従い、かつ登録の満了によって(1.2に記載)、他の登録名保有者に移転される場合、これらの更新通知はRAEに代わって送信される必要があります。これらの手順は、レジストラがさらに多くの通知を送付するのを妨げるものではなく、ただ少なくとも2回の通知を必要な時期に行うように設けられたものです。

    2.1.2. 登録満了後5日以内にRAEによって更新されなかった場合、あるいはレジストラによって削除された場合、レジストラは登録の更新についての指示を含む追加の満了通知を最低1回RAEに送付する必要があります。

    2.1.3. 満了通知は1つ以上の言語で記述されますが、登録契約と同じ言語が使用される必要があります。また、電子メールのように、受信側が通知を受け取るのに特別な操作を必要としない手段によって送付される必要があります。

    2.2. 期限満了後の更新

    2.2.1. 適用されるコンセンサスポリシーとレジストラ認定契約(RAA)の条項に従って、レジストラは期限の満了した登録をいつでも削除できます。

    2.2.2. 満了から8日以内に削除された登録について:その登録の期間満了から削除までの間、レジストラは有効なレジストリが許可する範囲においてRAEによって規定される既存のDNSの名前解決パスを遮断する必要があります。

    2.2.3. 満了から8日後以降に削除された登録について:少なくともRAEによる登録の更新が可能である最後の8日間(満了後の)、レジストラは有効なレジストリが許可する範囲においてRAEによって規定された既存のDNSの名前解決パスを遮断する必要があります。

    2.2.4. 登録されたDNSの名前解決パスの遮断中、RAEによる更新可能期間内にレジストラが当該ドメイン名へのWebトラフィックをWebページに誘導した場合、そのWebページはそのドメイン名の契約が満了していることを明確に示し、また更新の指示を表示する必要があります。

    2.2.5. 期限満了直後からパラグラフ2.2.2と2.2.3で説明されているDNSの解決の遮断期間を通じて、RAEは期限の満了した登録を更新するためにレジストラの許可を得る必要があります。

    2.2.6. RAEによる登録の更新後、レジストラはRAEによって規定されたDNSの名前解決パスを直ちに、あるいは商業的に可能な範囲で出来るだけ早く修復する必要があります。

  3. 再登録猶予期間

    3.1. 保証されたgTLDレジストリを除き、全てのgTLDレジストリは登録削除後ただちに30日間の再登録猶予期間(RGP)を設ける必要があり、その期間の間、削除された登録はRAEの要求により登録を削除したレジストラによって復旧されることができます。レジストリの追加猶予期間に削除された登録は、該当する場合、RGPの対象にするべきではありません。

    3.2. 再登録猶予期間の間、レジストリはDNSの解決を無効とし、その登録のデータ転送を禁止する必要があります。ICANNによって是認されたデータの転送と部分的に許可されたデータの転送はこの禁止の影響を受けません。また、レジストリはそのWhois情報上で再登録猶予期間内にある登録を明示する必要があります。

    3.3. RGPがそれぞれのレジストリによって設けられたものならば、レジストラはその期間内にRAEが削除された登録を回復するのを許可する必要があります。

  4. レジストラントへの費用と手順の通知

    4.1. gTLD名の登録の際、レジストラは登録ドメイン名保有者と見込み登録名保有者に対して請求する更新手数料、期限後の更新手数料(差額が生じる場合)、請戻し/回復の費用を適正にする必要があります。

    4.1.1. 最低限これらの費用はレジストラのWebサイトに明示され、またそのページへのリンクがレジストラの登録契約に含まれる必要があります。Webサイトを通じてそのサービスを提供または供給しないレジストラは、少なくとも登録契約にこれらの費用を含む必要があります。

    4.1.2. さらに、レジストラはこれらの費用が販売業者のWebサイトに表示されることを確認しなければなりません。

    4.2. レジストラはそのWebサイトで(使用される場合)第2項に記載されている期間満了前後の通知に使用する手段を説明する必要があります。

    4.2.1. 上記の説明には通常、使用される通信チャネル/メディアと通知が送付される連絡先の識別情報(たとえば、登録名所有者の電子メールアドレス、管理者の電話番号、顧客の住所など)が含まれている必要があります。

    4.2.2. レジストラの登録契約には、通知方法に関する同様の説明またはこの情報が利用可能なWebサイト上の該当するページへのリンクが含まれていなければなりません。

    4.2.3. さらに、レジストラは通知方法が販売業者のWebサイトに表示されること確認する必要があります。

    4.3. ICANNが適切なドメイン名の管理とgTLD登録のオンラインでの更新と再登録について記載したレジストラント向けの教育資料を公表するときには、レジストラは、ICANNからの適切な通知ののち、この教育資料を(あるいはレジストラによって特別に認められた同様の資料)、以下の手順によって登録名所有者が入手できるようにする必要があります。

    4.3.1. 登録処理の完了直後に登録名所有者に送付される通知とその後のすべての(Whois情報リマインダポリシー<http://www.icann.org/resources/registrars/consensus-policies/wdrp>によって要求される年次通知のような)Whois情報の正確さのリマインダ通知にこのマニュアルへのリンクを含めること。

    4.3.2. 登録が申し込まれるWebサイトに最低限レジストラ認定契約や関連するコンセンサスポリシーに従って表示されたリンクと同等に明確で目立つ方法と場所でこの資料へのリンクを表示すること。

備考

導入とその背景 ICANN At-Large諮問委員会の要求に応じ、2008年12月5日にICANNは有効期限後のドメイン名の復旧に関する報告書 <http://gnso.icann.org/issues/post-expiration-recovery/report-05dec08.pdf> [PDF, 422 KB]を公開しました。ジェネリックドメイン名支持組織評議会(GNSO)は2009年5月にその手順の策定検討を開始し、その結果いくつかの手順とその過程の提案書<http://gnso.icann.org/en/resolutions/#201107>が、ICANN理事会に提出されました。ICANN理事会はこれを2011年10月28日に是認し<http://www.icann.org/en/groups/board/documents/resolutions-28oct11-en.htm#1.5>、スタッフにこの手順に従うよう求めました。

有効期限が切れたドメイン名の登録回復ポリシーは、通信における明確な最低必要条件を設定する、規定された条件下において登録の更新と再登録を一様に可能にする、レジストラントへ与える資料の作成と普及促進などのレジストラの行為によって、レジストラントの要望に応えることを目的としています。

有効期限が切れたドメイン名の登録回復ポリシーはGNSOによって是認され、ICANN理事会によって採択された手段の提案書の意図と要求を確実に満たすため、GNSOによって召集された実施審査チームとの協議によって策定されました。

すべてのレジストラとレジストリは2013年8月31日.よりこの手順に従うことを求められています。

期日のリマインダ通知:GNSOによる手順の提案書には期限前の更新通知のタイミングについてある程度の柔軟さを認めています。たとえば、パラグラフ2.1.1に記載されているおよそ1か月および1週間前に送付されることが求められている更新通知が期日の26~35日および4~10日前に送付されたとしても、手順に従っているとみなされます。

期限満了後の更新:パラグラフ2.2.4はレジストラがRAEによる更新が可能な期間内にドメイン名へのWebトラフィックをWebサイトへと誘導した場合、レジストラが期日の通知と更新の説明を示す必要があることを説明しています。明確には、この要求はパラグラフ2.2.2と2.2.3に記載されている期間のみならず、RAEによって登録が更新可能であるすべての期間において適用されます。この項によって要求される更新指示は必ずしも複雑なものである必要はなく、単にRAEをレジストラのWebページ上の適切な箇所へと直接誘導できるものであれば十分です。

パラグラフ2.2.2は登録がその満了日から8日以内に削除された場合にレジストラが登録のDNSの名前解決パスを遮断する必要がある期間について説明しています。例として、登録が10月1日に期日を迎え、10月3日にレジストラがその登録名を削除した場合、DNSの名前解決パスは10月1日から3日まで遮断される必要があります。パラグラフ2.2.3は登録がその満了日から8日以上経過した後に削除された場合にレジストラが登録のDNSの名前解決パスを遮断する必要がある期間について説明しています。たとえば、登録が10月1日に期限切れになり、レジストラがドメイン名を10月20日に削除する場合、名前解決パスは少なくとも10月12日から20日までの期間にわたり遮断されなければなりません。

パラグラフ2.2.6はRAEによって規定されたDNSの名前解決パスをレジストラが直ちに、あるいは商業的に可能な範囲でできるだけ早く修復することを要求しています。「商業的に可能な範囲」という文言はこの場合、たとえばDNSの名前解決パスの修復に人的な介入が必要な場合や、期日後更新が祝日やその他の休業日に行われ直ちに修復できない場合を容認することを意図して用いられています。

レジストラントへの費用と手順の通知:パラグラフ4.1.1は、登録契約に(利用される場合にはレジストラのWebページにも)少なくとも更新手数料、期限後の更新手数料(差額が生じる場合)、請戻し/回復の費用を記載することをレジストラに要求しています。しかしながら、特に更新手数料が登録手数料よりも高額になる場合や移転手数料が生じる場合に、レジストラントが情報を得た上で決断をすることができ、また混乱を避けるため、レジストラはこれらの料金を十分に目立つ方法で公開することが奨励されています。

推奨されるベストプラクティス:GNSO は、以下の最適な実施方法をレジストラに奨励しています:

  • パラグラフ2.1.2で説明されている期日後通知が、通常当該ドメインを用いた連絡先に送付されていて、この送付が期日後の手続き(パラグラフ2.2.2と2.2.3に記載されているようなDNS 解決の妨害など)によって妨害されることが分かっている場合、期日後通知は(存在する場合)登録名所有者と関連する他の連絡先に送付される必要があります。
  • 登録が満了した場合にリマインダを送信することが出来るよう、レジストラは登録名所有者にそのドメイン名を使用しない電子メールアドレスを用意することを勧める必要があります。
  • パラグラフ4.2によって求められている通信手段の説明の中には通知が送付される元のレジストラの電子メールアドレスを記載し、登録ドメイン名所有者がスパムフィルターソフトウェアにブロックされることなく通知の電子メールを受信出来るようそのメールアドレスを「安全な送信先」として登録するように推奨してください。

手順に従う時期:すべてのICANN認定レジストラとgTLDレジストリはこのERRPに2013年8月31日までに従う必要があります。2.1節は全てのgTLDレジストラントに期日前通知を送付するようレジストラに求めています。レジストラはこれらの通知をERRPに従って8月31日より送付することを求められています。つまり、登録が2013年8月31日以降30日以内に期日を迎える場合、レジストラは期日1か月前のリマインダを送付する必要はありません。同様に、もしある登録が2013年8月31日から 7日以内に期日を迎える場合、レジストラは期日1週間前のリマインダを送付する必要はありません。しかしながら、レジストラはRAAの3.7.5節に従い、たとえそれらがERRP施行の1か月、或いは1週間以内に満了するものであったとしても、全ての期日を迎える契約に対して2通のリマインダを送付する必要があります。詳細については、以下の表を参照してください。

登録の期日: 1通目のERRP期日前通知が必要(期日の1か月前) 2通目のERRP期日前通知が必要(期日の1週間前) 少なくとも2通の期日前通知が必要(ERRPによる通知を含む)
2013年9月7日より前 x
2013年9月7日から9月30日 x x
10月1日以降 x x x
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."