Skip to main content
Resources

面向 .COM、.NET 和 .JOBS 的详尽 WHOIS 过渡政策

本页面还提供其他语种：

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

新闻

2019 年 11 月 7 日，ICANN 董事会通过了有关推迟执行合同合规工作的决议。ICANN 合同合规部将推迟执行详尽 WHOIS 过渡政策，直到以下各项工作全部完成为止：

  • 通用顶级域 (gTLD) 注册数据政策实施审核小组 (IRT) 完成其审核工作，并且针对 ICANN 董事会于 2019 年 5 月 15 日采纳的快速政策制定流程 (EPDP) 团队建议，制定了实施预估时间表；
  • ICANN 组织和 IRT 就 EPDP 团队建议对现有政策和程序（包括详尽 WHOIS 过渡政策）的影响，向 GNSO 理事会提供了所需信息；以及
  • GNSO 理事会决定是否采取相应措施来更新影响详尽 WHOIS 过渡政策的相关政策和程序（可能包括决定是否开展其他政策工作、提供相关指导或采取其他措施）。

本文档中的关键字"必须"、"不得"、"要求"、"应该"、"不应"、"建议"和"可以"按照位于以下地址的 RFC 2119 进行解释：http://www.ietf.org/rfc/rfc2119.txt。

适用范围：

本政策适用于 .COM、.NET 和 .JOBS gTLD 的注册管理运行机构，以及所有为注册 .COM、.NET 或 .JOBS gTLD 中的域名提供支持的注册服务机构。

定义：

    • 简略（注册）：由注册管理运行机构维护的域名，注册管理运行机构仅提供与域名相关的技术信息（例如，域名服务器、域名状态和创建日期）和提供支持的注册服务机构信息。域名联系人信息由提供支持的注册服务机构维护。
    • 详尽（注册）：由提供支持的注册服务机构向注册管理运行机构提供相关联系人信息副本的域名。注册管理运行机构维护与域名相关的技术信息（例如，域名服务器、域名状态和创建日期）和提供支持的注册服务机构信息。域名联系人信息由提供支持的注册服务机构维护。
    • 现有域名：在 2018 年 5 月 1 日之前创建的或处于 pendingCreate 状态的域名。
    • 过渡进度指标：指标由注册管理运行机构创建，并会定期发送给注册服务机构和 ICANN，以衡量从"简略"到"详尽"过渡的进度。这些指标至少包括由注册服务机构管理的域总数，以及附有联系人对象的域数量和百分比。

政策和有效日期：

3.1 所有新的域名注册都必须在 2018 年 5 月 1 日或之前作为"详尽"型注册提交。

3.2 现有域名的所有相关注册数据都必须在 2019 年 2 月 1 日前从"简略"型注册迁移到"详尽"型注册。

以下要求仅适用于注册管理运行机构：

4.1 注册管理运行机构必须在 2017 年 8 月 1 日前部署 EPP 机制或批量迁移机制，以便注册服务机构能够迁移现有域名的注册数据（例如，从"简略"型注册过渡到"详尽"型注册）。

4.2 注册管理运行机构必须在 2017 年 5 月 1 日之前向相关注册服务机构和ICANN 提供反映系统变更的文档，以支持 4.1 节中的要求。

4.3 注册管理运行机构必须于 2017 年 5 月 1 日之前在相关的运行测试环境 (OT&E) 中部署 EPP 机制或批量迁移机制，以便注册服务机构能够对现有域名注册数据的迁移工作进行测试（如，从"简略"型注册过渡到"详尽"型注册）。

4.4 注册管理运行机构必须在 2017 年 8 月 1 日之前支持在本条款中所述的 RFC5733 中指定的所有联系人命令。EPP 联系人字段<contact:id>、<contact:postalInfo type> 和 <contact:authInfo> 将为注册管理运行机构的必选字段。注册管理运行机构必须在 2019 年

2 月 1 日之前接受所有其他注册数据元素，但不得对这些数据元素提出要求，使之符合WHOIS（可通过端口 43 获取）和《2014 年 1 月 9 日批准的基本注册管理机构协议》（以下简称《基本注册管理机构协议》）规范 4 第 1 节或其后续修正案中规定的基于 Web 的目录服务要求，以及"注册管理机构注册数据目录服务一致性标签和显示政策"。

4.5 从 2018 年 5 月 1 日起，注册管理运行机构必须按照本条款中的规定，要求详尽注册数据符合 EPP 域对象 <create> 命令。注册管理运行机构必须对所有注册数据元素提出要求，使之符合WHOIS（可通过端口 43 获取）和在《2014 年 1 月 9 日批准的基本注册管理机构协议》（以下简称《基本注册管理机构协议》）规范 4 第 1 节或其后续修正案中规定的基于 Web 的目录服务要求，以及"注册管理机构注册数据目录服务一致性标签和显示政策"。

4.6 在 2017 年 8 月 1 日至 2019 年 2 月 1 日期间，注册管理运行机构应至少每月向每个注册服务机构提供过渡进度指标，截止时间为世界协调时下个月第一天的 23:59。

4.7 在 2017 年 8 月 1 日至 2019 年 2 月 1 日期间，注册管理运行机构应至少每月向ICANN提供所有注册服务机构的过渡进度指标，截止时间为世界协调时下个月第一天的 23:59。

4.8 注册管理运行机构可以在 2017 年 8 月 1 日之前，按照《2014 年 1 月 9 日批准的基本注册管理机构协议》（以下简称《基本注册管理机构协议》）规范 4 第 1 节或其后续修正案的规定，执行"注册管理机构注册数据目录服务一致性标签和显示政策"（"CL&D 政策"）的要求。

4.9 注册管理运行机构必须符合WHOIS（可通过端口 43 获取）和在《2014 年 1 月 9 日批准的基本注册管理机构协议》（以下简称《基本注册管理机构协议》）规范 4 第 1 节或其后续修正案中规定的基于 Web 的目录服务要求，以及"注册管理机构注册数据目录服务一致性标签和显示政策"（新注册截止日期为 2018 年 5 月 1 日，现有域名的截止日期为 2019 年 2 月 1 日）。

4.10 在 2017 年 8 月 1 日至 2019 年 2 月 1 日期间，对于现有域名和在共享注册系统 (SRS) 中没有数据存在的以下 RDDS 输出字段，注册管理运行机构可将以下 RDDS 字段作为备选，正如以下公告的说明 1 中所述："公告：《注册管理机构协议》相关说明和有关适用的注册数据目录服务 (WHOIS) 规范的《2013 年注册服务机构认证协议》(RAA) 相关说明"：

    • 注册管理机构注册人/管理员/技术人员 ID
    • 注册人/管理员/技术人员姓名
    • 注册人/管理员/技术人员所在街道
    • 注册人/管理员/技术人员所在城市
    • 注册人/管理员/技术人员所在国家/地区
    • 注册人/管理员/技术人员电话号码
    • 注册人/管理员/技术人员电子邮件

4.11 除非《注册管理机构协议》另有规定，否则，可以选择"账务"联系人。注册管理机构政策可以确定是"必选"、"可选"还是"不支持"。如果支持，"账务"联系人信息必须按以下公告中规定的格式显示："公告：《注册管理机构协议》相关说明和有关适用的注册数据目录服务 (WHOIS) 规范的《2013 年注册服务机构认证协议》(RAA) 相关说明"（第 22 节）。

以下要求仅适用于注册服务机构：

5.1 注册服务机构必须在 2017 年 8 月 1 日至 2019 年 2 月 1 日期间，向相关注册管理运行机构迁移所有规定的、在注册服务机构数据库中可用的现有域名字段，使注册管理运行机构符合 WHOIS（可通过端口 43 获取）和在《2014 年 1 月 9 日批准的基本注册管理机构协议》（以下简称《基本注册管理机构协议》）规范 4 第 1 节或其后续修正案中规定的基于 Web 的目录服务要求，以及"注册管理机构注册数据目录服务一致性标签和显示政策"。

5.2 从 2017 年 8 月 1 日起，在创建新域名注册之后，注册服务机构可以向注册管理运行机构提供完整的详尽注册数据，使其符合WHOIS（可通过端口 43 获取）和在《2014 年 1 月 9 日批准的基本注册管理机构协议》（以下简称《基本注册管理机构协议》）规范 4 第 1 节或其后续修正案中规定的基于 Web 的目录服务要求，以及"注册管理机构注册数据目录服务一致性标签和显示政策"。

5.3 从 2018 年 5 月 1 日起，在创建新域名注册之后，注册服务机构必须向注册管理运行机构提供完整的详尽注册数据，使其符合WHOIS（可通过端口 43 获取）和在《2014 年 1 月 9 日批准的基本注册管理机构协议》（以下简称《基本注册管理机构协议》）规范 4 第 1 节或其后续修正案中规定的基于 Web 的目录服务要求，以及"注册管理机构注册数据目录服务一致性标签和显示政策"。


实施注释

在本地隐私法和本政策中列出的要求相冲突时，注册管理运行机构和注册服务机构可以参考 ICANN 有关处理 WHOIS 与隐私法冲突的程序。

背景

在 GNSO 理事会批准了相关建议之后，ICANN 董事会于 2014 年 2 月 7 日采纳了 GNSO 详尽 WHOIS 工作组关于所有 gTLD 注册管理机构

使用详尽 WHOIS 的一致性政策建议。建议 #1 指出："详尽 WHOIS 服务的条款（《2013 注册服务机构认证协议》(RAA) 规范 3 中确定的一致性标签和显示模型）应适用于所有现有和未来的 gTLD 注册管理机构。"请参阅位于

http://www.icann.org/en/groups/board/documents/resolutions-07feb14-en.htm#2.c 的 ICANN 董事会第 2014.02.07.08 - 2014.02.07.09 号决议。

ICANN 与一个社群成员小组（例如，实施审核小组）合作实施了这些政策建议。在实施过程中，ICANN 在采纳这些建议之前，向社群征询了关于所提出的政策建议和本政策中所包含的语言的意见和建议。（请参阅 https://www.icann.org/public-comments/proposed-implementation-gnso-thick-rdds-whois-transition-2016-10-26-en）。

详尽 WHOIS 政策 PDP WG 的《最终报告》[PDF，1.23 MB] 第 7.2 节"实施注意事项"中还包含有关实施从简略向详尽 WHOIS 过渡的时间安排和要求的指导信息。其中明确指出："WG强调，某一部分建议的实施（例如，从现有的简略 gTLD注册向详尽注册过渡）没有必要延迟另一部分建议的实施（例如，此类数据的一致性标签和显示格式）"。

因此，ICANN 组织与实施审核小组合作采取了并行实施路径，将简略 WHOIS 注册转换为详尽注册，同时符合 Whois 数据的一致性标签和显示政策。有关详细信息，请参阅 https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en

A note about our terms of service:

We have updated our electronic terms of service to provide greater transparency and align with laws applicable to us. Learn more.

This site uses cookies to deliver an efficient user experience and to help us see how the site is used. Learn more.OK

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