传统互联网模型中，DNS 仅负责将服务名解析为 IP 地址，后续连接质量完全由 BGP 决定的网络路径承担；但随着服务节点大规模复制部署，如何为每个请求选择“最优”节点成为新难题。Cloudflare 在 AusNOG 2023 分享指出，DNS 调度正逐步接管原本属于 BGP 的流量工程职能，成为服务交付的关键控制面。
经典模型与复制服务的转折：
互联网早期（约 2000 年前）采用单点服务模式，用户经 DNS 获得 IP 后直接建立传输连接，路径优劣由 BGP 的选路结果决定，BGP 既是可达性协议也是流量工程协议。近十年来，服务复制让每个节点更贴近用户集群，问题随之转移：面对同一请求，多个节点可用时，由谁、以何种方式判定“最佳”实例？这不再是纯网络层问题，而是服务交付层的新决策域。
“最优”度量的多维困境：
给定客户端到两个实例的两条路径，如何比较？最短路径的距离单位是跳数、物理直线距离、还是传输时延？是否应优先高带宽路径而非低时延路径？这些指标互不兼容，且主机与服务难以在连接前完成全路径测量。原文未给出具体数据，但明确指出：业界至今未能就通用“最优”度量达成共识，导致选址逻辑在不同平台间差异巨大。
Anycast 将决策权交还 BGP：
首种应对方案是 Anycast，直接利用 BGP 的多路径收敛特性，让路由协议自行把流量引向拓扑最近的实例。这种做法把选址复杂度下沉到网络层，避免了应用层自行度量，但也将控制粒度限制在 BGP 能感知的拓扑距离内，无法感知实例负载、健康状态或链路质量等服务级指标。
对运维工程师而言，DNS 与 BGP 职责边界的模糊意味着排障视角必须从单一协议扩展到解析与路由的联动链路；部署 Anycast 或 DNS 调度时，需明确谁在决策、依据何种度量，才能在故障时快速定位是解析层还是转发层失效。
原文: APNIC Blog（2023-09-22）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog