1、ICS35.020 L07 YD 中华人民共和国 通信 行业标准 XX/T XXXXXXXXX 互联网新通用顶级域名服务 注册局业务数 据托管技术要求 Technical requirements of services for new generic top level domain registry data escrow 点击此处添加与国际标准一致性程度的标识 （报批稿） xxxx - XX - XX 发布 XXXX - XX - XX 实施 中 华 人 民 共 和 国 工 业 和 信 息 化 部 发 布 XX/T XXXXXXXXX I 目 次 前言 .II 引言 .III 1 范围
2、.1 2 规范性引用文件 .1 3 术语、定义和缩略语 .1 3.1 术语和定义 .1 3.2 缩略语 .2 4 概述 .2 5 通用惯例 .3 5.1 日期和时间 .3 6 数据托管格式 .3 6.1 通则 .3 6.2 根元素 .3 6.3 子元素 .4 6.4 子元素 .4 6.5 子元素 .5 6.6 子元素 .5 7 寄存文件的命名规则 .6 8 寄存文件的处理 .6 9 寄存通知 .7 10 验证程序 .7 10.1 基本验证程序 .7 10.2 扩展的验证程序 .7 11 公钥分发 .8 12 形式语法 .8 13 关于国际化域名 .10 14 安全考量 .10 参考文献 .12
3、 XX/T XXXXXXXXX II 前 言 本标准是“互联网新通用顶级域名服务技术要求 ”系列标准之一。该系列标准的结构和名称如下 ： 互联网新通用顶级域名服务 总体技术要求 互联网新通用顶级域名服务 支持 DNSSEC 的域名注册协议技术要求 互联网新通用顶级域名服务 域名注册协议启动期技术要求 互联网新通用顶级域名服务 域名注册协议赎回期技术要求 互联网新通用顶级域名服务 域名商标保护服务（ TMCH）流程和接口技术要求 互联网新通用顶级域名服务 区文件存取技术要求 互联网新通用顶级域名服务 注册局业务数据托管技术要求 互联网新通用顶级域名服务 注册局运行月报规范技术要求 互联网新通用顶
4、级域名服务 批量数据存取技术要求 本标准遵循 GB/T 1.1-2009的规则编写。 请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。 本标准由中国通信标准化协会提出并归口。 本标准起草单位 ： 互联网域名系统北京市工程研究中心有限公司、中国互联网络信息中心、北龙中 网（北京）科技有限责任公司、中国信息通信研究院 本标准主要起草人：马迪、高雷、刘阳、李岱明、周琳琳、邵晴、王伟、卢文哲、孔宁 XX/T XXXXXXXXX III 引 言 自 2012年 ICANN开放通用顶级域名以来，全球的域名服务进入了崭新的历史阶段，新的商业模式、 业务规范和支撑技术应运而生 。
5、 考虑到今后会有越来越多的机构成为新通用顶级域名注册局和相关服务 的提供者 ， 该系列标准的制定有利于指导相关企业部署和运行域名服务 ， 促进行业的健康发展 。 相关标 准的制定将有利于形成中国的最佳实践 。 结合中国的互联网治理环境 （例如工信部针对域名行业的备案 要求），本系列标准的制定也将有利于在域名范畴支撑互联网应用的可信可管可控。 XX/T XXXXXXXXX 1 互联网新通用顶级域名服务 注册局业务数据托管技术要求 1 范围 本标准规定了注册局的寄存数据的格式和内容 ,以及注册局定期向第三方服务商备份注册数据的数 据处理流程、算法、技术接口等 ,以便另一个注册局能够在不需要前者帮助
6、、并尽可能少的打扰其用户 的情况下 ， 及时重建前者的注册服务 。 因为每个注册局提供的注册服务细节都有所不同 ， 本标准提供一 种可扩展的机制 ， 从而可以容纳注册服务的变更和扩展 。 基于本标准 ， 注册局可以实现注册数据的第三 方托管功能 ， 并保证托管数据的安全性及完整性 。 该规范的设计独立于被托管的数据内容 ， 因此它可以 被用于除域名注册外的其他目的。 本标准适用于搭建同时符合 ICANN技术规范和工信部域名管理办法的新通用顶级域名系统。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的 。 凡是注日期的引用文件 ， 仅所注日期的版本适用于本文 件。凡是不注日期的引用文件
7、，其最新版本（包括所有的修改单）适用于本文件。 YD/T 2643-2013 域名注册协议可扩展供应协议技术要求 3 术语、定义和缩略语 3.1 术语和定义 下列缩略语适用于本文件 3.1.1 域名注册局 Registry 也称作“域名注册管理机构”，是指承担顶级域名系统的运行、维护和管理工作的机构。 3.1.2 域名注册商 Registrar 也称作“域名注册服务机构”，是指受理域名注册申请，直接完成域名在国内域名数据库中注册 、 直接或间接完成域名在国外顶级域名数据库中注册的机构。 3.1.3 托管代理 商 Escrow Agent 由域名注册局指定的组织，或受益第三方，其从注册局接收并保
8、护被托管的寄存数据。 3.1.4 受益第三方 Third-Party Beneficiary XX/T XXXXXXXXX 2 在特殊情况下接收域名注册局传送给托管代理的托管寄存数据的组织 。 这种组织可以是备份注册局 、 注册局监管机构或注册局合同方。 3.1.5 时间水印 Timeline Watermark 是一个时间点 ， 应基于该时间点收集所有用于一个寄存的数据库对象 。 寄存数据应该与该时间点一 致。 3.1.6 寄存 Deposit 寄存有三种类型 ： 完全寄存、差别寄存和增量寄存。对于这三种类型，数据托管要考虑的注册对象 的集合是为了提供注册局服务所必需的所有对象。 3.1.7
9、 全量 寄存 Full Deposit 包含注册局当前整个数据库的注册管理数据 ， 并且即将包含反应注册局 状态的数据 （该状态对应于 本个寄存的时间水印）。 3.1.8 差别寄存 Differential Deposit 包含所有未在上一个 （完全 、 增量或差别 ） 寄存中包含的交易数据 ， 视具体情况而定 。 差别寄存文 件必须包含从上一个寄存完成 （由它的时间水印指定 ） 起 ， 所有增加的 、 修改的或删除的数据库对象的 信息， 3.1.9 增量寄存 Incremental Deposit 包含所有未在上一个完全寄存中包含的交易数据。增量寄存文件必须包含从上一个完全寄存完成 （由它的
10、时间水印指定）起，所有增加的、修改的或删除的数据库对象的信息。 3.2 缩略语 下列缩略语适用于本文件。 ICANN 互联网名称与数字地址分配机构 The Internet Corporation for Assigned Names and Numbers RDE 注册局数据托管 Registry Data Escrow 4 概述 域名注册局的数据托管 ， 是指注册局周期性的向 第三方 （ 即 “托管代理 ”） 提交数据备份的过程 。 这 些数据应包括当注册局不能正常工作，或不能 /不愿意提供有秩序的数据传输服务时，被第三方用于恢 复操作的最小数据 。 例如 ， 对于一个域名注册局或注册商来
11、说 ， 待托管的数据应包含所有与已注册域名 相关的对象，如姓名、联系方式、域名服务器等。 数据托管的目标是为了互联网用户的利益 ， 为注册服务提供更高的回弹性 。 注册局的受益人不仅仅 包括注册信息的用户，还包括所有需要识别这些数据对象持有者的依赖方。 XX/T XXXXXXXXX 3 在域名注册局的上下文中 ， 注册数据托管是所有通用顶级域名的需求 ， 一些国家顶级域名管理者同 样也在托管数据。 ICANN认可的域名注册商也有类似的需求。 本标准规定了数据托管的格式 ， 该格式独立于被托管的对象 。 对每一类注册局 ， 或每一种待托管的 对象集合 ， 还需要制定专门的规范 ， 但这些规范不能
12、破坏本标准提供的必要条款 ， 或与这些条款相抵触 。 5 通用惯例 5.1 日期和时间 很多字段，如对象的建立和过期时间，被指定为“日期”格式。这些字段应该包含由 RFC 3339的 5.6 “互联网日期 /时间格式”规定的、 UTC（协调世界时）格式的时间戳。 1 6 数据托管格式 6.1 通则 本节定义了注册局生成的数据托管寄存的格式。按照本章以及互联网新通用顶级域名服务 批量 数据存取技术要求 的要求 ， 注册局对象 ， 例如域 、 联系人 、 名称服务器 、 注册服务商等 ， 将被编译成 一个寄存文件 （ 统称 “DNDE规范”） 。 DNDE规范将部分要素描述为可选 ； 如果注册局需
13、要使用这些要素 ， 可将其纳入寄存文件中。 如果注册局提供的某些服务需要提交上述以外的其他数据 ， 应根据具体情况逐个定义 “扩展性方案 ” 以体现相应数据。这些“扩展性方案 ”需要根据互联网新通用顶级域名服务 批量数据存取技术要求 的规定来制定。“扩展性方案”相关的数据将被纳入寄存文件中。 本节定义的数据托管寄存格式是对象不可知的，它允许 “承载 ”抽象元素，这些抽象元素使用 “substitutionGroup”属性来定义待托管对象的实际元素。应使用 UTF-8字符编码。 6.2 根元素 注册局 数据托管寄存的容器 （根元素 ） 是 。 该元素包含了以下子元素 ： watermark， d
14、eletes 和 contents。该元素包含以下属性： a） 一个必需的 “type”属性，用来标识寄存的类型： FULL（完全）、 INCR（增量） 或 DIFF（差 别）。 b） 一个必需的 “id”属性 ， 用来对每次托管寄存进行唯一标识 。 每一个注册局都有责任维护它自己 的托管寄存标识符空间，以保证唯一性，如使用 符合 YD/T 2643-2013 所规定的标识符。 c） 一个可选的 “prevId”属性 ， 用来标识上一次增量 、 差别或完全托管寄存 。 该属性必须用于差别 寄存（ “DIFF”类型）。 d） 一个可选的 “resend”属性， 它的值随着以下过程的重复而增加 ：
15、 如果接收方没有通过一个托管 寄存的验证过程 ， 注册局需要根据该寄存的特定日期生成新的托管寄存 。 第一次生成该寄存时 ， 该属性要么被忽略 ， 要么被置为 “0”。 如果该寄存需要被再次生成 ， 该属性必须被置为 “1”， 并 且以此类推。 根元素对象举例： 2010-10-18T00:00:00Z . . 6.3 子元素 一个必需的 元素包含与寄存的时间水印对应的日期 -时间。 元素对象举例： 2010-10-18T00:00:00Z . 6.4 子元素 该元素包含数据托管寄存的辅助信息。 一个必需的 元素包含以下子元素： a） 一个必需的 元素， 用来标识 RDE 协议版本。 b） 一
16、个或多个 元素，用来包含代表 和 元素对象的命名空间 URI。 元素对象举例： rde:deposit xmlns:rde=urn:ietf:params:xml:ns:rde-1.0 . 1.0 urn:ietf:params:xml:ns:rdeContact-1.0 urn:ietf:params:xml:ns:rdeHost-1.0 urn:ietf:params:xml:ns:rdeDomain-1.0 urn:ietf:params:xml:ns:rdeRegistrar-1.0 urn:ietf:params:xml:ns:rdeIDN-1.0 urn:ietf:params:x
17、ml:ns:rdeNNDN-1.0 urn:ietf:params:xml:ns:rdeEppParams-1.0 XX/T XXXXXXXXX 5 . 6.5 子元素 该元素应该出现在类型为“增量 ”或“差异 ”的寄存中。它包含了从前一个寄存起被删除的对象的 列表。该段中的每一个对象都应该包含被删除对象的 ID。 该段不应该出现在完全寄存中 。 当重建一次注册时 ， 如果该段出现在完全寄存中 ， 则它应该被忽略 。 每一个被托管的对象的规范中都必须声明用于引用待删除对象的标识符。 元素对象举例： rde:deposit xmlns:rde=urn:ietf:params:xml:ns:rde
18、-1.0 . foo.test bar.test sh8013-TEST co8013-TEST . 6.6 子元素 该元素包含一个寄存中的对象 。 它必须出现在所有类型的寄存中 。 它包含了待托管对象的数据 。 这 些实际对象应该被单独规定。 在增量寄存或差别寄存的情况下 ， 这些对象指明了在上一个寄存后该对象是否被增加或被修改 。 为 了区分一个和另一个对象，应该检查上一个寄存中这个被引用对象是否存在。 当使用增量或差别寄存（当从数据托管寄存中重建注册数据）时， 元素之间的相对顺序 很重要，对于 元素也同样如此。首先必须应用所有的 元素（按照它们出现的顺 序），然后必须应用所有的 元素（按
19、照它们出现的顺序）。 如果一个对象出现在多个寄存 （例如完全寄存和增量寄存 ） 的 段中 ， 当重建注册数据时 ， 应该使用来自最后一个寄存（根据时间水印的定义）的注册数据。 元素对象举例： rde:deposit xmlns:rde=urn:ietf:params:xml:ns:rde-1.0 . XX/T XXXXXXXXX 6 . Object1 specific. . Object2 specific. . . . 7 寄存文件的命名规则 文件将根据以下规则命名： gTLD_YYYY-MM-DD_type_S#_Rrev.ext 其中： a) gTLD将替换为 gTLD 名称； 如果是
20、 IDN-TLD， 则必须使用 ASCII 兼容的格式（ A 标签）； b) YYYY-MM-DD将替换为与交易时间线水印对应的日期 ， 例如 ， 对于与 2009-08-02T00:00Z 对应 的完全寄存，使用的字符串应该为“ 2009-08-02”； c) type将替换为： 1) “full”（如果数据代表完全寄存）； 2) “diff”（如果数据代表差别寄存）； 3) “incr”（如果数据代表增量寄存）； 4) “thin”（如果数据代表一个如互联网新通用顶级域名服务技术要求 批量数据存取 中指定的批量注册数据访问文件）。 d) #将替换为该文件在一系列文件中的位置，以“ 1”开头
21、；如果是单独的文件，则将替换为 “1”； e) rev将替换为文件修订（或重新发送）的次数，以“ 0”开头； f) ext替换为“ sig”（如果是准同名文件的数字签名文件）。否则将替换为“ ryde”。 8 寄存文件的处理 建议使用压缩技术以减少电子数据传输时间和存储容量要求 。 将使用数据加密来保护注册局托管数 据的隐私性。经压缩和加密处理的文件将按照 RFC 4880转换为二进制 OpenPGP格式。公钥加密、对称密 钥加密、哈希和压缩可接受的算法为 RFC 4880中列举的算法，而不是 OpenPGP IANA注册局中标记为不支 持的算法。原始文本格式的数据文件的处理流程如下： a)
22、寄存文件必须按本标准 第 8 章的规定命名， 但应使用 xml 作为扩展名； b) 数据文件均整合在一个命名同 a)的压缩包文件中， 但应使用 tar 作为扩展名； XX/T XXXXXXXXX 7 c) 创建经压缩和加密的 OpenPGP 消息时 ， 就将 tar 文件作为唯一输入文件 。 按照 RFC 4880， 建议 的压缩算法为 ZIP。 压缩数据将使用托管代理的公钥进行加密 。 根据 RFC 4880， 公钥加密算法 推荐使用 Elgamal 和 RSA。 根据 RFC4880， 对称密钥加密算法推荐使用 TripleDES、 AES128 和 CAST5； d) 文件在压缩和加密后
23、如果超过托管代理同意的文件大小限制，必要时可进行分割； e) 将使用注册局私钥为每一个已处理文件生成一个数字签名文件 。 根据 RFC4880， 数字签名文件 将为二进制 OpenPGP 格式，且不会压缩或加密。 根据 RFC 4880， 数字签名算法推荐使用 DSA 和 RSA。 数字签名中的哈希算法推荐使用 SHA256； f) 已处理文件和数字签名文件将通过托管代理和注册局之间达成的安全电子机制（ 如 SFTP、 SCP、 HTTPS 文件上传等 ） 传输到托管代理 。 如经 ICANN 授权 ， 可通过物理介质 （如光盘 、 DVD-ROM 或 USB 存储设备）进行非电子传输； g)
24、 托管代理将使用本标准第 11 节中所述的程序验证所传输的每一个（已处理）数据文件。 9 寄存通知 注册局每提交一个寄存，都必须同时向托管代理和 ICANN（使用 IETF Draft ICANN Registry Interfaces中所述的 API3）提交一份书面声明（可以通过经验证的电子邮件提交），其中要包含在 创建寄存时生成的报告副本 ， 并声明该寄存经过注册局检查 ， 是完整而准确的 。 注册局将在其声明中注 明寄存的 id和 resend属性（参见 6.2节）。 10 验证程序 10.1 基本验证程序 托管代理必须执行以下基本验证程序： a) 每一个数据文件的签名文件均需验证； b
25、) 如果一个文件是某个较大文件的分割部分，则需将分割部分合并； c) 对先前步骤中获得的每个文件进行解密并解压缩； d) 然后根据 本标准第 7 章定义的格式对先前步骤中包含的每个数据文件进行验证； 如果任一步骤中发现差异，则该寄存将视为不完整。 10.2 扩展的验证程序 托管代理必须执行一个扩展的验证过程 ： 使用某个时间点（时间水印 ） 的数据托管寄存的内容，最 近一次完全寄存加上所有差别寄存 ， 或者是最近一次完全寄存加上最近一次增量寄存 。 以下是建议的最 小测试： a） 使用经注册局同意的定义来验证托管寄存； 1) 在使用 XML 模型的情况下， 必须使用配置文件的 XML 模式来验
26、证托管寄存的内容。 b） 统计对象的数量 ， 并且验证对象的数量与该时间点 （水印 ） 托管寄存的 元素中报告的 元素数量相等； c） 所有与域名相关联的联系人对象必须存在； d） 所有与其他对象相关联的注册商对象必须存在； e） 元素要求列出的元素必须存在； f） 所有从其他对象关联来的 idnTableRef 定义都必须存在； XX/T XXXXXXXXX 8 g） 如果在过去托管了一个 EPP 参数对象， 有且仅有一个 EPP 参数对象必须存在； h） 水印时间不能处于未来。 11 公钥分发 每个注册局和托管代理将按照指定的电子邮件地址将公钥分发给另一方 （注册局或托管代理 ， 根据 具
27、体情况而定） 。 各方应该通过回复电子邮件确认收到另一方的公钥 ， 分发方随后将重新确认通过脱机 方法 （如面对面 、 电话等 ） 所传输密钥的真确性 。 通过这种方式 ， 可确认公钥被传输给能够通过分发方 运营的邮件服务器收发邮件的用户。托管代理、注册局和 ICANN将按照上述程序交换公钥。 12 形式语法 BEGIN Registry Data Escrow schema XX/T XXXXXXXXX 9 XX/T XXXXXXXXX 10 END 13 关于国际化 域名 XML被用于表示数据托管寄存 。 XML提供了对使用 unicode字符集 （以及它的包括 UTF-8在内的更紧凑 表达形式）编码的信息的自然支持。符合规范的 XML处理器可以同时识别 UTF-8和 UTF-16。尽管 XML提供 了识别和使用其他字符编码的方法（通过使用 声明中的 “encoding”属性），仍然推荐使用 UTF-8。 XX/T XXXXXXXXX 11 参 考 文 献 1 IETF RFC 3339 Date and Time on the Internet: Timestamps. 2 IETF RFC 4880 OpenPGP Message Format. 3 IETF Draft ICANN Registry Interfaces. _
