必须有的四个
- 解析成功率 —— 分域名统计，否则个别域名的持续失败会被平均值淹掉
- 解析延迟分位数 —— 看 p95/p99，不看均值；均值会掩盖尾部问题
- 上游可达性 —— 按上游分别统计，用于判断是否需要摘除某台
- 加密协议分布 —— 有多少查询真的走了 DoT/DoH，用于发现「悄悄回退到明文」
OPERATIONS
排错与运维
「打不开」不是一种故障。先花三十秒判断它属于哪一类，再动手 —— 跳过这一步是排查慢下来的主要原因。
第一步：把「打不开」分成四类
用一条命令就能分流。这一步被跳过时，最常见的后果是花很久去查一个根本没问题的地方。
dig example.com +short 或 nslookup example.com。
关键判断：这里问的是系统当前生效的解析器，而不是你手动指定的那个。 所以如果
dig 有结果、而浏览器仍然打不开，问题多半不在 DNS ——
这能省掉大量在错误方向上花的时间。
确认是解析问题后：按这个顺序查
顺序本身就是经验 —— 每往前一步都能缩小范围，跳步会导致反复回到起点。
① 先看当前生效的解析器是谁
很多「配了没生效」其实是一开始在查错误的解析器 —— 你以为在问 A，实际系统在问 B。
# Linux
resolvectl status
# macOS
scutil --dns | head -20
# Windows
netsh dns show encryption
ipconfig /all | findstr "DNS Servers"把这里显示的解析器地址，与你打算配置的那个做比对。不一致就先解决这个，其余排查都没有意义。
② 确认查询到底走没走加密
这一步回答「配置生效了吗」，而不是「解析通不通」。两者是不同的问题。
sudo tcpdump -i any -n 'port 53 or port 853 or port 443'保持抓包，另开一个窗口访问几个网站，然后看结果：
- 出现 53 → 仍是明文，加密没生效（或只对部分应用生效）
- 出现 853/tcp → DoT；853/udp → DoQ
- 出现指向解析器 IP 的 443 → DoH 或 DoH3
若只有部分应用走加密，多半是「只在浏览器里配了」。覆盖面问题见客户端配置。
③ 区分是「解析器不可达」还是「解析器不回答案」
两者现象都是「没结果」，但原因完全不同。
# 直接问加密解析器（绕过系统配置）
dig @1.1.1.1 example.com +short +time=3
# 换一个已知可用的解析器做对照
dig @9.9.9.9 example.com +short +time=3如果第一个超时、第二个正常，说明问题在你配置的那个解析器（可达性或证书）。 两个都超时，则更可能是本地网络或防火墙问题。
④ 看是否为证书校验失败（严格模式专属）
严格模式（如 systemd-resolved 的 DNSOverTLS=yes、Android 的私人 DNS）会校验 TLS 证书。证书对不上时表现为「完全没有回答」，而不是报错。
# 手工验证解析器的 TLS 证书是否正常
openssl s_client -connect 1.1.1.1:853 -servername cloudflare-dns.com </dev/null常见的两个原因：配置里只填了 IP 没填主机名（无法校验），或系统时间偏差过大（证书被判为未生效）。
⑤ 最后才怀疑缓存与 TTL
「刚改完记录却不生效」几乎都是 TTL 还没过，而不是配置错误。这一点在部署实践里也提到过。
# 直接问权威服务器，绕开所有缓存
dig @ns1.example.com example.com +norecurse
# 看 TTL 还剩多少
dig example.com如果权威返回的是新值、本地解析器返回的是旧值，那就是缓存 —— 等，或者换个解析器验证，不要改配置。
常见故障模式对照表
按「现象」查，比按「原因」查更接近实际排障时的处境。
| 现象 | 多半是 | 一步确认 |
|---|---|---|
| 配置后完全无法解析，也无报错 | 严格模式下证书校验失败 | 用 openssl s_client 手工验证书 |
浏览器能上，命令行 curl 不行 |
加密只配在浏览器层 | tcpdump 看 curl 是否发了 53 端口 |
| 内网域名解析不到，外网正常 | 加密解析器不认识内部域名 | 对内部域名做 dig，看是 NXDOMAIN 还是超时 |
| 偶发超时，重试就好 | 多个上游之间结果不一致，或某个上游抖动 | 分别对每个上游单独 dig 多次 |
| 换了网络之后加密失效 | 配置绑定到特定网卡（Windows 常见） | 换网络后重跑一次抓包 |
| 解析耗时突然翻倍 | 解析器变远，或缓存被绕过 | 对同一域名连续 dig，对比首次与后续耗时 |
要盯哪些指标
加密 DNS 的问题往往不是「坏了」，而是「变慢了」或「偶发失败」—— 没有指标就只能等投诉。
两个容易被忽略的
- 证书到期时间 —— 严格模式下一旦过期，解析会整体不可用，而不是逐个失败。这是最典型的「突然全站打不开」原因
- 配置漂移 —— 定期核对生效配置与预期是否一致。手工改过的机器迟早会和文档不一致
第二项听起来像流程问题，但它带来的故障和硬件故障一样真实，而且更难定位 —— 因为「没人改过」会让排查方向偏掉。建议把生效配置纳入定期快照比对。
接下来
单机排错之后，是组织层面的治理与风险边界。