Skip to main content
Resources

实质性转包安排 (MSA) 变更

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

概述

本网页为注册管理运营机构提供向 ICANN 组织申请批准实质性转包安排 (MSA) 变更的相关指导。

《注册管理机构协议》规范 10 第 6 节中定义的任何关键职能相关的所有转包安排均被视为"实质性转包安排 (MSA)"。运营一项或多项关键职能的转包商称为"后端注册管理运行机构"或"注册管理机构服务提供商 (RSP)"。

受 MSA 变更流程影响的关键职能包括:

  • DNS 解析
  • DNSSEC 正确签名的区域(如果注册管理机构提供了 DNSSEC)
  • 共享注册系统 (SRS),通常借由可扩展供应协议 (EPP) 的方式提供
  • 注册数据目录服务 (RDDS),例如,通过端口 43 和基于网络的服务提供的注册数据访问协议 (RDAP) 和 WHOIS。

ICANN 组织通过 MSA 变更流程对 RSP 进行测试和评估,以确保其有能力以稳定和安全的方式运营顶级域 (TLD)。ICANN 组织还要求注册管理运行机构提交一份移交计划,说明如何以稳定和安全的方式,协调和完成相关服务从一个 RSP 移交至另一个 RSP。

以下是 MSA 流程的一般时间表。单击此处可了解更详细的工作流程。

实质性转包安排 (MSA) 变更

提交前:考虑事项和准备工作

以下步骤重点介绍了注册管理机构在域名服务门户 (NSp) 中提交 MSA 变更请求之前应考虑的事项和应做的准备工作。

第 1 步:考虑相关事务。变更 RSP 可能会导致其他相应变更。例如,考虑:

  • 由于 RSP 变更,您是否会对《注册管理机构协议》(RA) 附录 A 中的注册管理机构服务进行任何修改?
  • 除了 MSA 变更之外,您是否还会将 TLD 分配给另一个不同实体?

对注册管理机构服务的修改:如果您提议的 RSP 所提供的注册管理机构服务与您当前的 RSP 不同(例如,注册管理机构锁定、IDN 语言/文字),那么您需要在提交 MSA 变更请求之前,先提交注册管理机构服务评估政策 (RSEP) 请求来更新附录 A 中的相关内容。我们鼓励您通过电话会议来商讨适当的步骤。


分配 TLD:除了 MSA 变更之外,如果您还计划将 TLD RA 分配给另一个不同实体,则需要先完成其中一项事务,然后再着手启动另一项事务。我们强烈建议您通过电话会议来商讨可用选项,这样还可帮助您更好地了解相关事务的影响。有关分配 TLD 的更多信息,请参阅分配页面

第 2 步:了解时间表。给自己留出至少 7-12 周的时间来完成向 ICANN 组织提出 MSA 变更请求这项工作。在您的时间表中,应根据您的业务需求和要求来考虑 ICANN 组织在处理 MSA 变更方面的要求,包括测试。例如,考虑:

  • 您与当前 RSP 的协议是否即将终止?
  • 从您当前的 RSP 移交至新的 RSP 需要多长时间?

第 3 步:与客户经理组织一次电话磋商,以确保您了解相关流程。您的客户经理可以向您简要介绍流程所涉及的内容,通知您需要准备的文档和测试工作,并帮助确保您了解提出 MSA 变更请求所需的事项。做好提交请求的准备工作会让流程更加高效。

第 4 步:审核并准备所需的文件。提前做好计划,审核提供的材料,准备要提交的文件,并注意以下事项:

  • 查看注册管理机构系统测试页面和资源
  • 确定您提议的 RSP 是新的(未知)RSP 还是现有(已知)RSP。未知 RSP 是指当前对一个或多个新通用顶级域 (gTLD) 提供支持的提供商。
  • 对于未知 RSP,您必须提交对MSA 技术问题的答复。如果您希望移交至未知 RSP,则需要完成一些额外的审核、测试和步骤。有关这些额外要求的更多详细信息,请参阅 MSA 变更指南
  • 制定移交计划(请参阅移交计划指南)。
  • 了解与您请求的 MSA 变更类型(变更为未知 RSP 或变更为已知 RSP)相关的费用
  • 查看 MSA 变更工作流程

资源

要求一览表(按 MSA 变更类型)

要求 已知 RSP 未知* RSP

非正式提交

技术评估

(预计评估费用 14,300 美元)

移交计划审批

注册管理机构系统测试

模拟演练

正式提交/ICANN 审核

ICANN 作出决定

RSP 移交

*目前未对新通用顶级域提供支持

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