Skip to main content
Resources

拡張レジストリセキュリティリクエストプロセス

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

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

拡張レジストリセキュリティリクエスト(ERSR)は、ICANNにTLDおよび/またはDNSに対する現在または緊急のセキュリティインシデント(以下、「インシデント」)を通知し、インシデントの緩和または解消に対応する可能性のある措置あるいは実行済み措置について契約上免責を要請するgTLDレジストリ向けプロセスを提供するために開発されました。契約上の免責は、インシデントへの対応に必要な期間中は、レジストリ契約の特定の条項に対する遵守を免除するものです。ERSRは、関連する当事者(たとえば、ICANN、その他の影響を受けるプロバイダーなど)への適切な情報提供を継続しながら、インシデントが発生した場合にもセキュリティ対策の運用を維持できるように設計されています。

インシデントには、次の 1 つまたは複数が想定されます。

  • TLDまたはDNSの体系的なセキュリティ、安定性および耐障害性を脅かす大規模で重大なDNSに関する悪意のある行為。
  • レジストリデータの無許可の開示、変換、挿入、または破壊、または該当するすべての標準規格に基づき運営されているシステムによるインターネット上の、情報やリソースへの不正なアクセスやそれらの開示を意味します。
  • ICANNのgTLDレジストリ継続計画[PDF、96K]で定義されているgTLDレジストリの1つ以上の重要な機能の一時的または長期的な障害を引き起こす可能性のある事象。

ERSRはインシデント専用のプロセスです。つまり、レジストリによる迅速な対応とICANNからの3営業日以内の迅速な応答が必要です。このプロセスは、レジストリサービス評価方針(RSEP)を通じて実施される必要がある要求を置き換えるものではありません。

いくつかの極めて特異な状況では、インシデントを防止したり対処したりするためにレジストリは迅速に対応する必要があります。このようなインシデントが発生した場合、ICANNが必要に応じて遡及的なウェイバーに対応できるように、レジストリは可能な限り速やかにERSRを提出する必要があります。

レジストリは、命名サービスポータルからケースを送信して、ERSRを送信できます。ERSRを送信するときには、レジストリオペレータは、対策がすでに講じられているかどうかを示す必要があります。提出された要求は次のように処理されます。

  • ERSRは、ICANNセキュリティレスポンスチームに転送されます。セキュリティレスポンスチームは、SSR、GDDオペレーション、GDDレジストリサービス、GDD技術サービス、法務およびコンプライアンスの部門のスタッフから構成されます。
  • セキュリティレスポンスチームの指定されたメンバーは、ケースバイケースで、1営業日以内にレジストリに連絡してインシデントを確認する責任を負うものとします。
  • セキュリティレスポンスチームは、必要に応じて追加情報を要求してERSRを確認および検証することがありますので、ERSRを要求した側にそのような情報の提供を迅速に求める場合があります。
  • セキュリティレスポンスチームは、リクエストを受信して​​から2営業日以内に、レスポンスを確認し決定するために必要な追加情報を要求するかを議論します。
  • ICANNは、要求した側または指定代理人にERSRを受領してから3営業日以内に、口頭および書面で応答します。
  • セキュリティレスポンスチームの指定された担当者は、インシデントの発生期間中、レジストリの主要な担当者との連絡を維持します。
  • レジストリがインシデントに応答した後でリクエストが受信された場合、ICANNは必要に応じて10営業日以内に対応し、リクエストに対して遡及的なウェイバーを書面にて提供するよう努めます。
  • セキュリティレスポンスチームはERSRに対応した後、影響を受けるレジストリと協力して、事後レポート(AAR)を作成し、コミュニティが参照できるようにします。AARが公開される予定である場合、ICANNと影響を受けるレジストリは、機密情報および専有情報が確実に保護されるように、ERSRリクエストのどのセクションとAARを編集すべきかを共同で検討します。ICANNとレジストリは、機密情報または専有情報であると合理的に判断した情報を編集する場合があります。
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."