Skip to main content
Resources

注册管理运行机构安全响应弃权 (SRW) 请求

注:所有语种版本中,英文版为官方版本,其他语种版本仅供参考.

安全响应弃权 (SRW) 服务旨在允许 gTLD 注册管理机构针对为缓和或消除当前或即将发生的 gTLD 和/或 DNS 安全事件而可能采取或已经采取的行动申请合同豁免。合同豁免是指在必要时间段内,为了应对突发事件而免于遵守注册管理机构协议的特定条款。SRW 旨在允许在突发事件发生时,采取运营安全措施,并根据需要告知所有相关方(例如,ICANN 组织和其他受影响的提供商)。

2021 年 8 月,ICANN 组织扩展了注册管理机构安全请求快速处理流程 (ERSR) 服务,使注册服务机构能够提交弃权请求。因此,ERSR 服务更名为安全响应弃权 (SRW) 服务。

在发生以下一个或多个突发事件时,注册管理机构可以请求此服务:

  • 针对 DNS 的大规模和极其严重的恶意活动,可能威胁到一个 gTLD 或 DNS 的系统安全、稳定与弹性。
  • ICANN 注册管理机构移交流程中规定的可能导致某一 gTLD 注册管理机构的一项或多项关键职能暂时或长期失效的事件。
  • 在未经授权的情况下披露、更改、插入或损毁注册数据;或者通过按照所有适用标准运行的系统,在未经授权的情况下访问或披露互联网上的信息或资源。
  • 对注册管理机构拥有司法管辖权的执法机构颁布法院命令,要求注册管理机构因特定的安全威胁而采取行动。

SRW 服务专门针对要求注册管理机构立即采取行动的安全事件。本服务无意取代应通过注册管理机构服务评估政策 (RSEP) 提出的请求。

注册管理机构 SRW 流程

ICANN 组织承认,在某些情况下,由于特殊情形,注册管理机构可能需要立即采取行动来阻止或解决突发事件。在这类情况下,注册管理机构应尽快提交一份 SRW 请求,以便 ICANN 组织根据需要提供一份可追溯的弃权书。

SRW 流程分为三个阶段:

  1. 提交 SRW 请求:注册管理机构可以通过域名服务门户提交安全响应弃权案例来发起 SRW 请求。在提交的请求中,注册管理机构必须:

    1. 说明是否已采取相应行动。
    2. 说明行动是否紧急,以及在采取行动之前是否要求豁免。
    3. 提供突发事件的描述,以及有关注册管理机构计划如何响应突发事件或者已采取何种行动来响应突发事件的详细信息。
    4. 包括注册管理机构请求免于遵守的注册管理机构协议条款。
  2. 审核 SRW 请求:ICANN 组织将审核 SRW 请求并做出回复。如有必要,ICANN 组织可能会要求提供其他信息,以确保对 SRW 请求进行全面审核和考量。ICANN 组织会要求请求者尽快提供此类信息。ICANN 组织可能会根据具体情况联系注册管理机构和/或外部权威机构(例如执法机构、安全研究人员等)以确认突发事件。
  3. 裁定和回复:ICANN 组织将在收到所有必需信息后的 15 个日历日内以书面形式做出回复,包括 (i) 根据需要提供一份弃权书或可追溯的弃权书,(ii) 对现有弃权书进行更新,(iii) 裁定请求在现有豁免范围内,或者 (iv) 裁定不批准豁免,包括理由。如果在提交的请求中说明了行动紧急并且在采取行动之前要求豁免,注册管理机构将收到 ICANN 组织的快速回复。

ICANN 组织在对 SRW 请求做出回复后,将与受影响的注册管理机构合作,编写一份《行动后报告》,并面向公众发布该报告。若需要发布《行动后报告》,ICANN 组织和受影响的注册管理机构将联合审核 SRW 请求和《行动后报告》,确定哪些部分应当进行修订,以保护机密和专有信息。

安全响应弃权请求衡量标准

ICANN 组织在 ICANN 开放数据平台上发布了安全响应弃权 (SRW) 请求的衡量标准,包括之前称为"注册管理机构安全请求快速处理流程 (ERSR)"的有关衡量标准。请访问 ICANN 开放数据网页以了解 SRW 衡量指标。

存档

作为对此项服务进行改进的部分工作,本网页已于 2022 年 5 月更新。有关已存档的注册管理机构安全请求快速处理流程 (ERSR) 网页,请访问此处

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