Skip to main content
Resources

注册管理机构过户流程

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

定义

在本文件中,下列术语的定义如下:

后端注册管理运行机构:与注册管理机构签订合同,运行 gTLD 注册管理机构的一项或多项关键职能的组织。

关键职能:对 gTLD 注册管理机构的运作非常关键的职能,包括:

  1. DNS 解析
  2. DNSSEC 正确签名的区域(如果是由注册管理机构提供 DNSSEC)
  3. 共享注册系统 (SRS),通常借由可扩展供应协议 (EPP) 的方式提供
  4. 注册数据目录服务 (RDDS),如:在端口 43 上以及通过网络服务提供的 WHOIS 服务。
  5. 注册管理机构数据托管

注册管理机构过户:与 ICANN 签署 gTLD 注册管理机构协议的签约方的变更。例如,导致需要进行注册管理机构过户的情况有:运营 gTLD 的组织更名、注册管理机构的出售或转让、当前注册管理机构违反注册管理机构协议等。

继任注册管理机构:注册管理机构过户后,与 ICANN 签署 gTLD 注册管理机构协议的新签约方。

注册管理机构过户流程

《义务确认书》第 9.2 节陈述,ICANN 需承担如下义务:

保护[域名系统的]安全、稳定与弹性。1

ICANN 章程确定了组织的核心价值。核心价值 #1 的内容如下:

保持并加强互联网的运行稳定性、可靠性、安全性和全球互用性。2

2006-2007 年 ICANN 运营规划(第 1.1.2 节)陈述 ICANN 将:

推出一个综合计划,在注册管理运行机构出现财务、技术或业务问题时须依照该计划处理,包括应完全符合数据托管要求并进行数据恢复3

相关流程创立于 06-07 财政年度,并经过不断更新,现称为"注册管理机构业务连续性框架" 4。注册管理机构业务连续性框架中描绘的"事故和事件管理流程"确定了对关键注册管理机构职能受到负面影响的情况加以处理的需求。

在追求核心价值 #1 的过程中,随着注册管理机构业务连续性框架的开发,ICANN 确定了一个流程定义需求。要求通过一些流程,以安全、稳定、可靠的方式进行 gTLD 过户,同时最大限度降低对注册人和 gTLD 用户的影响,并为过户所涉及到的各方提供开放透明的信息。

本文件中提出和描述了以下三个流程:

  1. 包含拟议继任者的注册管理机构过户流程
  2. 包含提案征询 (RFP) 的注册管理机构过户流程
  3. 域名注册管理后端应急运行机构临时过户流程

 

  1. 包含拟议继任者的注册管理机构过户流程

    当注册管理机构请求 ICANN 将其注册管理机构协议转让给一位潜在继任者时,将采用此流程(例如,注册管理机构被收购、组织更名、过户到注册管理机构服务连续性提供商)。如果发生以下情况,也将采用此流程:注册管理机构协议到期;具有管辖权的法律权威机构下达法院指令;或者,相关政府或公共权威机构取消对 gTLD(如为地理名称)注册管理运行机构的支持,并且拟推荐了一个继任注册管理机构。此流程的流程图见附件 2。

    评估拟议的继任者时,将始终进行适当级别的审查。例如,在更名的情况下,评估将重点确保没有机会劫持 TLD 这一点得到合法保证。

    在收到当前注册管理机构或相关政府或公共权威机构(针对地理 gTLD)发出的请求后,ICANN 将综合几方面来评估这一情况:收集到的事实材料、与当前注册管理机构和政府或公共权威机构(如适用)的对话,以及对注册管理机构协议的分析。评估将重点关注以下问题:

    • 提供后端注册管理机构职能的实体是否会发生变动?
    • 该 TLD 是否与某个社群相关,因而必须征求其意见?
    • 该 gTLD 是不是申请人指导手册定义下的地理名称?(或者,在申请时是否要求获得政府支持?)
    • 注册管理机构协议中是否包含任何可能会影响过户的约束条件?

    ICANN 还将对 gTLD、当前注册管理机构以及后端注册管理运行机构(如果这方面有变动)进行风险评估。评估既会结合三者进行整体评估,也会对各自的具体情况分别评估。例如,评估将核实该 gTLD 是否被金融机构大量使用,或大量用于电子商务,如果是,可能会采取更加严格的安全过户措施。

    完成这些评估后,拟议的继任注册管理机构将接受核查,以确保其获得必要的外部支持。如果 gTLD 是新 gTLD 申请人指导手册所定义的地理名称,那么 ICANN 将指示拟议的继任者取得相关政府或公共权威机构对潜在继任者的支持,并出具"支持/不反对"证明。如果注册管理机构协议规定过户时必须征求任何社群的意见,ICANN 将在这一阶段咨询他们。在这种情况下,只有相关社群对拟议继任者表示支持,过户流程才能继续。

    如果拟议继任者获得了必要的支持,或者不需要获得任何方面的支持,ICANN 将继续采用新 gTLD 申请人指导手册中规定的流程来评估申请人。ICANN 将以潜在注册管理机构评估矩阵(如附件 1 中所述)中设立的标准为基础,决定哪些评估必须进行,并收集信息和评估费用。这一费用将涵盖外部提供商开展评估的费用。

    ICANN 内部进行的评估将免费为申请人提供。

    评估的范围将因各个案例而异,具体取决于所需的适当审查级别。审查的三个级别如附件 1 所示。最高级别(即全面审查)的范围与新 gTLD 申请人的审核范围近似。评估将由参与评估新 gTLD 申请的一家公司进行。第二级别(即有限审查)的审核范围有所收窄。例如,技术和运营评估可能包括确保新组织与现有后端注册管理运行机构签署了相似的协议。第三级别(即最低审查)的审核范围非常窄,由 ICANN 内部进行。

    评估提供商将进行所需的评估,并向申请人和 ICANN 提供一份报告。如果申请人未通过评估,将有机会在评估失败后的三周内针对自身不足进行补救(扩展评估)。如果申请人未能把握住第二次机会通过评估,流程将结束并不予过户。同时将向申请人退款,退款金额等于收取的费用减去实际评估费用。

    如果潜在继任者通过评估,ICANN 将申请进行必要的审批,并在获得批准后与继任者签署注册管理机构协议。如果潜在继任者未获得批准,流程将结束且不予过户。

    一旦继任者获得批准,就将根据需要适当地对内和对外公布这一结果。如果过户不涉及后端注册管理运行机构的变动,继任者必须请求 IANA 对发起组织进行变更。

    如果提供后端注册管理运行机构服务的实体发生变动,继任者必须通过新 gTLD 的申请人指导手册中所定义的授权前测试阶段。不管后端提供商是注册管理运行机构还是注册管理运行机构的承包商,都必须通过该阶段。一旦测试成功完成,新注册管理运行机构必须继续请求 IANA 在 IANA 根区数据库中变更发起组织。IANA 步骤完成后,继任的注册管理运行机构将开展数据和服务迁移工作,并请求 IANA 对 DNS 和 RDDS (WHOIS) 记录进行更改。

    过户流程的最终步骤将根据需要适当地对内和对外公布,以便 ICANN 更新其关于 gTLD 注册管理机构的公开和内部信息。

  2. 包含 RFP的注册管理机构过户流程

    此流程将主要在 gTLD 注册管理机构违反注册管理机构协议(导致协议终止)且未确定继任注册管理机构时采用。如果发生以下情况,也将采用此流程:注册管理机构协议到期;具有管辖权的法律权威机构下达法院指令;或者,相关政府或公共权威机构取消对地理 gTLD 注册管理机构的支持,且没有推荐继任注册管理机构。此流程的流程图见附件 3。

    此流程与上述包含拟议继任者的注册管理机构过户流程类似,只是多了一个提案征询 (RFP) 子流程。RFP 的目的是确定潜在继任注册管理机构,并征集其申请。

    RFP 流程将在 gTLD 风险评估完成后启动,因为风险评估可能会产生重要结果,需要在 RFP 中披露。RFP 将描述继任注册管理机构必须提供的服务。此外,评估服务的预期成本将包含在 RFP 中,并成为申请人提出的经济方案的最低可接受标准。

    如果注册管理机构运营的 gTLD 是申请人指导手册中所定义的地理名称,那么 ICANN 将就 RFP 征求相关政府或公共权威机构的意见。另外,如果注册管理机构协议包含规定,要求 ICANN 在过户前咨询指定社群对潜在继任者的意见,那么该咨询将在流程的此阶段进行。

    一旦 RFP 经过批准,将发布 45 天,申请人必须在发布期结束之前作出响应。

    提议向原注册管理机构付款金额最高的申请人将接受核查,查看是否获得必要的支持,还将接受如包含拟议继任者的注册管理机构过户流程中所述的评估。这一遴选机制不仅为原注册管理机构提供最大回报,而且最大限度地降低了非成功申请人的不必要开支,同时还确保了成功申请人条件合格。

    如果申请人取得了必要的支持(或者不需要获得任何方面的支持)并通过了评估,流程将如前述流程继续。如果申请人没有取得必要的支持或没有通过评估,将考虑提议金额第二高的申请人,并依此类推,直到出现一位成功获得支持并通过评估的申请人,或者直到没有其他提案为止。

    如果在 RFP 流程中没有收到提案,或者由于缺乏相应支持或无法通过评估而没有产生合格申请人,那么将启动 TLD 废止流程以便关闭该 gTLD。如果某个 RFP 流程因无法确定继任者而关闭,但之后又发现有力候选者,可以视当时的情况考虑该名候选人,且相关决定应符合公共利益。

    如果通过此流程确定了一家合格的继任注册管理机构,那么已向此申请人收取的所有资金减去评估费用和应付的未结款项后,所得的结余都将转交给处理该 gTLD 的注册管理运行机构。

  3. 域名注册管理后端应急运行机构临时过户流程

    此流程主要用于新 gTLD 且必须满足以下两个条件:(1) 注册管理机构违反其注册管理机构协议,以及 (2) 某个关键职能的执行情况低于注册管理机构协议中规定的紧急阈值,导致不可接受的风险情形(如下文所定义)。在这种情况下,运营可转至应急后端服务提供商处进行,直到注册管理运行机构可恢复正常运营。如果注册管理运行机构知道或预期自己无法充分提供关键职能,这一临时过户也可应它们的请求发起。

    监测关键职能(数据托管除外)紧急阈值的衡量结果将从 ICANN 所用的注册管理机构 SLA(服务水平协议)监控系统提取,如注册管理机构协议所述。

    另外需要指出的是,这一过户流程旨在作为一项保护注册人和 gTLD 用户的临时措施。关键职能的临时过户将一直有效,直到根本问题得到解决,或者 gTLD 通过上述其中一个注册管理机构过户流程过户给另一运营商。为使这一临时过户顺利进行,新 gTLD 的注册管理机构协议包括一个注册管理运行机构的预授权,允许在紧急情况下更改 IANA 数据库中的 DNS 和 RDDS (WHOIS) 记录。

    一旦注册管理运行机构准备好恢复运营并且修复了导致其违规的所有问题,就可以发起一个包含拟议继任者的注册管理机构过户流程,以便重新取得 gTLD 运营的控制权。在违规后的整改期结束之前,注册管理运行机构始终可以做出这一选择。在该流程中,注册管理运行机构的身份定位为拟议的继任者。

    ICANN 将维持与至少两个预选域名注册管理后端应急运行机构(以下简称"应急运行机构")的签约关系。应急运行机构 RFP 流程将每五年发起一次,以便续约和/或选定新的应急运行机构。应急运行机构将从多种多样的地理区域中选择,以便提升应急运行机构的整体可靠性;如果在某个地区发生灾难,影响到其中一个应急运行机构的运行能力,则另一应急运行机构仍可随时运行。应急运行机构的基本资格要求为:至少三年的 DNS 运营经验和至少一年的 RDSS(例如 WHOIS)和 EPP 服务运行经验。

    ICANN 将基于价值 — 即兼顾服务和价格的最高性价比 — 选择应急运行机构。各次调用应急运行机构服务所需的资金将从新 gTLD 注册管理运行机构各自的持续经营方案中提取(注册管理机构协议的规格 8 规定新 gTLD 注册管理运行机构必须提供该方案)。

    应急运行机构的申请人评估将采用与新 gTLD 相似的流程,包括将要在紧急情况下使用的基础架构的授权前测试阶段。评估期间,基础架构必须已为投入运行做好准备。ICANN 可能会不时测试应急运行机构接受和应对紧急过户的能力和准备程度。

    一旦 ICANN 选择了应急运行机构,将向所有注册服务机构提供一份简化的注册管理机构-注册服务机构协议,使应急运行机构能够在临时过户过程中履行 SRS 职能。鼓励注册服务机构在任何紧急状况发生之前使应急运行机构加入进来,以便它们在某一 gTLD 的紧急过户发生时可立即投入运行(例如,已有现成协议、已经分发 SRS 访问凭证、已完成对应急运行机构的运行测试等)。

    当紧急状况发生且需要应急运行机构服务时,ICANN 将寻求让一个应急运行机构加入。如果选定的提供商无法接手运行,或者如果发生利益冲突,ICANN 将让另一提供商参与进来。根据 RFP 普通规则,在发生注册管理机构过户的情况下,活跃的应急运行机构可以申请成为 gTLD 的选定继任注册管理机构或后端运行机构。为了拥有一个均衡的投标流程,活跃的应急运行机构将向 ICANN 提供要求包含在 RFP 中的 gTLD 运行信息。

    在以下情形下,当前的后端注册管理运行机构可能会作为应急运行机构:

    • 注册管理运行机构请求 ICANN 紧急过户到后端注册管理运行机构,并将其作为应急运行机构;
    • 当前的后端注册管理运行机构正按照注册管理机构协议中规定的服务水平条款运行关键职能;
    • 后端注册管理运行机构公司与注册管理运行机构没有关联或没有附属关系;以及
    • 后端注册管理运行机构接受在比应急运行机构同意的条款更优越的条款下或相同条款下运行 gTLD。

    届时 ICANN 可自行决定是否同意让后端注册管理运行机构履行 gTLD 注册管理机构的职能。在这种情况下,对作为应急运行机构的后端注册管理运行机构的付款将从持续经营方案的收益中支取。

    应急运行机构必须满足以下服务水平要求 (SLR) 才能拥有各项关键职能。

    关键职能 服务水平要求
    DNS/DNSSEC ICANN 发出请求后 4 小时
    RDDS 收到数据后 24 小时
    SRS (EPP)* 收到数据后 72 小时
    数据托管 SRS 运行开始后 24 小时

    *SRS 服务器准备好接受来自注册服务机构的请求。

    应急运行机构将至少维护一个所有 gTLD 的每日区域文件存档,以便让选定的应急运行机构能够在紧急情况下快速恢复 DNS 服务。对于其他关键职能,将从当前注册管理机构和/或数据托管存储中获取数据。

    新 gTLD 的托管代理机构必须答应满足一个要求,即在紧急情况下,在请求发出后 24 小时内发布 gTLD 数据。

    在某个 gTLD 的关键职能紧急运行期间,应急运行机构将不会向注册服务机构收取 SRS 运行费用。

    通常情况下,应急运行机构不会受理注册服务机构提出的新建域、域续约、域转让或域名删除的操作。不过,在某些例外情况下,将受理上述操作,例如在注册管理机构加急安全请求流程下 5、UDRP 或任何其他 ICANN 域名争议解决流程下。对于注册服务机构赞助但无法再为其服务的域(注册服务机构丧失委任资格),ICANN 可以批准其批量迁移。应急运行机构将不会终止注册或使其自动续约;而且会在 RDDS(例如 WHOIS)输出当中的法律免责声明(如果有)上方包含一个简短说明(经 ICANN 批准),说明为什么过期日期已过,如注册管理机构协议规格 4 第 1.1 节所述。剩下的标准域名、联系人和主机(RFC 5730-34、5910)SRS 操作将得到允许。应急运行机构将与所有在 gTLD 中拥有赞助域的认证注册服务机构合作。

    继任注册管理机构自其运行开始的有效之日起即可收取续约或部分续约的费用。继任的注册管理机构将沿用失效注册管理机构的费用,并且必须遵照注册管理机构协议中规定的流程才能更改费用。

    应急流程的流程图见附件 4。

    从应急运行机构过户到原来的注册管理运行机构或新的注册管理运行机构时,应急运行机构将与新的运行机构合作协调,以便有条不紊地完成过户,将过户对注册人和 gTLD 用户的影响降至最低。

    紧急过户流程一旦/如果启动,ICANN 将对其进行监控和记录。从中将开发多个衡量指标,包括衡量注册管理运行机构和 EBERO 在五个关键职能方面的绩效。ICANN 将指出哪些方面表现良好,哪些方面可以改进,以便对这一流程提出修正。



1 ICANN. (2009, September 30). Affirmation of Commitments. Retrieved from http://www.icann.org/en/documents/affirmation-of-commitments-30sep09-en.htm

2 ICANN. (2009, September 30). ICANN bylaws. Retrieved from http://www.icann.org/en/general/bylaws.htm#I

3 ICANN. (2006, June 22). 2006-2007 ICANN Operating Plan. Retrieved from http://www.icann.org/announcements/operating-plan-22jun06.htm

4 ICANN. (2009). gTLD Registry Continuity. Retrieved from http://www.icann.org/en/registries/continuity/

5 http://icann.org/en/registries/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."