解析链路的风险在哪
传统 DNS 查询走明文 UDP 53，客户端只认第一个回来的应答，链路上任何一环都能动手脚：本地路由器或运营商递归被替换成会返广告的服务器、递归缓存被投毒返回错误地址、域名解析被人改动后指向别人的服务器。表现是不同网络解析结果不一致、部分地区打不开或跳到陌生页面。加固思路分两层：解析侧用可信递归、HTTPDNS 与 DNSSEC 提高结果可信度，传输侧用 HTTPS 证书保证即便解析被改也拿不到内容。
基本信息
| 协议与端口 | DNS 主用 UDP 53，区域传送与大数据包回退 TCP 53 |
|---|---|
| 常见风险 | 递归被劫持、缓存投毒、解析记录被篡改、DHCP 下发恶意 DNS |
| 检测手段 | 多递归对照、递归与 DoH 对照、证书链校验、解析结果纳入监控 |
| 加固手段 | 启用 HTTPS 与证书校验、接入 HTTPDNS、按支持情况启用 DNSSEC |
| 适用范围 | DNSSEC 需注册局与注册商同时支持，未普及时不能作为唯一手段 |
典型使用场景
- 用户投诉「打不开」但本地正常：用多递归对照判断是否为区域性劫持
- 移动端接入优化：用 HTTPDNS 绕过本地递归，避免被劫持到错误节点
- 域名接管排查：解析被改动后，需要快速确认权威记录与各递归的返回差异
- 日常监控基线：把关键域名的解析结果与 TTL 纳入巡检，异常时先看解析
- 新域名上线前检查：确认权威服务器、TTL 与 DNSSEC 状态符合预期
多递归对照与证书校验
多递归对照与证书校验
for ns in 223.5.5.5 8.8.8.8 1.1.1.1; do echo -n "$ns -> "; dig +short www.example.com @$ns; done # 三个递归同时对照
curl -s 'https://dns.google/resolve?name=www.example.com&type=A' # DoH 结果做交叉验证
dig +dnssec www.example.com @8.8.8.8 | grep -E 'flags|RRSIG' # 看 AD 标志与签名记录
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates # 确认证书主体与有效期，发现跳转页的第一手段异常表现与确认方法
| 表现 | 可能原因 | 确认方法 |
|---|---|---|
| 不同网络解析结果不同 | 本地递归被劫持或缓存不一致 | 多递归对照，看权威记录是否一致 |
| 解析到陌生地址且出现广告页 | 递归返回被篡改 | 对比 DoH 结果与证书主体 |
| 证书告警或主体不匹配 | 链路中间被替换为代理页 | openssl 查看 issuer 与 SAN |
| TTL 突然变短或变长 | 记录被修改或缓存被投毒 | 连续多次查询看返回值变化 |
| 仅移动网络异常 | 终端 DHCP 下发的 DNS 被替换 | 检查终端 DNS 设置与 HTTPDNS 接入情况 |
HTTPS 与证书校验是缓解劫持后果的底座：即使解析被改，证书主体不匹配也会直接告警，不会静默把用户交给对方。解析侧与传输侧要一起做，只做其中一层都留有缺口。
DNSSEC 通过签名验证应答来源，但需要域名注册局与注册商同时支持，部分后缀尚未启用；未启用时应以 HTTPDNS 加证书校验为主要防线。