7. Design Issues (设计问题)
7. 设计问题 (Design Issues)
本节讨论与 DNS UPDATE 协议相关的各种设计决策和澄清.
7.1. 本文档有意将全部复杂性放在服务器端. Requestor 行为在很大程度上未作规定, 以便给予 requestor 尽可能大的自由度.
7.2. UPDATE 协议支持通配符 owner name (即包含 "*" label 的名称), 但限制是禁用通配符处理 (参见第 1.1.3 节). 这意味着更新中的通配符会按字面量处理, 不会执行通配符扩展或匹配.
7.3. RRset 的 TTL 可以通过先删除该 RRset, 再使用新的 TTL 重新添加该 RRset 来更新. 但是, CNAME 不能与同一名称处的任何其他 RRset 共存, 因此涉及 CNAME 的更新应谨慎执行, 以免产生非法配置.
7.4. 重复的 RR 将被静默忽略. 这意味着, 如果某个更新试图添加一个已在 zone 中存在且 RDATA 完全相同的 RR, 该更新会成功, 但不会对 zone 内容产生影响.
7.5. 预计在没有 Secure DNS Update 的情况下, 服务器只有在更新来自某个源地址时才会接受它, 且该源地址已在服务器对 primary master zone 的描述中静态配置. DHCP 服务器很可能是这个静态配置列表中的候选对象.
7.6. 无法使用此协议创建 zone, 因为协议没有提供机制来告知 slave server 其 master server 是谁. 预计未来会扩展此协议以覆盖这种情形. 因此, 目前不支持添加 SOA RR. 出于类似原因, 也不支持删除 SOA RR.
7.7. 用于指定某名称拥有至少一个 RR 的先决条件, 在语义上不同于 QUERY. 如果查询该名称处的某个 RRset, QUERY 会返回 <NOERROR,ANCOUNT=0>, 而不是 NXDOMAIN. 但 UPDATE 的先决条件 [Section 2.4.4] 将不会得到满足.
7.8. UDP 响应可能在传输途中丢失, 请求也可能因超时条件而被重试. 在这种情况下, 某个 UPDATE 第一次被 primary master 接收时已经成功, 但当 requestor 最终收到重复请求的响应时, 它可能看起来已经失败. (这是因为原始先决条件在更新应用后可能不再满足.) 因此, 需要准确响应代码的 requestor 必须使用 TCP.
7.9. 因为需要准确响应代码的 requestor 会使用 TCP 发起其 UPDATE 事务, 所以通过 TCP 接收请求的 forwarder 也必须使用 TCP 转发该请求.
7.10. 允许延迟 SOA SERIAL 自动递增, 这样可以节省 serial number, 并使 2**32 处的回绕成为不常发生的事件. 对 DNS client 可见的 SOA SERIAL 在 zone 不同时需要彼此不同. 注意, 就此先决条件而言, QUERY 响应的 Authority Section 中的 SOA 也是一种可见性形式.
7.11. 由于某些较旧但已广泛安装的 DNS 实现存在互操作性问题, zone 的 SOA SERIAL 永远不应设置为零 (0). 递增 SOA SERIAL 时, 如果递增结果为零 (0) (在 2**32 处回绕时会出现这种情况), 必须再次递增它, 或将其设置为一 (1). 关于此主题的更多细节参见 [RFC1982].
7.12. 由于缓存 RRset 时必须进行 TTL 最小化, 建议将 RRset 中的所有 TTL 设置为相同的值. 虽然 DNS Message Format 允许同一 RRset 中存在不同 TTL, 且这种差异也可能存在于 zone 内部, 但这种差异会产生反直觉的结果, 因此不鼓励使用.
7.13. Zone cut 管理会给 Update Section 中的添加和删除操作带来一些隐晦的边界情况. 可以删除 NS RR, 只要它不是 zone 根部的最后一个 NS RR. 如果删除某名称处的所有 RR, zone 根部的 SOA 和 NS RR 不受影响. 如果删除 RRset, 则不能删除 zone 顶部的 SOA 或 NS RRset. 尝试添加 SOA 时, 如果 SOA 已经存在, 将被视为替换操作; 如果该 SOA 是新的, 则视为 no-op.
7.14. 在 primary master server 添加新的 RR 时, 不要求进行语义检查. 因此, requestor 可以导致添加 CNAME, NS 或任何其他类型的 RR, 即使它们的目标名称不存在, 或不具备使原始 RR 有用的适当 RRset. 如果 primary master server 确实实现这种检查, 则应非常谨慎地避免 zone 外依赖 (无法以权威方式检查其真实性), 并应在 prescan 阶段执行所有此类检查.
7.15. 非终端或通配符 CNAME 在 [RFC1035] 中没有得到良好规定, 使用它们很可能导致不可预测的结果. 不鼓励使用.
7.16. 空非终端 (有子节点但自身没有 RR 的节点) 会导致对该名称任意类型的查询返回 <NOERROR,ANCOUNT=0> 响应. 协议没有为空终端节点提供规定. 因此, 如果终端节点的所有 RR 都被删除, 该名称就不再使用, 对该名称任意类型的查询都将产生 NXDOMAIN 响应.
7.17. 在深层 AXFR 依赖图中, 历史上 slave 之间相互依赖并不构成错误. 这种配置曾用于使 zone 能够从 primary master 流向所有 slave, 即使并非所有 slave 都与 primary master 保持连续连接. UPDATE 使用 AXFR 依赖图进行转发, 这禁止了此类依赖环路, 因为 UPDATE 转发没有类似 AXFR 使用的 SOA SERIAL 预检那样的环路检测.
7.18. 被新的 zone cut 遮蔽的既有名称, 就 zone transfer 而言仍被视为 parent zone 的一部分, 即使针对这些名称的查询会被引介到新的 subzone 服务器. 如果移除某个 zone cut, 所有曾被其遮蔽的 parent zone 名称将再次对查询可见. (这是对 [RFC1034] 的澄清.)
7.19. 如果某服务器同时对某个 zone 及其 child zone 具权威性, 那么对于二者之间 zone cut 处名称的查询, 将只使用 child zone 中的数据进行权威回答. (这是对 [RFC1034] 的澄清.)
7.20. 使用 SOA RR 进行更新排序存在问题, 因为无法知道某个 zone 的 NS RR 中哪一个代表 primary master, 并且如果 zone slave 的 SOA.REFRESH 定时器自 primary master 上次变更该 zone 以来尚未到期, 这些 slave 可能是过时的. 我们建议, 需要有序更新的 zone 只使用实现了 NOTIFY (参见 [RFC1996]) 和 IXFR (参见 [RFC1995]) 的服务器. 当 client 在尝试有序更新时收到先决条件错误, 它应在一个随机延迟周期后简单重试, 以便让 zone 达到稳定状态.