7. 向后兼容性 (Backwards Compatibility)

由于原始定义缺少具体细节, 描述向后兼容性比较困难. 本节给出构建向后兼容性的若干提示, 其中大部分重复自前文相关小节.

向后兼容性并非必要, 但实现的兼容范围越大, 其互操作性也越强. 对 turnkey implementations 而言, 这通常不是问题. 对 general-purpose implementations 而言, 其重要性会随实现者维持互操作性的意愿而变化.

遗憾的是, 是否需要回退到较旧行为无法被发现, 因而必须记录在配置文件中. 实现的文档应该鼓励操作员定期复查其反复记录的 AXFR clients 和 servers, 因为旧软件会不时更新.

7.1. 服务器 (Server)

AXFR server 有能力对 AXFR client 的能力作出反应, 但有一个例外: 它无法知道 client 是否能接受每条 AXFR response message 中包含多个 resource records. client 受到这种限制的知识无法被发现, 因此必须通过配置设置.

AXFR server 的实现可以允许按每个 AXFR client 配置是否需要回退到每条消息一个 resource record. 在这种情况下, 默认值应该是每条消息使用多个记录.

旧客户端考虑:

每条消息单个 RR: 一些非常旧的 DNS implementations 预期每条 AXFR response message 的 answer section 中只有一个 resource record. 现代 AXFR servers 应该支持每条消息多个 RRs 以提高效率, 但可以为特定 legacy clients 提供配置选项以回退到 single-RR 行为.
消息大小: 较旧 clients 可能对其可处理的 DNS messages 最大大小有限制. 与这类 clients 交互时, AXFR servers 可以提供配置选项来限制单条 response messages 的大小.
EDNS(0), TSIG, 和 SIG(0): 较旧 clients 可能不支持 EDNS(0), TSIG, 或 SIG(0). AXFR server 应该优雅处理不包含这些选项的 client 查询, 并且不应该要求这些选项存在, 除非出于安全原因专门配置为必须如此.

服务器实现建议:

AXFR client 在查询 AXFR server 时有机会尝试其他特性 (即本文档未定义的特性).

如果在 AXFR session 中试图通过 TCP transport 发出多个 DNS queries 会中断原始请求, 则应该中止该尝试, 并应该考虑 AXFR server 是否打算在完成原始 (引发连接的) 区域传输后立即关闭连接.

旧服务器考虑:

每条消息多个 RRs: 现代 AXFR clients 必须准备好在单个 AXFR response message 中接收多个 resource records. 这是标准行为, 并已广泛部署多年.
连接处理: 较旧 servers 可能在发送最终 SOA RR 后立即关闭 TCP 连接, 而其他 servers 可能保持连接打开一段时间. AXFR clients 应该准备好应对任一行为, 并且不应该依赖区域传输完成后连接仍保持打开.
错误响应: 一些较旧 servers 可能返回非标准错误响应, 或可能不严格符合 DNS message format. AXFR clients 应该实现稳健的错误处理, 以优雅处理意外响应.

客户端实现建议: