YD T 3846.3-2021 互联网基础资源支撑系统信息交换接口规范 第3部分：域名权威解析服务.pdf

《YD T 3846.3-2021 互联网基础资源支撑系统信息交换接口规范 第3部分：域名权威解析服务.pdf》由会员分享，可在线阅读，更多相关《YD T 3846.3-2021 互联网基础资源支撑系统信息交换接口规范 第3部分：域名权威解析服务.pdf（24页珍藏版）》请在麦多课文档分享上搜索。

1、YD/T XXXXXXXX I ICS 33.040 M 21 YD/T YD/T 2017 中 华 人 民 共 和 国 通 信 行 业 标 准 互联网基础资源支撑系统信息交换接口 规范 第 3 部分：域名权威解析服务 Technical specifications for information exchange interface of Internet basic resource monitor management system - Part 3：Domain name authoritative resolution （报批稿） -发布 -实施 中 华 人 民 共 和 国 工 业

2、 和 信 息 化 部 发 布 YD/T XXXXXXXX I 目 次 前言 .II 1 范围 .1 2 术语和定义 .1 3 缩略语 .2 4 系统概述 .2 5 接口功能 .3 5.1 数据上报 .3 5.2 数据下载 .3 6 接口流程 .3 6.1 数据上报流程 .3 6.2 数据下载流程 .6 7 接口方法 .6 7.1 版本说明 .6 7.2 方法说明 .6 8 交换接口使用要求 .9 8.1 部省系统接口服务建设要求 .9 8.2 企业侧系统的建设要求 .10 9 数据格式定义 .10 9.1 上报数据格式 .10 9.2 基础代码下载数据格式 .17 9.3 接口返回数据格式 .

3、19 II 前 言 。 “互联网基础资源支撑系统 ”系列标准包括 互联网基础资源支撑系统信息交换接口规范 、 互 联网基础资源支撑系统监管信息交换接口规范 和 互联网基础资源支撑系统接口测试规范 ， 本部分 是互联网基础资源支撑系统信息交换接口规范 的第 3部分，该标准的预计结构和名称如下： 第 1部分：域名注册服务 第 2部分：域名管理服务 第 3部分：域名权威解析服务 第 4部分：域名递归解析服务 第 5部分： ICP网站 第 6部分： IP地址 第 7部分：内容分发网络（ CDN） 本部分按照 GB/T 1.1-2009给出的规则起草。 请注意本文件的某些内容可能涉及专利。本文件的发布机

4、构不承担识别这些专利的责任。 本部分由中国通信标准化协会提出并归口。 本部分 起草单位 ： 国家计算机网络应急技术处理协调中心 ， 天津市国瑞数码安全系统股份有限公司 。 本部分 主要起草人 ： 云晓春 、 李湘宁 、 陈悦 、 舒敏 、 陆希玉 、 蒋凌云 、 曹华平 、 任彦 、 窦禹 、 张牙 、 张勇。 YD/T XXXXX2017 1 互联网基础资源支撑系统信息交换接口规范 第 3 部分：域 名权威解析服务 1 范围 本部分规定了互联网基础资源支撑系统与各域名权威解析服务企业之间的数据交换接 口。 本部分适用于为各顶级域注册体系下注册的域名提供权威解析服务的企业所建设的互 联网基础资

5、源支撑系统 ， 包括但不限于提供域名权威解析服务的域名注册管理机构 、 域名注 册服务机构和其它机构。本部分不适用于顶级域权威解析。 2 术语和定义 下列术语和定义适用于本文件。 2.1 部级系统 management system of MIIT 工业和信息化部建设的 互联网基础资源支撑系统 的部级部分。 2.2 省局系统 management system of CA 工业和信息化部建设的互联网基础资源支撑系统的省局部分。 2.3 企业侧系统 management system of enterprises 域名权威解析业务经营企业建设的互联网基础资源支撑系统的企业部分。 2.4 域 名系

6、统 domain name system， DNS 因特网上作为域名和 IP地址相互映射的一个分布式数据库 ， 能够使用户更方便的访问互 联网，而不用去记住能够被机器直接读取的 IP数串。 2.5 域名权威解析服务 domain name authoritative resolution 在某个或者多个区域 （即权威域 ） 内 ， 提供原始 （权威 ） 域名资源记录信息的解析服务 。 2.6 区域文件 zone file YD/T XXXXX2017 2 用于描述一个 DNS的一个区域的文本文件，区域文件由多个资源记录（ RR）组成。 2.7 资源记录 resource record， RR

7、DNS 系 统 中 的 区 域 文 件 中 的 一 行 记 录 ， 记 录 的 格 式 为 ： ，更多相关信息请参考 IETF RFC1035。 3 缩略语 下列缩略语适用于本文件。 BIND DNS RR 伯克利因特网名字域系统 域名系统 资源记录 Berkeley Internet Name Domain Domain Name System Resource record SOA TTL XML 起始授权机构记录 生存时间 eXtensible Markup Language Start Of Authority Time To Live 可扩展标记语言 4 系统概述 互联网基础资源管理

8、支撑系统主要实现对互联网基础资源数据信息的采集汇聚 、 管理支 撑以及协同联动 ， 建成集中 、 完整 、 准确 、 可信 、 权威 、 开放的支撑平台系统 。 互联网基础 资源支撑系统采用三级体系结构 ： 部级系统、省局系统（以下简称为部省系统）和企业侧系 统。 其关系如图 1 所示： 图 1 系统体系结构图 部 级 系 统 省 局 系 统 省 局 系 统 企 业 侧 系 统企 业 侧 系 统 企 业 侧 系 统企 业 侧 系 统 信 息 交 换 接 口 YD/T XXXXX2017 3 部级系统处于架构的最上级 ， 主要存储全国域名权威解析数据 ， 并对全国的域名权威解 析数据进行管理、查

9、询、统计等操作。 第二级是省局系统 。 省局系统存储本省相关企业的域名权威解析数据 ， 同时实现本省域 名权威解析数据的统计、查询等功能。 第三级是企业侧系统 ， 由权威域名解析服务提供企业根据此标准规范自行建设 ， 主要实 现域名权威解析数据的上报功能。企业侧系统需要与所在省的部省系统 通过 WebService 接 口将企业权威域名解析基础数据上报。 如果企业使用 BIND 提供 DNS 服务则需要与部省系统 的 BIND 辅助节点进行同步。如果企业 不使用 BIND 软件系统则需要提供 SFTP 服务器端，供 部省系统下载区域文件 。 本部分规定了企业侧系统与部省系统之间的数据交换接口

10、。 5 接口功能 5.1 数据上报 企业侧系统向部省系统上报权威解析服务器数据的功能 ， 企业侧系统要与企业所在省份 的部省系统进行对接，并将数据上报到部省系统。上报功能主要包括： 1) 企业基本信息修改； 2) 域名解析服务器信息：新增、删除； 3) 资源记录上报。 5.2 数据下载 完成企业侧基础数据的下载，数据包括： 1) 单位性质代码信息； 2) 区域代码信息； 3) 证件类型代码信息。 6 接口流程 6.1 数据上报流程 6.1.1 企业基本信息、解析服务器上报流程 流程如图 2 所示，具体为： YD/T XXXXX2017 4 图 2 数据上报流程 1） 企业侧系统使用 WebSe

11、rvice方式调用部省系统的 upload方法 ， 将数据上报至所 在省的部省系统，上报数据请见 9.1.1、 9.1.2节； 2） 部省系统接收企业侧上报的数据，完成信息校验后进行保存； 3） 如果部省系统已经存在上报过的企业基本信息或者解析服务器信息 ， 则先删除 后再进行保存，所以企业每次应上报全量数据； 4） 部省系统将接收结果返回企业侧系统。 6.1.2 资源记录上报流程 资源记录通过文件方式上报至部省系统 ， 需要企业提供资源记录 文件下载 SFTP服务器 ， 部省系统连接 企业提供的 SFTP 服务端下载资源记录文件 ， 源记录文件数据格式分为文本格 式和 XML 格式。 6.1

12、.2.1 资源记录 上报周期 每周一上报全量数据，周二至周日每天上报增量数据，时间计划 要求如表 1。 表 1 资源记录上报周期表 时间 全量 /增量 数据时间要求 周一 全量 每 周一的 12 点之前将截止至上周 日 23:59:59 之前的 全量资源记录数据 放到 SFTP 服务端的下载目录中。 周二 增量 12 点之前将前一天（即周一 的 0:00-23:59:59）的增 量资源记录数据 放到 SFTP 服务端的下载目录中。 周三 增量 12 点之前将前一天（即周 二的 0:00-23:59:59）的增 量资源记录数据 放到 SFTP 服务端的下载目录中。 周四 增量 12 点之前将前一

13、天（即周 三的 0:00-23:59:59）的增 量资源记录数据 放到 SFTP 服务端的下载目录中。 周五 增量 12 点之前将前一天（即周 四的 0:00-23:59:59）的增 企 业 侧 系 统 部 省 系 统 校 验 并 保 存 数 据 结 果 信 息 upload YD/T XXXXX2017 5 量资源记录数据 放到 SFTP 服务端的下载目录中。 周六 增量 12 点之前将前一天（即周 五的 0:00-23:59:59）的增 量资源记录数据 放到 SFTP 服务端的下载目录中。 周日 增量 12 点之前将前一天（即周 六的 0:00-23:59:59）的增 量资源记录数据 放到

14、 SFTP 服务端的下载目录中。 6.1.2.2 上报文件命名规则 资源记录文件格式要求和上报文件命名规范详见 9.1.3。 6.1.2.3 上报流程 流程如图 3所示，具体为： 图 3区域文件上报流程 1） 企业将上报的域名资源记录文件（文件格式见 9.1.3）进行打包、压缩； 2） 如果超过文件压缩后超过 1GB则需要分卷； 3） 对压缩文件进行加密； 4） 对加密 后的文件进行哈希 （ md5， 可使用 Linux系统的 md5sum命令计算哈希值 ） 计 算，并生成校验文件； 5） 企业将加密后的压缩文件和校验文件放到 SFTP服务端下载目录； 企 业 侧 部 省 系 统 2.对 压

15、缩 文 件 加 密 ， 加 密 后 文 件 名 不 变 ， 如 需分 卷 则 对 压 缩 文 件 分 卷 1.准 备 域 名 资 源 记 录 文 件并 压 缩 3.对 压 缩 文 件 进 行 哈 希 计 算 ， 生成 校 验 文 件 5.下 载 注 册 文 件 解 压 、 解 析 4.将 加 密 文 件 和 校 验 文 件 放 到SFTP下 载 目 录 如 果 解 压 失败 ， 则 向 企 业 发 送 短 信和 邮 件 通 知 YD/T XXXXX2017 6 6） 部省系统通过 SFTP下载企业服务器上的域名资源记录数据文件； 7） 部省系统对下载的资源记录 文件进行 （如果文件为分割文件则

16、合并 ） 校验 、 解压和 解析； 8） 如果校验、解压或解析失败，则向企业相关负责人发送短信和邮件通知。 6.2 数据下载流程 流程如图 4所示，具体为： 图 4 数据下载流程 1） 企业侧系统调用部省系统 WebService的 download方法，下载上报结果和基础数据； 2） 部省系统查询是否有需要该企业下载的数据，若有 返回数据 ； 否则，告知企业侧系 统没有数据需要下载。 7 接口 方法 7.1 版本说明 接口方法使用的 XML 格式数据含有接口版本信息， 使用 XML 根节点元素 “version”属 性的值进行标识 。 版本号格式为 V.1.0， 所有依据本部分 生成的 XM

17、L 文件须填写本版本号 。 部级系统和省局系统均要校验当前系统支持的接口版本 ， 版本校验通过后方能进行下一 步处理，否则返回版本错误提示信息。 7.2 方法说明 按照本部分要求 ， 企业侧应建设 数据交换 SFTP 服务 ， 为部省系统提供域名注册数据下 企 业 侧 系 统 部 省 系 统 download() 返 回 结 果 数 据 YD/T XXXXX2017 7 载功能。 7.2.1 upload 方法 7.2.1.1 服务请求地址 https:/服务器 IP 地址 /adnsservice/exchange?wsdl 7.2.1.2 方法原型 String upload (Long

18、enterpriseId, String randVal, String pwdHash, String data, int dataType, String dataHash, int encryptAlgorithm, int hashAlgorithm) 7.2.1.3 方法描述 企业侧系统通过调用本方法实现企业基本信息和解析服务器数据上报。 企业侧系统在调用该接口方法时，需要要 产生长度为 20 个字节的随机字符串（数字和 大、小写字母 ） ，并将部级系统或省局系统分配的口令与该随机字符串连接（例如，口令是 字符串 “1234567890”，生成的随机字符串是 “abcdefghij”

19、，那么连接后的结果是字符串 “1234567890abcdefghij”） 。 将连接后的结果转换为 UTF-8 编码的二进制数据， 使用 hashAlgorithm 定义的哈希算法进行哈希计算， 得到参数 pwdHash 的值作为认证信息。 企业侧系统在调用该方法上报数据时， 所上报的 XML 数据文件大小不能超过 50MB。 企业侧系统在上报完数据文件后 ， 建议保存该数据文件 3 个月以上 ， 以保证系统处理文 件出现错误时重新上传数据文件。 企业侧系统 要对需要上报的信息编制 XML 文件，然后依序进行如下处理： 1） 对上报 的 XML 字符串数据转换成 UTF-8 编码的二进制数组

20、 ; 2） 如需加密上传，对二进制使用 参数 encryptAlgorithm 指定的加密算法进行加密 ; 3） 对二进制数组使用 参数 hashAlgorithm 指定的哈希算法计算哈希值，并对哈希值转 换成 16 进制 字符串形成 dataHash。 7.2.1.4 参数描述 本方法共使用 8 个参数， 各项参数的描述如表 2 所示。 表 2 upload 接口参数表 参数名称 参数类型 参数描述 enterpriseId 字符串 企业的标识，由部省系统产生 randVal 字符串 企业侧系统调用该方法时生成的随机字符串， 长度是 20 字节 YD/T XXXXX2017 8 pwdHas

21、h 字符串 使用指定的哈希算法对用户密码和随机字符串转换 为 UTF-8 编码二进制数组进行哈希运算 ， 然后将哈希值转 换为 16 进制字符串得到的结果，认证口令由部省系统 产生。 data 字符串 企业 基本信息修改或解析服务器 XML 数据字符串 ， 如 需加密上传 ， 先 将 XML 字符串转换为 UTF-8 编码二进 制数组 ， 然后对二进制使用 参数 encryptAlgorithm 指定 的加密算法进行加密，加密 后进行 Base64 编码。 dataType 整型 1- 企业基本信息修改 2- 解析服务器上报 dataHash 字符串 对上报 信息 data 转换为 UTF-8

22、 编码二进制数组后进行 哈希运算得到的哈希值， 然后将哈希值转换为 16 进制 字符串。 encryptAlgorithm 整型 对称加密算法 0：不进行加密，明文传输 1： AES 加密算法 （ 128 位 、 CBC 模式 、 PKCS5Padding 补码方式 ） ，加密密钥由部级系统或省局系统产生 hashAlgorithm 整型 哈希算法 0： SHA-256 哈希算法 7.2.1.5 返回值 该方法返回一个 XML 数据流 ， 描述了本次操作的结果代码 ， 接口返回数据格式的描述 见 9.3。 7.2.2 download 方法 7.2.2.1 服务请求地址 https:/服务器

23、IP 地址 /adnsservice/exchange?wsdl 7.2.2.2 方法原型 String download (Long enterpriseId, String request, String randVal, String pwdHash , int hashAlgorithm) YD/T XXXXX2017 9 7.2.2.3 方法描述 通过该方法，企业侧系统可以下载基础代码数据。 企业侧系统在调用该接口方法时， 需要产生长度为 20 个字节的随机字符串（数字和大、 小写字母 ） ，并将部级系统或省局系统分配的口令与该随机字符串连接（例如，口令是字符 串 “12345678

24、90”，生成的随机字符串是 “abcdefghij”，那么连接后的结果是字符串 “1234567890abcdefghij”） 。 将连接后的结果转换为 UTF-8 编码的二进制数据， 使用 hashAlgorithm 定义的哈希算法进行哈希计算， 得到参数 pwdHash 的值作为认证信息。 7.2.2.4 参数描述 本方法共使用 5 个参数， 各项参数的描述如表 3 所示。 表 3 download 接口参数表 参数名称 参数类型 参数描述 enterpriseId 字符串 企业标识，由部省系统产生 request 字符串 XML 字符串， 根据 type 参数值 确定 XML 格式， 具

25、体请见 9.2 节中的下载请求格式描述。 randVal 字符串 企业侧系统调用该方法时生成的随机字符串 ， 长度是 20 字 节 pwdHash 字符串 使用指定的哈希算法对用户密码和随机字符串转换 为 UTF-8 编码二进制数组进行哈希运算 ， 然后将 哈希值转换为 16 进制字符串得到的结果，认证口令由部省系统产生。 hashAlgorithm 整型 哈希算法 0： SHA-256 哈希算法 7.2.2.5 返回值 该方法返回一个 XML 字符串 ， 其中描述了本次操作的结果代码 、 结果描述和基础代码 （基础代码 格式见 9.2） 。 8 交换接口使用要求 8.1 部省系统接口服务建设

26、要求 YD/T XXXXX2017 10 按照本部分要求 ， 部省系统要建设数据交换接口服务 ， 为企业侧系统提供域名权威解析 备案信息的上报及相关数据的下载功能 。 部省系统的数据交换接口服务建设 ， 应保证对企业 侧系统提供正常的数据上报和下载服务。 由于企业侧系统对数据交换接口服务的访问是不可控的 ， 在访问高峰时段 ， 容易形成数 据交换接口服务的访问瓶颈 ， 影响到系统的访问性能 。 为避免出现无法访问 、 访问速度慢的 情况 ， 应充分考虑系统建设的网络访问量 、 网络带宽需求 ， 并充分考虑系统的自我防护能力 。 8.2 企业侧系统的建设要求 企业侧系统通过对部级系统的数据交换接

27、口访问 ， 实现域名权威解析相关数据上报和相 关数据的下载功能 。 如果企业采用区域文件下载方式上报数据 ， 则须保证下载服务器可用性 。 为避免对部省系统的过度访问 ， 企业侧系统应安装本部分的要求进行建设 ， 并在运行过 程中应主动降低对数据交换接口服务的访问频率。 9 数据格式定义 9.1 上报数据格式 9.1.1 企业基本信息修改 企业修改企业的基本信息数据项见表 4。 表 4 企业基本信息 编号 节点 节点名称 必填 数据类型 长度（字节） 描述 1. sn 业务流水号 必填 字符串 128 由企业侧系统生成，生成规则： enterpriseId+Unix 时间戳（秒） + 自增序列

28、 例如 ： enterpriseId 为 10001 时间 戳 为 ： 7654321098 自增序列当前 为 1， 则 sn 为 ： 1000176543210981 2. enterpriseId 企业 Id 必填 字符串 128 省系统为企业分配的唯一标识 3. license DNS 企业许可证号 选 填 字符串 128 由 工信部颁发的 DNS 企业许可 证号 4. address 单位地址详细地址 必填 字符串 128 单位地址，例如：北京市海淀区 YD/T XXXXX2017 11 花园路 18 号 3 号楼 101 5. type 单位性质 必填 整型 / 见 9.2.2 单位

29、性质代码表 6. corporate 企业法人 必填 / / 企业法人信息与联系方式，具体 信息见 表 5 7. contacts 企业联系人信息 必填 / / 单位的网络安全责任人信息与联 系方式，具体信息见 表 5 表 5 联系人信息 编号 节点 节点名称 必填 数据类型 长度（字节） 描述 1 name 姓名 必填 字符串 32 人员姓名 2 certType 证件类型 必填 整型 / 人员的证件类型， 见 9.2.3 证件类 型代码表 3 cardNum 证件号码 必填 字符串 32 对应的证件号码 4 telephone 固定 电话 选填 字符串 32 固定 电话 5 mobile

30、移动电话 必填 字符串 32 移动电话 6 email 电子邮件 必填 字符串 64 电子邮件地址 9.1.2 解析服务器信息上报数据格式 基础数据上报内容包括企业信息 、 解析服务器机房信息 ， 数据上报不仅发生在基础数据 新增时 ， 还应在基础数据更新后经企业侧系统核实无误后立刻上传至部省系统 。 企业侧系统 主动上报类型分为：新增、删除种方式，上报格式见表 6。 表 6 新增 /删除解析服务器请求表 编号 节点 节点名称 必填 数据类型 长度（字节） 描述 1 new 新增的解析服务器 选填 / / 需要新增解析服务器业务操作标 识，解析服务器数据格式见 表 7 2 delete 删除解

31、析服务器 选填 / / 需要删除解析服务器业务操作标 识，解析服务器数据格式见 表 8 3 sn 业务流水号 必填 字符串 128 本次操作的流水号 ， 由企业侧系统 生成， 生成规则 ： enterpriseId+Unix YD/T XXXXX2017 12 时间戳（秒） +自增序列 例如 ： enterpriseId 为 10001 时间戳 为 ： 7654321098 自增序列当前为 1， 则 sn 为： 1000176543210981 a 上报信息时新增的解析服务器或删除解析服务器至少填写一个， new 和 delete 操作可以同时存在。 9.1.2.1 新增 新增解析服务器数据

32、， 如果系统已经存在上报企业的 相同机房 ID 数据 ， 系统会将数据 删除后再进行保存，所以企业必须每次上报该机房的全量数据信息，数据项见 表 7。 表 7 新增解析服务器表 编号 节点 节点名称 子节点 子节点名称 必填 数据类型 长度（字节） 描述 1. serverRoomId 机房 ID / / 必填 字符串 256 机房的 ID， 由 DNS 企 业生成企业内唯一 ID, 建议 使用 UUID 2. serverRoomNa me 机房名称 / / 必填 字符串 128 机房的名称统一规则 为： 机房所在街道（路） + 自定义具有实际意义 的机房名称 例：大屯路综合机房 在企业内部

33、机房名称 不可重复 3. serverRoomTy pe 机房 性质 / / 必填 整型 / 1-租用 2-自建 4. province 机房所在省 或直辖市 / / 必填 长整型 / 机房所在省 Id， 见 9.2.4表 13 5. city 机房所在市 或区（县） / / 必填 长整型 / 机房所在市 Id， 见 9.2.4 表 13 6. county 机房所在县 / / 选填 长整型 / 机房所在县 Id， 见 9.2.4 表 13 7. address 机房 地址 / / 必填 字符串 128 机房的通信地址 ， 例如 ： 北京市海淀区花园 路 YD/T XXXXX2017 13 1

34、8 号 linkType 链路类型 必填 整型 / 机房互联网出入口类 型 ： 1-电信 ； 2-联通 ； 3- 移动； 4-铁通； 9-其他 bandwidth 链路 带宽 必填 长整型 / 机房互联网出入口带 宽 (单位： Mbit/s) linkTime 链路分配时 间 必填 字符串 10 链路分配时间的时间 ， 采用 yyyy-MM-dd 的格式 8. gatewayInfo 链路信息 a useType 使用类型 必填 整型 / 1-自用 2-出租 ipVersion DNS服务 IP 地址版本 必填 整形 / 1-IPv4 2-IPv6 serverIp DNS 服务器 的 服务

35、IP地 址 必填 字符串 64 DNS 服务器的对外服 务 IP 地址，例如： 223.5.5.5 9. serverList DNS 服务器 列表 a serverDom ainName DNS 服务器 域名 必填 字符串 64 DNS 服务器的域名 a 该节点必填，可重复多次。 9.1.2.2 删除 数据删除操作会将该机房内所有的数据删除，数据格式如下： 表 8 删除机房数据表 序号 英文名 中文名 数据类型 长度（字节） 必填 描述 1. serverRoomId 机房 ID 字符串 128 必填 企业系统中机房数 据的 Id 注：当删除机房时，该机房的所有服务器也将删除 9.1.3 资

36、源记录 文件上报数据格式 资源记录（区域）文件上报支持文本和 XML两种格式，文本格式见 9.1.3.1， XML格式见 9.1.3.2。企业可以选择任意一种格式进行上报。 YD/T XXXXX2017 14 9.1.3.1 文本格式 采用文本格式进行资源记录上报 ， 应按照 9.1.3.1.1和 9.1.3.1.2的格式说明进行资源记 录文件生成，并对生成后的文件进行压缩，压缩后的文件命名规则应符合 9.1.3.1.3要求， 压缩文件大小限制及存放路径应符合 9.1.3.1.4要求。 9.1.3.1.1 区域文件格式 依据 IETF RFC 1035 提供区域文件 ， 其中应包括域名系统 (

37、DNS) 中使用的实际区域内 的所有记录，格式如下所示： $ORIGIN domain-name 举例： $ORIGIN . 600 IN NS . $ORIGIN . 600 IN NS . www 600 IN CNAME $ORIGIN . www 600 IN A 10.10.10.1 600 IN MX . 9.1.3.1.2 区域文件文本格式要求 区域文件命名要求如下： 1) 使用 $ORIGIN 指令标识资源记录的所属域名； 2) TTL 必须显示为十进制整数； 3) 所有域名均必须采用小写字母； 4) 在一个记录中必须仅使用一个制表符作为字段之间的分隔符； 5) 使用“ ”来表

38、示主域名； 6) 禁止使用 $INCLUDE 指令； 7) 禁止使用 $TTL 指令； 8) 禁止使用括号，例如，以便跨越线框继续在记录中使用字段列表； 9) 禁止使用注释“；”； 10) 禁止使用空行； 11) SOA 记录不是必须的，如果包含应出现在区域文件的第一行； 12) 一个区域文件中可以包含多个域的记录数据。 9.1.3.1.3 区域压缩文件命名规则 区域文件命名格式为： YYYYMMDD_fileType_type_S.ext.splitNum 。 文件名中的占位符替换规则如下： YYYYMMDD 替换为数据上报截止日期； YD/T XXXXX2017 15 fileType 替换为 txt； type 将被替换为： 1） “full”（如果数据代表完全数据 ） ； 2） “diff”（如果数据代表增量数据 ） 。 S为文件序号，如果只有 一个文件则为 1，如果包含多个区文件 则序号从 1 递增 ； ext 文件后缀 “zip”，完整性校验为 “zip.md5”（上报数据文件的哈希值文件 ） ，每 一个数据文件必须包含一个 md5 校验文件，例如 ： 数据文件： 20161215_full_1.zip 完