跳到主要内容

4. 传输 (Transport)

本节描述 AXFR 的传输协议要求. 原始 DNS 规范定义 AXFR 在 TCP 上运行, 这仍然是 AXFR 唯一标准化的传输方式.

4.1. TCP​

AXFR 必须使用 TCP 作为其传输协议. TCP 提供可靠, 有序, 且带错误检查的数据交付, 这对区域传输的完整性至关重要.

4.1.1. AXFR Client TCP​

AXFR client 与 AXFR server 的 DNS 端口建立 TCP 连接 (通常为端口 53, 但可以配置其他端口).

连接建立:

  1. AXFR client 发起 TCP three-way handshake, 以便与 AXFR server 建立连接.

  2. TCP 连接建立后, AXFR client 按第 2.1 节规定发送 AXFR query message.

  3. 随后 AXFR client 等待 AXFR server 以一条或多条包含区域数据的 DNS response messages 进行响应.

连接保持:

  1. AXFR client 应该保持 TCP 连接打开, 直到收到完整区域传输. 完整传输由某条 response message 的 answer section 中收到最终 SOA RR 表示.

  2. 收到完整区域传输后, AXFR client 可以关闭 TCP 连接, 或可以保持其打开以发送其他查询 (尽管这不是 AXFR 的典型行为).

  3. AXFR client 必须准备好应对 AXFR server 在任何时候关闭 TCP 连接, 包括在完成区域传输后立即关闭.

超时:

  1. AXFR client 应该实现读写超时, 以检测无响应服务器或网络问题.

  2. 推荐超时值随区域大小和网络条件而异, 但典型读超时可能在数分钟范围内 (例如 5-10 分钟), 以适应大型区域.

  3. 如果发生超时, AXFR client 应该关闭 TCP 连接, 并将区域传输视为失败.

错误处理:

  1. 如果 AXFR client 收到 RCODE 不是 NOERROR 的 DNS response message, 它必须将区域传输视为失败并关闭 TCP 连接.

  2. 如果 AXFR client 收到 malformed DNS message 或不符合 AXFR protocol 的消息, 它应该关闭 TCP 连接并将区域传输视为失败.

  3. 如果 TCP 连接过早关闭 (在收到最终 SOA RR 之前), AXFR client 必须将区域传输视为失败, 并丢弃收到的任何部分区域数据.

多个查询:

  1. AXFR client 可以在同一 TCP 连接上发送多个 AXFR queries, 这种做法称为 "pipelining" 或 "connection reuse". 但是, 此行为并未广泛实现, 也不是必需的.

  2. 如果 AXFR client 发送多个查询, 它必须等待第一个查询的完整响应 (包括最终 SOA RR) 之后再发送下一个查询.

  3. AXFR server 不要求支持每个连接多个查询, 并且可以在响应单个查询后关闭连接.

4.1.2. AXFR Server TCP​

AXFR server 在其 DNS 端口监听传入 TCP 连接 (通常为端口 53).

连接处理:

  1. 接受 TCP 连接后, AXFR server 等待从 AXFR client 接收 DNS query message.

  2. AXFR server 解析 query message, 以判断其是否为有效 AXFR query (如第 2.1 节定义).

  3. 根据该查询和适用策略 (例如 ACLs, TSIG authentication), AXFR server 要么以区域数据响应, 要么以错误消息响应.

响应传输:

  1. 如果区域传输已授权, AXFR server 按第 2.2 节规定发送一条或多条包含区域数据的 DNS response messages.

  2. 每条 response message 都作为完整 DNS message 在 TCP 连接上发送. AXFR server 必须确保保留消息边界 (即每条 DNS message 前面都有 RFC 1035 第 4.2.2 节规定的 2-byte length field).

  3. AXFR server 持续发送 response messages, 直到所有区域数据 (包括最终 SOA RR) 均已传输.

连接终止:

  1. 发送最终 response message (包含尾随 SOA RR) 后, AXFR server 可以立即关闭 TCP 连接, 或可以保持其打开以接受其他查询.

  2. AXFR server 应该在合理超时后关闭空闲连接, 以释放资源.

  3. 如果发生错误 (例如 write error, timeout, 或 internal error), AXFR server 可以随时关闭连接.

并发:

  1. AXFR server 应该能够处理多个并发 AXFR sessions (即来自不同 clients 的多个 TCP connections).

  2. AXFR server 可以对并发区域传输数量施加限制, 以防止资源耗尽.

4.2. UDP​

UDP 上的 AXFR 未标准化, 并且在 general-purpose DNS implementations 中不得使用. 虽然早期 DNS 规范曾提及小区域可通过 UDP 进行 AXFR 的可能性, 但这种方式有显著限制:

  1. 可靠性: UDP 是不可靠协议, 不保证 packet 的交付或顺序.

  2. 消息大小: UDP 上的 DNS messages 大小受限 (没有 EDNS(0) 时通常为 512 字节, 使用 EDNS(0) 时最高约 4096 字节), 对大多数区域传输并不实用.

  3. 未标准化: 现代 DNS 规范中没有针对 UDP 上 AXFR 的标准化格式或行为.

因此, UDP 上的 AXFR 被视为已过时, 并且不得在新的 DNS 软件中实现. 较旧 DNS 文档中对 UDP 上 AXFR 的任何引用都属于历史内容, 应予忽略.

建议: AXFR clients 和 servers 必须使用 TCP. 如果出于某种原因需要基于 UDP 的区域同步, 实现者应考虑使用 UDP 上的 IXFR [RFC1995], 尽管 IXFR 通常也通过 TCP 执行.

最后于 更新