Skip to main content
Resources

gTLD契約遵守プログラムについて

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

以下に示すgTLD契約遵守プログラム [PDF, 974 KB] の概要は、指針としての目的のみにより提供されています。契約当事者は、ICANNとの契約および適用されるICANNポリシーのすべての必要条件を継続的に確認して準拠する必要があります。

gTLD契約遵守プログラムでは、gTLDレジストリ契約の契約条項を一般的な契約遵守領域に分割しています。これらの領域の遵守は、内部監視、苦情処理、および外部リソース(業界ニュースなど)の監視を通じて履行されます。新サービスが導入されたり、プロトコルやポリシーが変更されたりした場合は、その領域に契約遵守の監視事項が追加されることがあります。

gTLDレジストリ契約は基本的構造を共通しますが、具体的な条件には多様性があります。以下に、gTLD契約遵守領域の一部、および新gTLDレジストリ契約の関連条項を示します。新gTLDレジストリ契約フォームを作成していないレジストリは、異なる条件を使用していることがあります。詳細は、各gTLDのレジストリ契約をご覧ください。

ICANNは、契約遵守についてccTLDオペレータに対処する契約上の権限はありません。

契約遵守領域

  1. 機能上および性能上の仕様

    機能上の仕様は、レジストリの技術システム(DNS、EPP、RDDSなど)の仕組みを指定するものです。性能上の仕様は、可用性、中断、処理時間、および更新頻度について標準を設定します。これらの領域における契約遵守を判断するため、ICANNは内部の技術的監視(利用可能な場合)を実施します。さらに、報告月の内部の技術的監視から得られた実際の性能結果をサービス レベル契約の条件に比較するため、レジストリ オペレータから提供される月次レジストリ レポートが使用されます。

    関連条項には、新gTLDレジストリ契約の仕様6および10が含まれます。レジストリ オペレータのサービス レベル契約の条件に関する苦情は、レジストリに関する苦情申し立てフォーム(https://www.icann.org/resources/pages/performance-2013-06-28-en)を使用して提出できます。

  2. 登録データ ディレクトリ サービス(Whois)およびWhoisへのバルクアクセス

    新gTLDレジストリ契約のフォームを作成したレジストリは、ポート43を介する公開のWhoisサービス、および必要なデータ要素を指定フォーマットで含むWebディレクトリ サービスを提供する必要があります。また、バルク登録(Whois)データへのアクセスを毎週ICANNに提供する必要があります。ICANNは、レジストリがWhoisデータへの適切なアクセスを提供し、条件に沿う方法でWhoisデータを示し、更新頻度の条件を満たし、バルク アクセスの条項に従っているかどうかを検査します。

    関連条項には、新gTLDレジストリ契約の仕様4および10、およびICANNの勧告「Clarifications to the Registry Agreement and the 2013 Registrar Accreditation Agreement (RAA) regarding applicable Registration Data Directory Service (Whois) Specifications(レジストリ契約および2013年レジストラ認定契約(RAA)に適用される登録データ ディレクトリ サービス(Whois)の仕様に関する説明)」が含まれます。

  3. データ エスクロー

    すべてのレジストリは、データ エスクロー サービスの条項でICANNが承認するデータ エスクロー エージェント(DEA)を選択する必要があります。コンプライアンスチームは、DEAの委託が有効であるかどうか、およびレジストリがエスクロー通知をICANNに提出したかどうかを検査します。

    関連条項には、新gTLDレジストリ契約の仕様2が含まれます。

  4. レジストラ データの使用

    新gTLDレジストリ契約のフォームを作成したレジストリは、レジストラから収集した登録データを保護するため、合理的な手続きをとる必要があります。レジストリは、情報の用途をレジストラに通知する必要があり、非公開の理由で情報を使用してはなりません。コンプライアンスチームは、私的データの取り扱い方法に関するレジストリからレジストラへの連絡を検査し、ICANNの苦情申し立てフォームにより提出された苦情を処理します。

    関連条項には、新gTLDレジストリ契約のセクション2.14ならびに2.18、および仕様9が含まれます。

  5. レジストリ サービスへの等しいアクセスおよび行動規範

    この領域には、新gTLDレジストリ契約のフォームを作成したレジストリが負う、すべてのレジストラに等しい無差別のアクセスを提供し、すべてのレジストラとの間で統一的な無差別の契約を使用する義務が含まれます。また、レジストリがレジストラ サービスまたはレジストラ再販業者サービスも提供する場合、レジストリは行動規範に基づく内部検査を実施し、その結果と署名入り遵守証明書をICANNに(例外なく)提供する必要があります。ICANNは、苦情処理および外部リソースによりこれらの条項を監視し、必要とされる年次証明書を検査します。

    関連条項には、新gTLDレジストリ契約のセクション2.9a、および仕様9ならびに13(該当する場合)が含まれます。行動規範の条件に関する苦情は、行動規範に関する苦情申し立てフォーム(https://www.icann.org/resources/pages/code-of-conduct-2014-01-29-en)を使用して提出できます。

  6. 登録の制限

    登録ポリシー、または(スポンサーされるgTLDについては)綱領の制限事項(付属書S)により、一部のgTLDは制限されています。たとえば、コミュニティgTLDは関係するコミュニティに関する登録の制限に従う必要があります。制限を受けるレジストリは紛争解決ポリシーにより、不適切な登録についての紛争を解決するための標準を提供します。

    ICANNはRRDRP(レジストリ制限事項に関する紛争解決手続き)により、新gTLDレジストリ契約のフォームを作成したレジストリが登録制限の義務に準拠していないことを申し立てる初回報告を提出できるようにしています(レジストリ契約の仕様12)。ICANNは、レジストリがレジストラントに対して適切な紛争解決メカニズムを提供することを保証します。

    関連条項には、新gTLDレジストリ契約のセクション2.19および仕様12が含まれます。仕様12に定められたレジストリ オペレータの登録制限に関する苦情は、RRDRPに関する苦情申し立てフォーム(https://www.icann.org/resources/pages/rrdrp-2013-10-31-en)を使用して提出できます。

  7. サンライズおよびクレーム サービス

    新gTLDレジストリ契約のフォームを作成したレジストリ、および契約レジストラは、Trademark Clearinghouse(TMCH)と連携してサンライズおよびクレーム サービスを提供する必要があります。これらのサービスは、TMCHに商標を記録した商標所有者向けの権利保護メカニズムです。商標所有者はサンライズ サービスにより、商標に対応するドメイン名が一般に利用可能になる前に、そのドメイン名を登録できます。クレーム サービス期間中に、TMCHに記録されている商標に一致するドメイン名を登録しようとする当事者に対して、レジストラは商標クレーム通知を提供する必要があります。通知を受けた当事者がそのドメイン名を登録する場合、TMCHはその登録について商標所有者に通知します。

    公開されているレジストリのサンライズ紛争解決ポリシー(SDRP)による解決策がすべて講じられた後は、ICANNがクレーム サービスの違反およびサンライズ サービスの違反に関する苦情を受け付けます。

    関連条項には、新gTLDレジストリ契約の仕様7、およびTrademark Clearinghouse(TMCH)権利保護メカニズムの要件が含まれます。SDRPによる解決策がすべて講じられた後の苦情は、サンライズ処理および手続き報告フォーム(https://www.icann.org/resources/pages/sdrp-2013-10-31-en)を使用して提出できます。また、レジストリ オペレータのクレーム サービス要件に関する苦情は、クレーム サービス フォーム(https://www.icann.org/resources/pages/claims-2014-01-29-en)を使用して提出できます。

  8. 予約名

    すべてのレジストリは、レジストリ契約に定められた名前を予約する必要があります。ICANNは準拠を判断するため、内部の技術監査を実施し、外部からの苦情に対応します。新gTLDレジストリ契約のフォームを作成したレジストリは、gTLDの運用または推進に必要な名前を最大100個(該当する場合はIDNバリアントを含む)有効にできます。レジストリ契約の他のすべての条件が満たされている限りにおいて、レジストリがgTLDで予約可能な名前の数は制限されません。

    関連条項には、新gTLDレジストリ契約の付属書6および仕様5が含まれます。レジストリ オペレータの予約名またはブロックされたSLDに関する苦情は、予約名およびブロックされたSLDに関する苦情申し立てフォーム(https://www.icann.org/resources/pages/reserved-2013-06-28-en)を使用して提出できます。

  9. 名前衝突

    各gTLDの委任日をもって(2014年8月18日00:00 UTC以降)、新gTLDレジストリ契約のフォームを作成したレジストリは、(1)ブロック対象のリストに含まれるセカンド レベル ドメイン(SLD)をブロック、またはそれらの名前を有効にする90日以上前に計画的中断(CI)またはワイルドカードによるSLDのCIを実施するか、あるいは(2)そのTLDの下の名前を有効にする90日以上前にワイルドカードによるCIを実施する必要があります。ICANNは、委任後にICANNに転送されるゾーン ファイルを主に使用して、CIの実施を監視して期間を記録します。CIの実施中、その他のレジストリの義務はそのまま保持されます(DNSSEC、whois.nic.tldでのRDDSサービスの提供など)。

    関連条項には、新gTLDレジストリ契約の仕様6、および名前衝突発生管理のフレームワークと関連文書が含まれます。

  10. ゾーン ファイルへの第三者アクセス

    すべてのレジストリは、ゾーン ファイルに対する第三者アクセスを提供する必要があります。レジストリのゾーン ファイル契約は、レジストリ契約またはスポンサーシップ契約に定められた形態をとる必要があります。また、CZDS(Centralized Zone Data Service)での契約の使用を含みます(該当する場合)。ICANNは、レジストリのゾーン ファイル契約を検査し、CZDSによりゾーン ファイル アクセスを行う第三者からの苦情を処理することにより、レジストリが契約を変更したり追加条件を課したりしていないかどうかをチェックします。

    関連条項には、CZDSの条項、および新gTLDレジストリ契約の仕様4が含まれます。レジストリ オペレータのゾーン ファイル アクセスの条項に関する苦情は、ゾーン ファイル アクセスに関する苦情申し立てフォーム(https://www.icann.org/resources/pages/zfa-2013-06-28-en)を使用して提出できます。

  11. 1連絡先データの悪用

    新gTLDレジストリ契約のフォームを作成したレジストリは、gTLDでの悪用や不正行為に関連する問い合わせに対応するための有効な電子メール アドレス、有効な郵便宛先、および一次連絡先をICANNに提供し、Webサイトで公開する必要があります。ICANNは、レジストリのWebサイトを検査して、必要な連絡先が公開されているかどうかを判断します。

    関連条項には、新gTLDレジストリ契約の仕様6が含まれます。レジストリ オペレータの連絡先データの悪用に関する苦情は、連絡先データの悪用に関する苦情申し立てフォーム(https://www.icann.org/resources/pages/abuse-contact-2014-01-29-en)を使用して提出できます。

  12. 公益のための誓約

    新gTLDレジストリ契約のフォームを作成したレジストリは、特定の必須および任意(ある場合)の公益のための誓約を実行する必要があります。必須条項として、レジストリ-レジストラ間契約(RRA)に特定の条項を含めること、および定期的な技術分析を実施することが含まれます。これらの義務は、公益のための誓約の紛争解決手続き(PICDRP)により強制できます。ICANNは、苦情処理と外部リソースにより、これらの条件に対する準拠を監視します。

    関連条項には、新gTLDレジストリ契約の仕様11およびPICDRPが含まれます。PICDRPに関する苦情は、PICDRPフォーム(https://www.icann.org/resources/pages/picdrp-2013-10-31-en)を使用して提出できます。

  13. 統一早期凍結(URS)システム

    ICANNのURS手続きは、ドメイン名の登録によって明確な侵害を受ける権利保有者をするための、低コストで迅速な手段です。ICANNは、URSプロバイダからのURSの苦情の処理中および処理後に、新gTLDレジストリ契約のフォームを作成したレジストリがURS手続きの要件に従うことを保証する役割を担います。

    関連条項には、レジストリおよびレジストラ向けのURS技術要件、URSの手続きおよびルール、および新gTLDレジストリ契約の仕様7が含まれます。URSの決定事項に対するレジストリ オペレータの不履行に関する苦情は、URSフォーム(https://www.icann.org/resources/pages/urs-2013-10-31-en)を使用して提出できます。

  14. ワイルドカードの禁止

    新gTLDレジストリ契約のフォームを作成したレジストリは、DNSワイルドカード リソース レコード、DNSリソース レコードの統合手法、およびDNSのすべてのレベルでの未登録のドメイン名や未提供の有効なNSレコードのリダイレクトを使用することを禁止されます。これらのドメイン名のクエリを実行する場合は、RFC 1035および関連するRFCの記載に従って、権限のあるネーム サーバーがRCODE 3の「Name Error」の応答(別名「NXDOMAIN」)を返す必要があります。ICANNは、内部の技術監視により準拠を判断します。この禁止事項は、名前衝突発生審査の条件によって一時的な免除が認められます。

    関連条項には、新gTLDレジストリ契約の仕様6が含まれます。レジストリ オペレータによるワイルドカードの使用禁止に関する苦情は、ワイルドカードの禁止(ドメインのリダイレクト)に関する苦情申し立てフォーム(https://www.icann.org/resources/pages/wildcard-prohibition-2014-01-29-en)を使用して提出できます。

  15. ICANNへの支払い

    すべてのレジストリは、ICANNに料金を支払う必要があります。レジストリの支払い記録データは、ICANNの経理部門から利用可能です。現在使用されている支払遅延の警告および通知は、経理スタッフとの調整により契約遵守プログラムに組み込まれています。

    関連条項には、新gTLDレジストリ契約の第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."