DNS HTTPS/SVCB 记录导致访问异常：优先级、mandatory、ALPN 与地址提示排查

先确认查询的是 HTTPS 还是 SVCB

HTTPS RR 是为 HTTP/HTTPS 映射定义的 SVCB-compatible 类型，普通服务发现可能使用 SVCB。两者线格式相近，但查询名称与协议映射不同。

用目标客户端实际查询的 owner name 验证，不要只查 _https._tcp 或凭 SRV 经验猜名称。记录权威、递归和客户端三处的应答。

保存完整 RRset 而不是一行摘要

记录 owner、TTL、类型、SvcPriority、TargetName、所有 SvcParams、DNSSEC 状态和应答来源。多条 ServiceMode 记录共同构成候选集，只复制第一条会丢失选择逻辑。

同时查询目标名的 A/AAAA，并抓取客户端最终连接 IP、端口、ALPN 与 SNI。DNS 正确不代表端点已部署对应服务。

区分 AliasMode 与 ServiceMode

RFC 9460 定义优先级 0 为 AliasMode，非零为 ServiceMode。AliasMode 用于把服务绑定指向另一个名称；ServiceMode 则描述具体替代端点和参数。

把优先级 0 的记录写入 ServiceMode 参数，或在一个 RRset 中混用不符合要求的组合，可能被视为无效。先检查区文件的逻辑模式，不要只确认语法能加载。

AliasMode 不是普通 CNAME

HTTPS/SVCB AliasMode 能支持 apex 等 CNAME 难以使用的场景，但它有自己的处理规则。不要同时依赖互相冲突的 CNAME、HTTPS AliasMode 和应用层跳转。

沿 AliasMode 链逐跳查询，检查循环、目标 NXDOMAIN、DNSSEC 验证和链长。任何一跳不一致都可能造成客户端差异。

ServiceMode 优先级数值越小越优先

多个 ServiceMode 记录按 SvcPriority 组织候选，较小非零值优先。优先记录若指向尚未上线的端点，支持 HTTPS RR 的客户端可能先失败，而不支持的旧客户端继续使用原始 A/AAAA，形成“新浏览器坏、旧客户端正常”。

发布前确保每个较优先端点真实可用，或用 canary 解析范围逐步上线。不要把未部署目标放在最高优先级等待以后启用。

TargetName 的点号语义要准确

TargetName 可以是域名；区文件中缺少末尾点可能被当作相对名并自动追加 zone，最终指向错误名称。使用 dig 查看权威服务器返回的完整规范化名称。

特殊的 . 有协议定义的含义，不能随意当作“空值”。以 RFC 和 DNS 服务商界面实际表示为准。

目标名的证书必须匹配原始来源

HTTPS RR 改变连接端点，不会自动改变用户访问的 HTTPS origin。TLS 证书、SNI 和 HTTP Host 仍需符合协议映射与原始域名要求。

若 TargetName 指向 CDN 名称，只给 CDN 名称签证书而未覆盖原始域名，会出现证书错误。通过真实客户端握手验证，不能只 curl 目标名本身。

mandatory 列出的键必须同时存在

RFC 9460 要求 mandatory 中列出的每个 key 也出现在同一 RR 的 SvcParams。列出不存在的 key 会使记录不自洽。

mandatory 也不能把自身列入列表。检查区文件生成器是否用数字与名称混合后重复、遗漏或错误排序。

未知 mandatory 参数会淘汰整条记录

客户端若不支持一条记录声明为 mandatory 的参数，应忽略该 ServiceMode 记录，而不是忽略单个参数后继续连接。若所有候选都被淘汰，客户端的回退行为与协议映射、实现有关。

新增私有或新注册 key 时，先测主流客户端覆盖率。不要为了“强制启用新功能”把非必要参数全部放入 mandatory。

port 与 no-default-alpn 自动具有强制性

RFC 9460 将 port 和 no-default-alpn 视为 automatically mandatory。客户端不理解时不能假装忽略，否则会连接错误端点或协议。

配置非标准端口前确认防火墙、负载均衡、证书服务和客户端 bad-port 策略。端口在 DNS 中发布不等于网络已放行。

alpn 必须与服务器真实能力一致

alpn 声明端点提供的应用协议，例如 h2 或 h3。客户端会与自身支持集合取交集。DNS 声明 h3，但 UDP/QUIC 未开放，或服务器 TLS 没有协商 h2，会造成连接失败或延迟回退。

分别测试 TCP/TLS 与 QUIC，记录握手协商出的 ALPN。不要仅检查 DNS 文本里写了什么。

no-default-alpn 不能单独出现

RFC 9460 规定存在 no-default-alpn 时还必须有 alpn，且它的值应为空。错误地写成带值参数，或只关闭默认协议而不提供替代集合，会使记录不自洽或无可用协议。

只有确实不提供默认 HTTP/1.1 等协议时才使用它。普通兼容站点通常不需要为追求“现代化”关闭默认集合。

ipv4hint 与 ipv6hint 只是提示

地址 hint 用于降低额外查询延迟，客户端仍可查询 TargetName 的 A/AAAA，并可能优先使用正式地址结果。hint 与 A/AAAA 不一致时，不同客户端、缓存和网络会选择不同地址。

把 hint 纳入与源站地址相同的自动更新流程，避免扩容、CDN 切换后遗留旧 IP。不要把 hint 当成替代 A/AAAA 的唯一权威地址。

单边 ipv4hint 会影响 IPv6/NAT64 体验

RFC 9460 建议使用 ipv4hint 时也提供 ipv6hint 以改善性能。只有 IPv4 hint 的记录在 IPv6-only/NAT64 网络上可能需要合成、忽略 hint 或等待 AAAA，造成与双栈网络不同的延迟。

在 IPv4-only、双栈和 IPv6-only/NAT64 环境分别测试。不能只用办公网络证明全球客户端正常。

hint 地址必须真的服务目标 origin

即使地址语法正确，目标 IP 也必须接受原始 SNI/Host、证书和所声明协议。把后端私网地址、健康检查地址或另一租户 CDN IP 写成 hint，会产生 TLS 或 HTTP 错误。

从外部网络直接对 hint IP 进行带正确 SNI 的受控测试，并检查 Anycast/地域路由。

SvcParamKey 不可重复

同一记录中每个 SvcParamKey 只能出现一次，mandatory 列表也不能重复。某些 DNS 控制台可能允许保存文本，却在权威输出或签名阶段产生不同结果。

对最终权威 wire response 做解析校验，不要只看管理页面表单。

参数顺序与线格式由实现规范化

区文件展示顺序不等于 wire format；SvcParamKey 在线格式有严格排序要求。成熟权威服务器会编码，但自研签名器、动态更新工具或代理可能生成畸形应答。

用至少两个独立解析器检查权威响应，并观察 FORMERR、SERVFAIL 或记录被忽略。不要手工拼接未知二进制 RDATA 上线。

DNSSEC 会放大不一致问题

修改 HTTPS/SVCB RRset 后需要生成正确 RRSIG。多权威节点更新不同步、签名过期或 NSEC/NSEC3 否定证明不一致，会让验证解析器 SERVFAIL，而不验证的客户端仍返回数据。

分别向每台权威查询并使用验证解析器检查。不要通过关闭 DNSSEC 作为长期修复，应回滚或重新签名正确 RRset。

递归缓存会保留旧候选集

HTTPS RR、TargetName A/AAAA 和 AliasMode 各跳可能有不同 TTL。修改端点后，递归缓存可能组合新旧数据，引起阶段性失败。

变更前规划 TTL，发布后按各 RRset 的最大缓存窗口观察。清本机缓存不能代表公共递归已经更新。

客户端支持差异要纳入测试

不支持 HTTPS/SVCB 的客户端通常继续走传统地址解析；支持但参数集合不同的客户端会选择不同候选。对浏览器、操作系统 resolver、命令行工具和嵌入式客户端分别记录能力。

不要只用 dig 证明用户链路。DNS 工具显示记录，不代表应用实现会采用它。

浏览器安全升级可能改变现象

HTTPS RR 的存在可向客户端表达安全连接相关信息。若原站只提供 HTTP、HTTPS 配置不完整或 443 被阻断，支持客户端可能与旧客户端表现不同。

上线记录前先确保原始 origin 的 HTTPS、证书、重定向和资源均可用。不要用 DNS 记录替代完整 HTTPS 部署。

CDN 与 DNS 自动生成器要统一来源

CDN 可能自动生成 HTTPS RR 与地址 hints，同时用户又在权威区手工维护另一组，导致重复或冲突候选。确认记录由 DNS 服务商、CDN还是 IaC 管理。

选择单一权威配置源，保留变更审计和回滚。不要在控制台与 GitOps 两边同时修改。

最小化回退测试

建立三组测试：无 HTTPS RR 的传统 A/AAAA 基线；只含一个无额外参数的 ServiceMode；逐项加入 alpn、port、hints 和 mandatory。每一步记录 DNS、握手、HTTP 和失败时间。

发现问题时回到最后通过的最小记录，而不是把所有参数一次性改写。

发布与回滚顺序

先部署并验证目标端点、证书、协议和防火墙，再发布低风险 DNS 记录。使用小流量解析、内部域名或受控客户端做 canary，并准备删除/恢复原 RRset 的原子回滚。

回滚后仍需等待 TTL，并继续监控旧候选连接。不能看到控制台已删除就立即宣布恢复。

修复后的验收标准

验收应证明：AliasMode/ServiceMode 合法；优先级和 TargetName 正确；mandatory 键存在且客户端支持；ALPN 与真实握手一致；port 可达；hints 与 A/AAAA 和服务一致；证书覆盖原始 origin；每台权威与 DNSSEC 正常；不同网络和客户端均能成功或按预期回退。

报告保存 RRset、TTL、哈希、客户端矩阵和脱敏连接结果，不保存私钥、控制台 Token 或内部地址清单。

常见问题

HTTPS 记录与普通 A/AAAA 有什么关系？

HTTPS RR 提供替代端点和连接参数；客户端仍可能查询 TargetName 的 A/AAAA，并可能忽略不支持或无效的 HTTPS 候选。

SvcPriority 为 0 和 1 有什么区别？

0 表示 AliasMode；非零表示 ServiceMode。两种模式的结构和处理规则不同，不能只当作普通权重。

mandatory 里写了未知 key 会怎样？

不支持该 mandatory key 的客户端应忽略整条 ServiceMode 记录，而不是只忽略那个参数。

ipv4hint 可以替代 A 记录吗？

不应这样理解。它是地址提示；客户端仍可查询 TargetName 的 A/AAAA，并可能以正式查询结果更新连接选择。

为什么新浏览器失败而旧客户端正常？

新浏览器可能采用 HTTPS RR 指向错误端点、协议或端口；旧客户端不支持该记录，继续使用传统 A/AAAA 路径。

来源资料

• RFC 9460 SVCB 与 HTTPS RR：https://www.rfc-editor.org/rfc/rfc9460.html
• RFC 9461 DNS 服务的 SVCB 映射：https://www.rfc-editor.org/rfc/rfc9461.html
• RFC 9462 Designated Resolver Discovery：https://www.rfc-editor.org/rfc/rfc9462.html
• IANA DNS SVCB 参数注册表：https://www.iana.org/assignments/dns-svcb/