摘要

  • 较小的 SVCB 优先级，只能在客户端确实可用的记录之间表示偏好。客户端先排除格式错误、自相矛盾或不兼容的记录；一个无法识别的必需参数，就足以让表面上的第一选择失去资格。
  • AliasMode 委托的是服务发现，不会改变原始服务身份；ServiceMode 把端点与参数绑定成候选方案。地址提示、DNS 中的 ALPN 和经认证的 DNS 回答都只是输入，真正的证明还要经过 A/AAAA、原始名称的 TLS 校验、实际协商协议和应用响应。

第一名没有进入候选集

设想一个源站发布两条 HTTPS ServiceMode 记录。优先级 1 指向新边缘，并带有一个客户端不认识、同时被标为 mandatory 的实验参数；优先级 2 指向旧边缘，参数均被该客户端理解。运维看板把第一条称为“首选端点”。

对这个客户端而言，它根本不是可选端点。RFC 9460 要求客户端忽略包含未知必需键的记录，于是它转而评估优先级 2，并可能成功连接。优先级规则没有被颠倒；真正发生的是资格审查先于排序。

这个分析场景不指向任何特定浏览器或 CDN。它揭示一种常见的权力误读：把发布顺序当成已执行命令。域名控制者可以描述候选连接方案，却不能凭 DNS 让所有客户端获得解析能力，也不能让网络放行端口、让服务器接受宣告的协议，或让证书自动证明原始服务身份。

两种模式分配不同权力

RFC 9460 定义 SVCB 类型 64 和与之兼容的 HTTPS 类型 65。每条记录包含优先级、目标名称与可选服务参数。优先级为零表示 AliasMode，非零表示 ServiceMode。

AliasMode 把某项服务的发现委托给另一个名称，尤其解决区顶点不能普通使用 CNAME 的问题。它只影响相应的 SVCB 兼容服务，不会把该名称下所有 DNS 记录一并改写；其中出现的参数也会被忽略。实现还必须限制别名链长度，否则委托会变成无法终止的循环。

别名尤其不会改写 origin。HTTPS 客户端即使沿别名到达服务商目标，TLS SNI、证书参考名和 HTTP Host 或 :authority 仍是原始服务名。域名控制者委托的是到达服务的路径，不是把读者身份迁移到服务商域名。

ServiceMode 则把 TargetName、端口、协议集合、地址提示以及扩展参数绑定为一个候选方案。多 CDN 环境可以让每个供应商发布与自身能力一致的组合，避免把供应商甲的地址与供应商乙的参数拼在一起。但记录仍是交给兼容客户端执行的提案，不是端点在线或部署一致的证明。

先拒绝，再排序

选择之前有数道门槛。线格式错误可能让整个 RRset 被拒绝并回退到非 SVCB 路径；已识别参数彼此冲突，会使单条记录不自洽；普通未知参数通常可忽略，但未知必需参数会使该记录不兼容。

只有剩余记录才进入优先级排序。数值较小者先试，同一优先级内部随机打散，以实现均衡选择，而不是 SRV 那种由发布者给出的权重。因此，小数字的含义是“优先使用这个兼容方案”，绝不是“无条件服从这个目标”。

mandatory 也不是对服务器的强制命令。它声明：若客户端忽略某个键，这条记录就无法正确工作。客户端要么理解全部必需条件，要么排除该记录。列表中的键必须同时出现在该记录中，而且不能把 mandatory 自己列入。

对 HTTPS 而言，port 和 no-default-alpn 一旦出现就自动成为必需项。忽略端口会把流量送到错误监听器；忽略对默认协议的排除，则可能协商端点并未提供的协议。这些最小规则防止扩展性滑向静默误解。

宣告协议不是协商协议

alpn 参数描述候选端点宣称提供的协议套件，客户端可以据此准备 HTTP/2 或 HTTP/3 连接，减少先访问默认端点的往返。但 DNS 列表不是握手结果。实际 ALPN 仍由客户端与服务器在 TLS 中协商。

区域节点可能落后，防火墙可能阻断 UDP，DNS 也可能领先于边缘部署。调查必须同时保存 DNS 收到的 ALPN 集合与握手实际选择值。port 亦然：DNS 可以指定端口，客户端安全策略和中间网络仍可拒绝它。

提示可以是临时的

ipv4hint 与 ipv6hint 用来降低没有目标地址时的等待，并不替代 TargetName 的 A/AAAA。当地址答案在本地可用时，客户端应忽略提示；否则仍要查询目标，并把权威地址答案用于后续连接。

这种设计允许乐观启动，却不把性能优化升级为永久路由权威。客户端可能先连接提示地址，再转向 A/AAAA；地理调度也可能给出不同集合。审计若只写“连接到某 IP”，就丢失了决定性上下文：地址究竟来自提示、Answer、Additional、缓存，还是代理侧解析？

每次绕行都保留原始名称

RFC 9460 允许 SVCB/HTTPS 通过不可信 DNS 渠道传输。DNSSEC 可以证明 RRset 的来源与完整性，但不是强制条件，因此安全性不能只押在 DNS 回答上。

替代端点仍需证明自己有权服务原始名称。HTTPS 客户端发送原始名称的 SNI，以该名称校验证书，并在 HTTP 层保留原始 authority。只对供应商 TargetName 有效的证书仍然不够，即便别名由域名持有者发布、DNSSEC 也完全通过。

这构成清晰的权力边界：DNS 管发现，TLS 身份规则管端点认证，ALPN 记录双方真正协商出的协议，HTTP 记录该 origin 的请求与响应。任何一步都不能替其他步骤作证。

回退本身是一项政策

HTTP 早于 SVCB，因此现有协议的客户端一般允许在 SVCB 缺失或不可用时走普通连接路径。这有利于自愿采用，却形成降级边界。若受保护的 SVCB 查询因认证错误、SERVFAIL、传输失败或超时而失败，客户端应停止，而不是悄悄抛弃受保护参数。普通不受认证的 DNS 失败，则可按本地政策视为致命或非致命。

多供应商环境还会产生分裂证据：CNAME、HTTPS 与 A/AAAA 是独立查询，可能在不同时间命中不同 CDN 状态。客户端必须获取所选 TargetName 对应的地址。提示可以缩短等待，但无法证明所有 RRset 属于同一发布代次。

运行代码优先原则在这里不是口号。区域文件的声明之所以有价值，是因为兼容实现实际解释它。共同层只应规定互操作所需的最小约束，不应让 DNS 发布者统治每个客户端的回退，也不应让客户端供应商改写域名持有者的服务政策。

来源