跳到主要内容

1. 引言 (Introduction)

用于维护某一区域内服务器一致性的 Domain Name System 标准机制包含三个要素. Authoritative Transfer (AXFR) 定义于 "Domain Names - Concepts and Facilities" [RFC1034] (本文档称为 RFC 1034) 和 "Domain Names - Implementation and Specification" [RFC1035] (下文称为 RFC 1035). Incremental Zone Transfer (IXFR) 定义于 "Incremental Zone Transfer in DNS" [RFC1995]. 用于及时通知区域变更的机制 (NOTIFY) 定义于 "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. 这些机制的目标是使一组 DNS 名称服务器能够对给定区域保持一致的权威性.

本文档按照当前 Internet 中实际部署的方式重新规定 AXFR 机制, 希望达到现代 Internet Standards 所要求的精确程度, 并由此更新 RFC 1034 和 RFC 1035.

1.1. 术语定义 (Definition of Terms)​

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL" 应按 "Key words for use in RFCs to Indicate Requirement Levels" [BCP14] 中的说明解释.

"newer"/"new" DNS 和 "older"/"old" DNS 分别指在本文档发布之后和之前编写的实现.

"General-purpose DNS implementation" 指面向广泛使用而开发的 DNS 软件. 这包括可作为库或独立进程自由访问的解析器和服务器, 也包括仅用于支撑 DNS 服务产品的专有实现.

"Turnkey DNS implementation" 指定制的, 单一用途的 DNS 实现. 这类实现由使用 DNS 协议消息格式的软件组成, 但并不符合 DNS 全部功能范围.

术语 "AXFR session", "AXFR server", 和 "AXFR client" 将在第 2 节第一段中, 于建立更多上下文之后引入.

1.2. 范围 (Scope)​

一般而言, 给定区域的权威名称服务器可以使用多种方式来实现其所服务区域内容的一致性. 例如, 有些 DNS 实现从关系数据库中组装应答 (而不是从 master files 中组装), 并依赖数据库的非 DNS 机制来同步数据库实例. 其中一些非 DNS 方案在某种程度上可以互操作. 然而, AXFR, IXFR, 和 NOTIFY 是唯一由协议定义的, 用于为一组名称服务器提供一致性的带内机制, 也是 IETF 指定的唯一机制.

本文档不涵盖不一致的 DNS 情形. 在某些 DNS 应用中, 一个区域的服务器并不意图保持一致.

1.3. 上下文 (Context)​

AXFR client 发出查询, 以便从 AXFR server 接收某一区域的内容. 这类传输是一种 DNS 查询类型, 并符合 DNS 协议规范, 包括查询头部和应答消息.

区域内容是区域内域名所拥有的权威 DNS RR. 通常, 一个 AXFR session 会传输某一区域的所有权威 RR, 但有一个例外. 跟随 zone cut 时, glue records 不会被传输.

区域传输由 DNS SOA refresh timer, NOTIFY 消息, 或操作员干预发起 (但并不排除其他方式). AXFR 通常仅限于专门配置为该区域主服务器的 secondary 的服务器, 来自其他客户端的查询会被拒绝.

RFC 1035 最初对 AXFR 的定义指定其运行在 TCP 之上. 本规范仅支持 TCP 上的 AXFR. 不过为完整起见, 本规范会在资料性附录中提及 AXFR-over-UDP.

一个 AXFR session 由一条 AXFR query message, 一条或多条 AXFR response messages, 以及最后的 TCP 连接终止组成. 如果满足以下两个条件, 则称 AXFR session 为 "successful": (1) AXFR client 收到成功的 AXFR response sequence, 且 (2) AXFR client 关闭 TCP 连接, 或 client 收到 AXFR server 已关闭 TCP 连接的确认.

本文档不处理区域传输安全性. 相关安全考虑见第 8 节.

1.4. 覆盖范围及与原始 AXFR 规范的关系 (Coverage and Relationship to Original AXFR Specification)​

本文档覆盖一种权威的, 不感知 DNS UPDATE 的, 从 primary 到 secondary 的 AXFR session, 不使用安全机制, 且所传输的区域是通过 IPv4 传输的 "normal" DNS zone. 也就是说, server 是该区域的 master 或 primary, client 是 secondary 或 slave server. 此定义的编写方式旨在允许扩展机制指示对其他参数值的覆盖.

为供参考, 本文档指出以下情况 (但不定义这些变体):

  • 区域传输可以在一个 slave 与另一个 slave 之间进行 (二者均为权威服务器).

  • 区域传输 client 可以是收集数据的 resolver 或 zone validator (非权威应用).

  • 存在一个可选协议扩展, 允许 "incremental transfers" -- Incremental Zone Transfer (IXFR) [RFC1995].

  • DNSSEC (通过 RFC 4033 [RFC4033], RFC 4034 [RFC4034], 和 RFC 4035 [RFC4035]) 为 DNS 定义了一种安全协议.

  • DNS UPDATE (RFC 2136 [RFC2136]) 提供了一种动态更新区域的方法.

  • 可以使用 IPv6 传输.

提及这些内容的目的是说明, 尽管本文档描述的机制只适用于特定场景, 仍有相关场景会参照本文档获取上下文. 上述变体并不全都等价, 当然也并非彼此独立, 并且可能属于也可能不属于本文档范围.

本文档的范围有意保持狭窄, 但其写法表明它描述的是一种可扩展机制.

最后于 更新