Skip to main content
Resources

2009 レジストラ認定契約に基づくレジストラントの権利と責任

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

2011 年 6 月 27 日

2009 レジストラ認定契約に基づくレジストラントの権利と責任

この文書は、情報提供だけを目的として複数の言語に翻訳されています。(英語の) 信頼できる原文は、以下から入手できます。 http://www.icann.org/en/registrars/registrant-rights-responsibilities-en.htm

背景:2009年RAAに追加された新しい規定のひとつは、ICANNに、登録機関と協議して、登録者の権利および責任を明記したウェブページを作成することを定めている。この公文書は、GNSO CouncilおよびAt-Large Advisory Committeeの共同ワーキンググループからの初回意見、そしてその後の登録機関との協議を基にして作成された。この文書には、2009年RAAを基準とする現時点での登録者の権利および責任の概要がわかりやすい言葉で説明してある。

概要

このドキュメントは、レジストラの Web サイト上での公開目的で、 レジストラ認定契約 (RAA) に定義されるレジストラントの権利と責任に関する条件を分かりやすい言葉で 説明します。ここで説明される条件の一部にはレジストラントについて特に言及していないものもありますが、これらの条件はレジストラとレジストラントの関係の理解の ために含められています。 ICANN コンセンサス ポリシーと仕様は RAA に含められてい るので、このドキュメントではこれらのポリシーと仕様で言及されるレジストラントの 権利や責任についてもまとめています。

このドキュメント内の条件のまとめは、 RAA で定義される条件や、仕様やポリシーに 含まれる条件を無効にしたり置き換えるものではありません。

序文

ドメイン名を登録するには、登録名保有者 ( レジストラントとも呼ばれる ) は ICANN 認定レジストラのサービスを使用する必要があります。 ICANN 認定レジストラになるには、レジストラは レジストラ認定契約 (RAA) と呼ばれる契約を ICANN と 締結する必要があります。 RAA ではレジストラントの様々な権利や責任が定義されています。また、レジストラントには、レジストラが従うことに同意した別途の ICANN ポリシーおよび仕様からの追加の権利や責任が発生します。

RAA および関連するポリシーのドキュメントでは、専門的な法的用語が多用されてい ます。レジストラントがドメイン名の登録に伴って発生する権利および責任をより良く理解するのをサポートするため、これらの権利や責任は単一のドキュメントにまとめられています。ここで提供する要約事項は、 RAA や関連するポリシーおよび仕様に記載される実際の条件を無効にしたり、置き換えるものではありません。

RAA 参考条件

RAA は ICANN とレジストラの間の契約であるため、登録名保有者を含めた他の何者も RAA の違反に関する申し立てで ICANN またはレジストラを訴えることはできません。

レジストラは、関連する TLD に他のレジストラより優れたアクセスを提供することを レジストラントに宣伝することはできません。

レジストラの責任の一部は、登録料の支払い、レジストラへの必須データ ポイントの 提出、正確なデータの提出、および適切なタイミングによる必須データの更新などの 特定の責任を登録名保有者が果たしているかどうかに依存しています。レジストラはまた 、登録期間の終了、登録名保有者の個人データの使用、プライバシーまたはプロキシ登録サービスを通して登録されたドメイン名に対するデータのエスクロー、登録名の復旧にかかる料金の公開などの項目に関する通知を登録名保有者へを発行する必要があります。

レジストラからレジストリ オペレータへのデータの提出

該当する各 TLD について、レジストラは TLD 内の各登録名に関連する 特定の データ ポイントを提出する必要があります。

  • 登録されている登録名の名前 (3.2.1.1) 。
  • 登録名のプライマリ ネームサーバーとセカンダリ ネームサーバーの IP アドレス (3.2.1.2) 。
  • それらのネームサーバーの対応する名前 (3.2.1.3) 。
  • レジストリ システムで自動的に生成されない場合、レジストラの識別情報 (3.2.1.4) 。
  • レジストリ システムで自動的に生成されない場合、登録の有効期間終了日 (3.2.1.5) 。および
  • レジストリ オペレータが提出を要請するその他のデータ (3.2.1.6) 。

通常、登録名保有者はネームサーバーに関する情報をレジストラに提出する必要があり (3.2.1.2 – 3) 、セクション 3.2.1.6 で要求される追加のデータも必要になる場合があります。登録名保有者がこれらのデータ ポイントの更新を提出する場合、レジストラは 5 日以内にこの更新をレジストリ オペレータに提出する必要があります。

Whois データ

レジストラは双方向の Web ページとポート 43 Whois サービスを一般公開し、ユーザーが 無料でクエリを発行可能にする必要があります。 RAA には、クエリの応答として提供する 必要のある特定のデータ ポイントが定義されています。

  • 登録名 (3.3.1.1) 。
  • 登録名のプライマリ ネームサーバーとセカンダリ ネームサーバーの名前 (3.3.1.2) 。
  • レジストラの識別情報 ( レジストラの Web サイトから提供されます ) (3.3.1.3) 。
  • 登録の本来の作成日 (3.3.1.4) 。
  • 登録の有効期間終了日 (3.3.1.5) 。
  • 登録名保有者の名前と郵便宛先 (3.3.1.6) 。
  • 登録名の技術担当者の名前、郵便宛先、電子メール アドレス、電話番号、および(該当する場合)ファックス番号 (3.3.1.7) 。および
  • 登録名の管理担当者の名前、郵便宛先、電子メール アドレス、電話番号、および(該当する場合)ファックス番号 (3.3.1.8) 。

これらのデータ ポイントは一般的に Whois データと呼ばれています。以下で説明するように、登録名保有者は、登録名の Whois データへの更新を適切なタイミングでレジストラに提出する必要があります。更新を受け取ったら、レジストラは Whois データを速やかに更新 する必要があります。レジストラは公開クエリ機能の管理を外注することができます。

RAA ではレジストラが第三者に Whois データへのバルク アクセスを提供することを許可 しています。公開クエリ機能を通して Whois データへのバルク アクセスまたはアクセスを 提供する場合、レジストラは大容量のクエリに対して アクセス制限 を課し、また RAA で規定されるように、マーケティング活動や勧誘書送付を含む Whois データの使用にも 制限を課す必要があります。公開クエリ機能を外部業者に委託する場合、レジストラはポート 43 サービスを提供する外注業者が Who is データへのアクセスおよびデータの 使用に関して同様の制限を課すよう要求する必要ががあります。

登録名保有者との通信

レジストラは、レジストリ オペレータに提出する情報の記録に加えて、登録名保有者との すべての通信の記録を管理する必要があります

登録名保有者データのエスクロー

レジストラは、レジストラがレジストリ オペレータに提出するすべてのデータに加え、レジストラの認定を通して登録されたすべての登録名のすべての Whois データの データベース を保持 する必要があります。加えて、レジストラはデータベースに、各登録名の 請求連絡先の名前、(該当する場合)郵便宛先、電子メール アドレス、電話番号、および ファックス番号を含める必要があります。

場合によっては、レジストラントはレジストラが Whois クエリで公開する個人情報の量を制限することを選択できます。これは、名前をプライバシー サービスを通して登録することで実行できます ( レジストラントが個人識別情報を隠し、多くの場合にプライバシー サービスの情報で置き換えることを可能にする ) 。顧客は名前をプロキシ サービスを通して登録することも選択できます。この場合、プロキシ サービスが登録名保有者となり、プロキシ サービスがドメイン名の使用のライセンス許可を顧客に与えます。この場合、登録名保有者として、プロキシ サービスが必須データ ポイントのすべてまたはほとんどについての情報を保持しています。

登録名がプライバシーまたはプロキシ登録サービスを通して登録された場合、データベース内の情報に影響があるため、レジストラは 以下の 2 つのいずれかを実行する必要があります 。レジストラは、 (1) プライバシーまたはプロキシ登録が使用された場合でも、 各登録名に関連する顧客が提供した名前、郵便宛先、電子メール アドレス、電話番号をデータベース内に含めるか、 (2) 顧客がプライバシーまたはプロキシ登録サービスの使用を選択した場合、顧客のデータはエスクローされないことを示す通知を表示する必要があります。顧客のデータがエスクローされない場合、プライバシーまたはプロキシ登録サービスに関連する連絡先のみがエスクローされます。顧客のデータがエスクローされず、プロキシまたはプライバシー サービスの情報のみがデータベースで保管される場合、 レジストラまたはレジストリに障害が発生すると、通知はデータベース内の連絡先に のみ送信されます。

レジストラとレジストラント間の商取引

RAA は 登録名保有者との取引 も含めたレジストラの商取引に関して多くの要求を課しています。

レジストラは、登録料の妥当な支払い確認を登録名保有者から受け取るまで、登録名を アクティブにすることはできません

RAA は、レジストラが現在の登録期間終了時に登録をキャンセルした場合も含め、登録名保有者が登録更新に同意しなかった場合にレジストラが 登録期間の終了時 に取るアクションを規定しています。登録名保持者が更新に同意しなかった場合、レジストラは登 録期間の終了から 45 日以内に必ず登録名をレジストリ データベースから削除する必要があります 。

登録をキャンセルするレジストラのこの権利と、ドメイン名削除の義務は絶対的ではあ りません。 RAA の セクション 3.7.5.1 は、「酌量すべき事情」の可能性を規定しています。 この事情が存在する場合、レジストラは登録名保有者の同意なしにドメイン名を更新 することができます。これらの事情には、登録名が UDRP アクション、裁判所の命令、 破産手続き、請求に関する紛争の対象となっている場合などが含まれます。レジストラは、登録名保有者の同意なしに登録を更新した理由の記録を保持しておく必要があります。

レジストラは、各新規レジストラントに レジストラの削除および自動更新ポリシーに 関する通知 を用意する必要があります。登録契約期間中にレジストラの削除ポリシーが変更された場合、レジストラはこれらの変更についてレジストラントに通知する努力を払う必要があります。削除および自動更新ポリシーの詳細は、レジストラがドメイン名 登録および更新用に運営する Web サイト上に 表示する必要があります 。また、レジストラ は請戻猶予期間 ( 名前がレジストリで「 Pending Delete 」になっている 30 日の期間 ) 中に ドメイン名の復旧にかかるすべての料金をこれらのサイト上に提示する 必要があります。1

登録の削除または期限切れ時に登録名が UDRP 紛争 の対象になっている場合、 UDRP 苦情申立者はドメイン名を更新 ( 削除された場合は復旧 ) する権利があります。苦情申立者が 名前を更新または復旧した場合、レジストラは名前を HOLD または LOCK ステータス2 にし、 Whois 情報を変更して名前が紛争の対象になっていることを示す必要があります。 RAA の セクション 3.7.5.7 は、 UDRP 紛争が決定事項なしに終了した場合、または UDRP 紛争が元のドメイン名のレジストラントに有利な形で解決した場合、元のドメイン名のレジストラントに名前を復旧または更新する権利を与えています。

レジストラ - 登録名保有者間契約

レジストラは、すべての登録名保有者と 電子形式または紙形式の登録契約を締結する 必要があります 。 RAA によると、レジストラ - 登録名保有者間契約には、 (RAA のセクション 3.7.7.1 – 12 で規定されるとおり ) 最低限以下の項目が含まれる必要があります。

  • 登録名保有者は「正確で信頼できる連絡先」を提供する必要があります。また、登録期間中に「速やかに修正および変更を加える」必要があります。必要事項の詳細はセクション 3.7.7.1 に規定されています。「登録名保有 者がいる場合は氏名、郵便宛先、電子メール アドレス、電話番号、および ファックス番号、登録名保有者が組織、協会、または企業の場合は連絡目 的に指名された担当者の名前およびサブセクション 3.3.1.2 、 3.3.1.7 、および 3.3.1.8 に記載されるデータ要素です。」
  • 登録名保有者が不正確で信頼できない情報を故意に提供した場合、情報の速やかな更新を故意に怠った場合、または連絡先詳細の正確さに関するレジストラの問い合わせに 15 日以上応答しない場合には、登録名保有者による契約の実質的な違反となり、登録をキャンセルする根拠になります。
  • 登録名保有者として表示される者は、完全な連絡先情報を提供する必要があり、登録名保有者として記録されます。場合によっては登録名保持者がドメイン名を登録し、他のユーザーにドメイン名を使用する許可を与えることも可能です (Web サイトデザイナーがドメイン名を顧客に代わって登録する場合など ) 。この状況において、名前の実際の使用者がレジストラ - 登録名保有者間契約を締結しなかった場合 (RAA では「第三者」と定義 ) 、第三者によるドメイン名誤用の責任は登録名保有者に問われる場合があります。これは、登録名保有者が第三者のドメイン名使用から「起訴できる損害の妥当な証拠」を受ける場合に発生します。この場合、登録名保有者は、ユーザーの識別情報および連絡先情報を提示しない限り、「登録名の不正な使用が原因となる損害の責任を負います」。
  • レジストラは登録名保有者が提供するデータをどのように使用するか、また登録名保有者のデータを誰が受け取るかに関する通知を提示する 必要があります。レジストラはまた、登録名保有者がデータにアクセスおよびデータを更新する方法についての通知も提示する必要があります。加えて、レジストラは登録名保有者がどのデータ ポイントをレジストラに提出する必要があるか、またどの情報を任意提出とするかを識別する必要があります。登録名保有者は、これらのデータ処理条件のすべてに同意する必要があります。
  • 登録名保有者が、レジストラ - 登録名保有者間契約を締結しなかった者 ( 前述の「第三者」 ) の代わりにレジストラに個人情報を提出する場合、登録名保有者は (1) これらの第三者である個人にレジストラが提供するのと同じデータ処理通知を渡したこと、また (2) レジストラのデータ処理条件に関して第三者から同様の同意を受け取ったことを確認する必要があります。
  • レジストラは、前述のデータ処理通知内に記載される登録名保有者のデータのみ処理できます。
  • レジストラは、妥当な事前措置を講じて、登録名保有者のデータの「紛失、誤用、不正なアクセスまたは開示、変更、破棄」を防止することに同意 する必要があります。
  • 登録名保有者は以下について表明する必要があります。「登録名保有者は、登録名保有者が知り得る限り、登録名の登録も登録名の直接または間接的な 使用においても第三者の法的権利を侵害していないことを表明します。」このことは、登録名保有者はドメイン名が他者の法的権利を侵害するような形で登録されていないことをレジストラに対して表明する必要があることを示 しています。この「侵害」の例には、登録名保有者ではない他者の商標や 著作権を侵害するドメイン名の登録などが考えられます。3
  • 登録名の使用に関する紛争が発生した場合、登録名保有者は少なくとも 以下の 2 つの場所のいずれかの管轄の裁判所に合意する必要があります。レジストラの所在位置 ( 通常 Web サイトまたはレジストラ - 登録名保有者間契約に記載 ) または「登録名保有者の法定住所」。「法定住所」とは法的専門用語ですが、通常登録名保有者が必須の個人情報内でレジストラに提示する所在地です。管轄裁判所に合意するとは、登録名保有者がこれらの所在地の裁判所がこれらの種類の訴訟に関して決定を下す力を持つことに合意することを意味しています。4
  • 登録名保持者は、セクション 3.7.7.11 で定義する理由に基づいて登録が 「保留、キャンセル、または移管」の対象となることに同意する必要があります。これらの理由には以下が含まれます。 ICANN が仕様を採択するか、ポリシーが必要とする場合、またはレジストラやレジストリ手順で「レジストラまたはレジストリ オペレータによる名前の登録の間違いを訂正するか、登録名に関する紛争の解決を図る」場合。例えば、 UDRP はドメイン名紛争をヒアリングする管理パネルがドメイン名登録の保留、移管またはキャンセルを命じることができ、登録名保有者はこの可能性に同意する必要があることを指定する ICANN 採択のポリシーです。
  • 登録名保有者は、「登録名保有者のドメイン名登録から生じたりドメイン名登録に関連するすべての請求、損害、責任、経費、および費用(妥当な訴訟の費用と経費を含みます)に対し、レジストリ オペレータとその役員、幹部、従業員、および代理人を防衛し補償します。」最も単純な形式では、登録名保有者のドメイン名登録を理由としてその登録名のレジストリ オペレータ ( またはその従業員など ) が告訴された場合、登録名保有者がレジストリ オペレータに訴訟に関するすべての費用と、裁定された評決および 債務に関連する費用を支払うことを意味しています。この「補償」は訴訟のみに制限されるものではありません。

連絡先情報の確認

以下に詳細を示すように、レジストラに適用される、作成される可能性のある仕様やポリシーがあります。仕様やポリシーの一部は、ドメインが最初に登録される時に登録名保有者が提供する連絡先情報を確認するレジストラの義務 について、また 連絡先情報の定期的な再確認の要件 について扱っています。

レジストラはまた、任意の人物がレジストラに登録名の連絡先情報が不正確であることを通知した場合に、連絡先情報を確認するために「 現実的な手段 」を取ることが求められています。レジストラには、誰から通知されない場合にも、自身が認識するようになった連絡先情報の誤りを修正するために行動する義務があります。

レジストラはまた、正しい電子メールまたは郵便宛先を含めた、自身に関する 適切な 連絡先情報を維持 する必要があります。この連絡先情報は、レジストラの Web サイトで公開する必要があります。

再販者との契約

RAA は、 第三者の再販者と連携するレジストラに対して義務を課しています 。この再販者とは、レジストラがレジストラ サービスの提供者として契約を結ぶ人物または実体 です。 RAA では現在、レジストラがレジストラ - 再販者間契約に以下を含む特定の項目を含めることが求められています。再販者が、 ICANN によって認定を受けていると表現することの禁止、すべての再販者登録契約に、レジストラがレジストラ - 登録名保有者間契約内に含める必要のあるすべての条項を含めることの要求、レジストラが公開する 義務のあるすべてのリンクをすべての ICANN Web サイトに公開することの要求、そしてスポンサーとなるレジストラの識別。再販者はまた、顧客が再販者のプライバシーまたはプロキシ登録サービスをドメイン名登録に使用している場合、以下の 3 つのうちのいずれかを確実に実行する必要があります。 (1) 顧客の識別および連絡先情報をレジストラに委託する、 (2) 識別および連絡先情報をエスクローへ委託する、または (3) 連絡先情報がエスクローされないことの通知を顧客に対して発行する。

RAA はまた、必須条項に違反する再販者に対してレジストラが順守および履行に関するアクションを取る必要があることを定義しています。

その他のポリシー / 仕様

復旧名の正確性に関するポリシー (http://www.icann.org/ja/registrars/rnap-ja.htm) では、誤った 連絡先データまたはレジストラの問い合わせの非応答を原因として削除された名前を レジストラが ( 請戻猶予期間から ) 復旧した場合、この名前はレジストラントが更新した正確な Whois 情報を提示するまで、 Registrar Hold ステータスに置かれる必要があることを定義しています。

登録名保有者が自身の認識する範囲でドメイン名の登録または使用は他者の法的権利を侵害しないことを表明する必要があることを規定する RAA 要件に加えて、統一ドメイン名紛争解決ポリシー (UDRP) は同様の事項を表明する必要、またドメイン名が違法な目的で登録されていないこと、そして適用される法に違反される形で使用されないことを 表明する必要を規定しています。

UDRP はまた、登録名保有者が UDRP に基づいて紛争を解決するために義務的紛争処理 手続を提出する必要を定義しています。これらの義務的紛争処理手続は、 UDRP で説明されるように、 ICANN 認定の UDRP 紛争解決プロバイダ (http://www.icann.org/ja/dndr/udrp/ approved-providers-ja.htm に表示 ) で起訴される紛争で、 UDRP 紛争処理手続きの統一規則 (http://www.icann.org/ja/dndr/udrp/uniform-rules-ja.htm で 定義 ) に従っています。義務的紛争処理手続の提出義務は、登録名保有者が同様の行為に 関して法的手段を取ることができないことは意味していません。 RAA で定義される管轄 要件と同様、義務的紛争処理手続を提出する要件は、登録名保有者が UDRP で適切に 提訴されるべき紛争をヒアリングする UDRP プロバイダの能力に関して訴訟を起こすことはできないことを意味します。

Policy on Transfers of Registrations between Registrars ( レジストラ間の登録の移管に関するポリシー) では、レジストラ間でドメイン名登録を移管する権利を登録名保有者に与え ています。移管ポリシーは、レジストラの移管要請への応答に制限時間を課しています。 移管を実行する権利は絶対的ではありません。 ICANN およびレジストリ ポリシーの中には 移管権利に以下のような制限を課すものがあります。ドメイン名が移管されるタイミング ( 作成された日付や以前の移管から判断 ) 、およびレジストラ レビューに必要な承認および 文書化を提供する登録名保有者に課される制限。記録のレジストラは、以下の場合にのみ移管を拒否できます。

  • 不正行為の証拠がある
  • UDRP アクション
  • 管轄裁判所からの命令
  • 登録名保有者または管理担当者の識別情報に関して正当な紛争がある
  • ドメイン名の有効期限が切れている場合は以前の登録期間の、切れていない 場合は以前のまたは現在の登録期間に対する不支払い ( クレジットカードのチャージバックを含む ) 。このような場合はすべて、移管の拒否の前に、ドメイン名は記録のレジストラによって「 Registrar Hold 」ステータスに 置かれる必要があります。
  • 移管担当者による、移管に対する書面を通した明白な異議。 ( 例 : 電子メール、ファックス、紙の文書、または移管担当者が明示的および自発的にオプトイン 手段を通して異議を唱えた他のプロセス )
  • レジストラが Lock ステータスを解除するための適切にアクセスが可能で 実際的な方法を登録名保有者に対して提供することを前提に、ドメイン 名がすでに Lock ステータスにあった。
  • ドメイン名の Whois 記録に示される作成日から 60 日以内に移管が要請 された。
  • ドメイン名が移管日から 60 日 ( これより短い期間を設定可能 ) 以内である ( 両方のレジストラが同意するか、紛争解決プロセスから指示を受けた上で、元のレジストラに再度移管される場合を除く ) 。

1 一般的な gTLD 登録名の有効期間を視覚的に表示したものを http://www.icann.org/ja/registrars/gtld-lifecycle-ja.htm から参照することができます。この図は、ドメイン名の期限切れ後のステータスの詳細情報を参照する場合 に便利です。

2 ドメイン名のステータスには、コミュニティ ベースのインターネット ドラフト「 Request for Comments ( コメントのリクエスト ) 」で定義される正式な技術名があります。ここで要求されるステータスはレジストラにより設定されます。登録がこれらのステータスのいずれかにある場合、ドメインを削除することはできず、登録を変更することもできません。レジストラは修正をするためにはステータスを変更する必要があります。

3 他者の「法的権利の侵害」には他のさまざまな可能性が考えられます。ドメイン名の登録または使用が他者の権利を侵害するおそれがある場合、登録名保有者になる前に外部からの独立したアドバイスを受けることをお勧めします。

4 登録名の使用に関する紛争の決定を下すことができる管轄は他にもありますが、これらの管轄は RAA では指定されていません。

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."