Skip to main content
Resources

注册服务商间域名注册迁移政策

2008 年 11 月 7 日修订通过

2009 年 3 月 15 日生效

旧版本政策 ( 2004 年 7 月 12 日 )

 

  1. 持有人授权迁移

    1. 注册服务商要求

      只要迁入注册服务商的转让流程符合本政策的最低标准 , 且 ICANN 和 注册管理机构政策 未禁止 , 注册域名持有者就可以将其注册域名在注册服务商间 予以 迁移。注册服务商间的域名迁移流程必须简洁明了 , 以避免混淆。而且 , 注册服务商应尽力向注册域名持有者通报注册服务商所采用的具体迁移流程的发布文档 , 并提供访问权限。

      1.1 迁移权限

      只有在迁出注册服务商或适用注册服务商 ( 如可用 )的 公众可访问的 WHOIS 服务中所列出的管理联系人和注册域名持有者 , 才有权批准或否决迁入注册服务商提出的迁移请求。如有争议,注册域名持有人的权限大于管理联系人的权限。

      注册服务商可使用来自登记在册注册服务商或相关注册服务商 , 或来自共识性政策决定的其他数据来源的 Whois 数据 , 来确认迁移请求的真实性。

    2. 迁入注册服务商要求

      每当注册域名持有者请求将域名注册迁移给另外一个注册服务商时,迁入注册服务商应该:

      2.1 获得来自注册域名持有者或管理联系人 ( 以下统称 " 迁移联系人 " ) 的直接授权。因此,迁入注册服务商只有在收到迁移联系人的迁移确认之后才能开始迁移。

      2.1.1 必须通过有效的标准化授权书 (FOA) 进行授权。 ICANN 网站上提供两种不同类型的 FOA 。迁入注册服务商必须使用标记为 " 注册服务商迁移初步授权 " 的 FOA 向迁移联系人提出注册服务商迁移的授权请求。登记在册注册服务商可使用标记为 " 注册服务商迁移请求确认 " 的 FOA 向迁移联系人提出注册服务商迁移的确认请求。

      FOA 需用英文传达 , 并且使用英文对所有因迁移请求而引发的争议进行裁决。注册服务商可选择使用其他语言与迁移联系人进行沟通。但是 , 选择这一方式的注册服务商对 FOA 翻译之后的非英文版本的准确性和完整性负责。

      2.1.2 如果迁入注册服务商通过实体流程来获得授权 , 只需取得由迁移联系人签名的 FOA 文件的复印件即可 , 也可加上登记在册注册服务商的相关域名 Whois 输出的复印件。

      2.1.2.1 如果迁入注册服务商采用实体流程 , 则由其负责取得迁移联系人身份的可靠证据并对证明已取得该证据的相关记录予以维护。迁入注册服务商还要确保做出请求的实体真正获得了授权。实体身份可接受的形式有:

      • 公证书
      • 有效驾驶证
      • 护照
      • 企业章程
      • 军官证
      • 国家 / 政府颁发的身份证件
      • 出生证

      2.1.3 如果迁入注册服务商通过电子流程来获得授权 , 可接受的身份认证形式包括 :

      • 符合迁入注册服务商所在国家立法规定的电子签名(如有立法)。
      • 来自个人或实体的同意书(电子邮件地址需要与迁移联系人的电子邮件地址相同)。

      登记在册注册服务商不可单独否决迁移申请,因为迁入注册服务商还未收到上面所提到的确认。

      迁入注册服务商只有在收到了确认之后才可进行迁移。所有迁移案例的前提是迁入注册服务商收到并验证了迁移联系人的迁移请求。

      2.2 通过传达注册服务商工具包中指 定的 " 迁移 " 命 令来请求注册管理执行机构数据库改为显示新注册服务商。

      2.2.1 传 达 " 迁移 " 命令即 代表迁入注册服务商已从授权 Whois 数据库列出的迁移联系人处获得了所需授权。

      2.2.2 迁入注册服务商负责注册域名持有者在注册服务商间转让域名请求的验证工作。但是 , 这并不妨碍登记在册注册服务商按照本政策第 3 部分的规定 , 行使独立确认注册域名持有者将域名迁移给迁入注册服务商的请求之权利。

    3. 登记在册注册服务商的义务

      登记在册注册服务商在收到来自注册服务商的未决迁移通知时,可选择独立确认注册域名持有者的申请。在独立确认申请时,登记在册注册服务商必须遵守本协议中与迁入注册服务商相关的标准。为确保登记在册注册服务商所采用的请求方式本身便于管理、详实明了 , 且能清楚地提供给迁移联系人来确认迁移联系人的意图 , 登记在册注册服务商必须使用 FOA 。

      FOA 需用英文传达 , 并且使用英文对所有因迁移请求而引发的争议进行裁决。注册服务商可选择使用其他语言与迁移联系人进行沟通。但是 , 选择这一方式的注册服务商对 FOA 翻译之后的非英文版本的准确性和完整性负责。而且 , 这种非英文的沟通方式必须符合本政策中规定的流程和步骤。这包括但不局限于注册服务商不得在 FOA 中添加用于迁移请求时取得迁移注册服务商同意的信息。

      这一要求不会妨碍登记在册注册服务商通过单独的渠道对其现有客户进行市场宣传。

      登记在册注册服务商应在可行的情况下将 FOA 发送给迁移联系人 , 但需要在收到注册管理执行机构迁移请求后的二十四 (24) 小时之内完成。

      如果登记在册注册服务商在五 (5) 个自然日内未对内注册管理机构的迁移请求通知作出回应 , 则视为自 动 " 同意 " 该迁 移。

      如果 Whois 中列出的迁移联系人未向登记在册注册服务商确认迁移请求 , 且登记在册注册服务商未明确否决迁移请求 , 则视为登记在册注册服务商允许进行迁移。

      如果登记在册注册服务商基于以下任何理由否决了迁移请求,必须向注册域名持有者和潜在迁入注册服务商提供否决的原因。登记在册注册服务商仅可在出现以下情况时否决迁移请求:

      1. 欺诈行为的 证据
      2. UDRP (统一域名争端解决规则)诉讼
      3. 有司法管辖权的法庭作出的法庭指令
      4. 对注册域名持有者或管理联系人身份的合理争议
      5. 域名已过期 , 先前注册期未付费 ( 包括信用卡拒付 );或者 域名未过期 , 先前或当前注册期未付费。但是 , 在所有情况下 , 登记在册注册服务商在否决迁移之前必须输 入 " 注册服务商持有 " 状 态。
      6. 来自迁移联系人的明确书面迁移拒绝。(如电子邮件、纸质文件或其他迁移联系人选择的明确自愿拒绝的流程)
      7. 域名已被置 于"锁定状态",前 提是注册服务商为已注册域名持有者提供了一套解除锁定状态的合理且易用的方法。
      8. 迁移请求发生在域名创建 60 天内 ( 按照该域名在注册管理机构的 Whois 记录 ) 。
      9. 域名距离上次迁移不满 60 天 ( 或其他确定的更短天数 )( 经过注册服务商双方的一致同意 且 / 或按照争议解决流程的决议而迁回原注册服务商的情况除外 ) 。 "已迁移"仅 代表按照本政策的程序进行了注册服务商间迁移。

      注册服务商更换请求不会被否决的情况包括但不局限于:

      • 未决或未来注册期未付款。
      • 未收到来自注册域名持有者或管理联系人的回应。
      • 域名处于 " 注册服务商锁定状态 " , 在迁移请求之前 , 注册域名持有者已获得了解除域名锁定状态的合理且易用的方法除外。
      • 域名注册期时间限制 , 首次注册后的前 60 天或注册服务商迁移后的前 60 天除外。
      • 在争议域名的注册域名持有者已为域名注册支付费用的情况下 , 注册服务商和业务合作伙伴 / 附属机构之间出现的一般费用违约。

      登记在册注册服务商拥有独立于迁移流程之外的其他机制向注册域名持有者收费。因此,如果出现付费争议,登记在册注册服务商不得将迁移流程作为保证能向注册域名持有者收取服务费用的机制。该情况的例外情况如下:

      (i) 在域名过期后提出迁移请求 , 先前注册期未付费 ; 或

      (ii) 在域名过期前提出迁移请求 , 当前注册期未付费。

    4. 注册服务商协作

      每个注册服务商都有保存文档副本的责任 , 这些文档包括 FOA 及迁移联系人对 FOA 的回应文件 , 这些可能在按照争议解决政策提出和解决争议时有需要。迁入注册服务商必须按照合约规定的标准文档保留政策 , 维护好从迁移联系人处收到的 FOA 。身份可靠证据必须和 FOA 一起保存。

      相关注册服务商间域名交易期间和之后,迁入注册服务商和登记在册注册服务商都必须提供有关迁移的可靠证据。这些信息只能在属于迁移交易方的其他注册服务商提出要求时提供。此外 , ICANN 、注册管理执行机构、拥有管辖权的法院或管理机构、第三方争议解决小组也可要求获得该信息 , 该信息需在收到请求后五 (5) 天内提供。

      迁入注册服务商必须按照迁出注册服务商的要求保留和出具书面和电子版的 FOA 复件。登记在册注册服务商要求获得 FOA 复印件时 , 迁入注册服务商必须在五 (5) 个自然日内满足登记在册注册服务商的这一要求 ( 包括提供随附的支持文档 ) 。如果无法在该规定时间内提供文档,按照本政策的要求提出迁移投诉时,注册管理执行机构或争议解决小组可据此废除该迁移。

      如果登记在册注册服务商或迁入注册服务商认为迁移请求的处理违反了本政策的规定 , 注册服务商可按照本政策 C 部分的规定启动争议解决程序。

      为便于进行迁移请求,注册服务商应提供并维护一个仅用于与其他注册服务商和注册管理机构联系的私人电子邮件地址:

      1. 该电子邮件地址仅用于与迁移请求相关的事务以及本政策规定的程序。

      2. 应确保由能够对迁移问题作出回应的人员负责该电子邮件地址的邮件接收工作。

      3. 该邮件地址接收到邮件后 , 应该在合理的商业期限内 , 也就是七 (7) 个自然日内对邮件内容作出回应。

    5. 基于 EPP 的注册管理机构对注册服务商的要求

      基于 EPP ( 可扩展供应协议 ) 的通用顶级域名注册管理机构下的注册服务商必须满足以下要求。

      如果注册服务商未向注册域名持有者提供生成和管理其独有 " AuthInfo " 代 码的工具 , 注册服务商必须在收到注册域名持有者 " AuthInfo " 代码首次请求 的 五 (5) 天内向注册域名持有者提供。

      注册域名持有者请求获得适用的 " AuthInfo 代码 " 时 , 注册服务商为满足这一请求而采取的机制不得比用于更改注册域名持有者联系人或名称服务器信息的机制更为严格。

      登记在册注册服务商不得仅仅是因为注册域名持有者与注册服务商之间有付款争议 , 而拒绝向注册域名持有者提供 " AuthInfo 代码 " 。

      注册服务商生成的 " AuthInfo " 代码必须针对唯一的域名。

      " Auth-Info " 代码仅可用于确认注册域名持有者的身份 , 但是按照本政策第 2 部分和第 4 部分的要求 , 仍需要 FOA 进行迁移请求的授权或确认。

    6. 注册管理机构要求

      从迁入注册服务商收到 "迁移"命 令后,注册管理执行机构会向注册服务商双方发送电子通知。对于使用电子邮件进行通知的注册管理机构,可将回应通知发送到每个注册服务商的迁移专用邮箱。

      注册管理执行机构需要完成所请求的迁移 , 除非在五 (5) 天之内 , 注册管理执行机构收到来自登记在册注册服务商的 NACK 协议命令。

      注册管理机构的最新数据库反映出迁入注册服务商的更改时,注册管理执行机构将向注册服务商双方发送电子通知。可将通知发送到每个注册服务商的迁移专用邮箱或是各方同意的其他邮箱。

      迁移完成后,如果注册管理执行机构收到以下通知之一,将撤销迁移。此时将发生反向迁移,域名重新回到其原始状态。注册管理执行机构必须在收到通知五 (5) 天内撤销迁移 , 除非有注册管理机构争议决议 , 此时注册管理执行机构必须在 14 个自然日内撤销迁移 ( 法庭诉讼除外 ) 。撤销迁移需要收到以下通知之一:

      1. 通过电子邮件、信件或传真发送的登记在册注册服务商和迁入注册服务商的协议 , 声明迁移有误或不符合本政策规定的程序。

      2. 拥有迁移管辖权的争议解决机构所作出的最终决定;或者

      3. 拥有迁移管辖权的法院发出的指令。

    7. 注册记录

      每个注册服务商需要其客户 - 注册域名持有者维护好自己的记录 , 以便对首次域名注册数据进行存档和证明。

    8. 注册条款生效

      只要注册域名的总未满期限未超过十 (10) 年 , 注册管理执行机构按照本政策 A 部分完成持有者授权迁移即会使得现有注册域名延长一年。

  2. 经 ICANN 许可的迁移

    如果注册服务商因为以下原因需要对其赞助的所有注册域名进行赞助权迁移, (i) 该注册服务商或其资产被其他注册服务商收购 , 或 (ii) 未获得注册服务商认证或未取得注册管理执行机构授权 , 则按照以下程序进行迁移 :

    (a) 迁入注册服务商必须获得 ICANN 注册管理机构 TLD 的认证 , 且必须与注册管理机构 TLD 的注册管理执行机构签署注册管理机构 / 注册服务商协议。

    (b) ICANN 必须向注册管理执行机构书面保证迁移有利于机构群体的利益 , 例如避免注册服务商已经或即将倒闭而威胁到稳定性方面的利益。

    如果注册管理执行机构对以上两个条件满意 ,那么 对于涉及注册域名不超过 50,000 个的迁移 , 注册管理执行机构将免费对注册管理机构数据库进行一次性修改。对于涉及注册域名在 50,000 个以上的迁移 , 注册管理执行机构将对迁入注册服务商一次性统一收费 50,000 美元。

  3. 迁移争议解决政策

    迁移争议解决政策对如何处理有关注册服务商间迁移的争议问题进行了规定。相关注册管理执行机构和 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."