摘要

  • DNS SRV 允许一个域针对特定服务与传输协议，发布多个目标、各自端口、主备层级，以及同一层级内的静态选择倾向。
  • Priority 与 Weight 不是同一种负载策略：客户端先尝试数值最低且可达的优先级；只有在同一优先级内部，才按权重随机排列目标。
  • SRV 只提供发现证据。客户端仍须把规范目标解析成地址，连接指定传输与端口，并验证真正响应的应用服务。

服务位置曾藏在客户端的常识里

早期 DNS 擅长回答“这个主机名对应哪个地址”。应用程序往往自行补齐其余部分：使用约定端口、读取 /etc/services，或者把管理员写进文档的准确服务器名当作入口。服务名、承载主机、端口和故障切换因此被压缩成一个习惯。

1996 年 10 月的 RFC 2052 提出实验性 SRV 记录，换了一个问题：某个域里的某项服务在哪里？答案可以列出多个目标，并携带优先级、权重与端口。

2000 年 2 月，RFC 2782 以 Proposed Standard 取代 RFC 2052。它希望管理员能低摩擦地在主机之间移动服务、让多个服务器共同承载一个域，并明确区分主服务器与备用服务器。IANA 至今把 SRV 登记为 DNS 类型 33，Server Selection。

查询名拆开了服务、传输与管辖域

在 example.com 寻找 TCP 上的 LDAP 时，支持 SRV 的客户端查询 _ldap._tcp.example.com。左侧两个标签分别声明服务与传输，其余名称界定服务所属的管理域。

RFC 2782 取代实验性文本时，为服务与协议标签加上了下划线。其目的不是装饰，而是降低服务元数据与自然存在的普通 DNS 标签发生碰撞的概率；新版同时澄清了权重算法。

后来的注册制度继续收窄命名权。RFC 6335 统一服务名与传输端口的注册流程。服务名即使没有分配固定端口，也可供 SRV 等发现机制使用。注册负责避免重名，不等于 IANA 为产品或流量背书。

2019 年，RFC 8552 建立“带下划线且全局作用域的 DNS 节点名”注册表，避免不同规范在同一全局命名空间内独立占用相同标签。RFC 8553 把使用 SRV 的规范接入这套制度，同时保存既有软件与运行实践。最初的防碰撞约定由此获得可审计的分配边界。

四个字段表达四类不同证据

SRV 的数据部分包含 Priority、Weight、Port 和 Target。若把它们统称为“DNS 负载均衡”，就会抹掉其中最重要的界线。

Priority 划分故障切换层级。客户端必须先尝试数值最低且能够到达的目标。数值更高的记录不是流量较少的同级服务器，而是低层级不可用后才进入选择面的备用层。

Weight 只比较相同 Priority 的记录。客户端累计权重、抽取均匀随机数、用累加区间选出一个目标，移除后再重复，最终生成尝试顺序。域发布相对倾向，顺序却由客户端产生。若同组存在正权重，零权重也不是绝对禁用；规范算法仍赋予它极小概率。

RFC 2782 的示例把两个目标置于优先级 0，权重分别为 1 与 3。经过大量彼此独立的首次选择，后者应趋向取得约四分之三；优先级 1 的两个目标只有在前一组无法服务时才出现。单次查询和单个用户从未获得精确 3:1 的承诺。

Weight 更不是实时负载遥测。CPU、队列与延迟变化得比 DNS 缓存快。为了追逐负载而大幅缩短 TTL，会增加 DNS 请求、削弱缓存并降低可靠性。这个字段表达的是相对稳定的容量差异，例如服务器性能或网络连接质量。

Port 则把另一项知识从客户端移入 DNS。它通常可以是已注册端口，却不必如此。运营者能把服务移出默认或 Unix 特权端口，而无需先修改每台客户端上的本地表。

Target 指向具体主机，但终点规则很严格：该名称必须拥有地址记录，不得是别名。客户端可使用 Additional 区返回的 A/AAAA，也可另行查询。SRV 能把发现引向地址解析，却不能在目标处再隐藏 CNAME 或 DNAME 链。

“没有答案”不等于“明确不提供”

若唯一 Target 是根标签 .，含义是该域明确不提供这项服务。它不否认域本身存在，也不否认其他服务，只对这一服务与传输组合给出积极、有限的拒绝。

没有可用 SRV 时，原始流程采取另一条路：查询域本身的地址并尝试旧约定。RFC 2782 直言，指望所有客户端在第一条 SRV 发布后同时升级并不现实。管理员应为旧客户端保留合理地址，但不应把纯备用主机放入普通地址集合，让旧软件把它误当主机。

兼容路径因此成为运营决策。保留它能延续访问，也可能绕过 SRV 的优先级与端口；删除它能让新策略一致，却可能切断不会 SRV 的软件。协议没有假装这笔迁移成本不存在。

发布候选目标并未证明服务成立

合规客户端需要解析完整 RRset，按 Priority 分组，在组内加权排序，解析每个 Target 的地址，再尝试传输、地址与端口组合。每一步都有独立失败条件。

即使 DNS 答案经过真实性保护，它最多证明相关 DNS 权威发布了什么。它不证明端口上的进程健康，不证明应用身份正确，不证明目标主机同意被引用，也不证明不同目标由同一组织控制。

表达能力增加，也扩大了错误发现语句的作用面。DNS 欺骗者除伪造主机与地址外，还能给出错误端口。一个域可以把第三方主机列为目标并向其导入无意流量。细粒度端口让过滤更困难，也迫使 DNS 与网络运营团队更紧密协作。

SRV 的适用性同样不能由域管理员单方面创造。应用协议规范必须明确允许 SRV、定义服务符号名并处理安全问题。协议规定这类查询是否有意义；域权威填写候选集合；客户端执行选择；目标仍要通过实际传输与应用协议证明自己。

来源与证据上限

本文只使用实验性 RFC 2052、标准轨 RFC 2782、服务名程序 RFC 6335、下划线注册制度 RFC 8552 及其 RFC 8553 更新，以及现行 IANA DNS 参数表。这些来源证明语义和规范演化，不证明当今部署率、延迟收益、权重准确度、实现合规或任何在线服务的健康状态。

SRV 的历史价值恰在这种有限性：稳定服务名不再被绑死在一台主机和一个默认端口上，但这个名字也从未获得替代连接与应用验证的权力。