摘要

  • RFC 1794 描述了 1995 年一项设计讨论：让 DNS 地址顺序反映服务器负载变化，而不修改 DNS 协议。
  • 权威服务器可以表达偏好；缓存、辅助服务器的刷新节奏以及客户端本地排序，则使这种偏好无法成为强制的目标分配。

有序答案不是连接指令

一个名称可以对应几台功能相同的主机。若其中一台较空闲，管理者自然希望它排在前面。但 DNS 传回的是资源记录，不负责替应用建立连接。RFC 1794 把这条界线放在讨论中心：地址次序可以有参考价值，却不保证客户端按次序使用。

这份文件发表于 1995 年 4 月，类别是 Informational。它明确说自己不制定任何 Internet 标准。作者想记录 DNS 工作组的一次探索和当时考虑过的方案，也坦承历史叙述可能缺少片段。因此，它能证明当时有人如何讨论设计问题，不能单凭它推断某种方案部署了多少、效果如何。

从轮换地址到读取负载

RFC 作者把早期尝试追溯到约 1986 年：BIND 的一些改版会改变地址记录的排列。他举出 Bryan Beecher 的 Shuffle Address 修改，以及 Marshall Rose 的 Round Robin 代码，认为两者可能传播较广。这是作者的回顾性判断，不是独立统计。

轮换能够改变哪条地址先出现，却不查看每台主机实际有多忙。RFC 1794 将其与 TGV 的做法相对照：据文中记载，Matt Madison 利用 VMS 专有功能检查系统负载，再按从轻到重排列 A 记录。这个办法更接近实时状态，但依赖特定操作系统，也需要更改 DNS 记录处理。前一种做法容易兼容，却不看负载；后一种更敏感，却难以通用。

兼容性让动态逻辑换了位置

工作组列出的目标包括：与既有 DNS 向后兼容、信息能够频繁变化、一次返回多个地址、兼顾其他资源记录、容纳不同负载定义，并且计算要快。文中把五分钟称为正常的更新时间，也设想过六十秒的间隔；这不是实测服务指标。多地址的用意，是让首选主机在 TTL 到期前出故障时仍有其他候选，并不等于保证切换成功。

修改协议或增加记录类型，会让庞大的既有实现面临兼容问题。RFC 记载 Rob Austein 提出另一条路：改进区域传送程序。程序先取得负载信息，再重新排列区域数据，之后交给名称服务器；DNS 报文格式可以不变。动态变化发生在区域准备阶段，实时查询仍走熟悉的协议。

复杂性只是转移了。区域传送用于更新辅助名称服务器，主服务器不会通过传送自身区域来回答查询。若某个子区域变化很快，辅助服务器的刷新间隔就很重要；返回给解析器的 TTL 也要足够短，新的次序才可能较快传播。排序运算还必须赶在它所依据的信息过时之前结束。源头上刚算出的次序，抵达用户时可能已经留在缓存里一段时间。

最后的决定留给了客户端

RFC 1794 指出 DNS 不保证响应中的记录顺序。作者称其具有可预测性：客户端可能反复看到同一排列，但也能按本地规则重新排序，例如使用 sortlist。区域传送程序无法预知远端的这种选择。返回多个地址，也不能证明客户端会逐个尝试、备选主机仍健康，或应用请求最终完成。

这段历史并不是 DNS 变成了流量分配器，而是设计者承认不同环节各自掌握的控制权。运营方可以决定如何计算并发布偏好；辅助服务器与缓存决定它何时传播；客户端决定实际尝试哪个地址。RFC 1794 记录的是在这些边界内工作的办法，不是部署规模或运行效果的证明。

来源