把 DNS 装进 TLS 里
明文 DNS 会被中间人看到域名并可能被篡改。DoT 把 DNS 包进 TLS 走专用端口 853，识别容易；DoH 走 443 并伪装成普通 HTTPS 请求，难以区分；DoQ 用 QUIC 走 UDP 853，延迟更低但部署尚少。三者都能防窃听与篡改，代价是本机抓包看不到明文域名，排障与内网审计的可见性下降。
基本信息
| DoT | TCP 853 上承载 TLS，遵循 RFC 7858 |
|---|---|
| DoH | HTTPS 443 上的普通请求，遵循 RFC 8484 |
| DoQ | UDP 853 上基于 QUIC，遵循 RFC 9250 |
| 端点格式 | DoH 必须带路径，如 https 加域名加 /dns-query |
| 影响面 | 加密后中间设备无法按域名做策略，企业出口可能限制这类流量 |
三种方案对照
| 方案 | 端口 | 特点 |
|---|---|---|
| DoT | TCP 853（TLS） | 专用端口，易识别也易封禁 |
| DoH | TCP 443（HTTPS） | 与网页流量同端口，难以区分 |
| DoQ | UDP 853（QUIC） | 连接建立快、支持多路复用，部署较少 |
| 明文 DNS | UDP 与 TCP 53 | 可被抓包与按域名审计，但无隐私 |
| DNSSEC | 协议不变 | 只保证真实性，不提供机密性 |
常用端点与验证
常用端点与验证
阿里 DoH：https 加 dns.alidns.com 加 /dns-query
腾讯 DoH：https 加 doh.pub 加 /dns-query
Cloudflare：https 加 cloudflare-dns.com 加 /dns-query
# 用 curl 验证 DoH 是否可用（需要正确的 Accept 头）
curl -s -H 'accept: application/dns-json' 'https://dns.alidns.com/resolve?name=example.com&type=A'
# 用 kdig 验证 DoT
kdig -d @223.5.5.5 +tls-ca +tls-hostname=example.com example.com典型使用场景
- 公共网络下保护解析隐私：避免域名被旁路记录
- 分支与出差场景绕过解析劫持，确认返回结果是否为真实权威数据
- 验证企业出口策略：确认 DoH 是否被限制或需要显式放行
- 排查「开启加密 DNS 后解析变慢」：确认端点连通性与是否走了代理
开启 DoH 后本地抓包看不到明文域名：隐私更好但排障更难，企业出口也可能因无法做域名审计而限制这类流量，上线前要先确认合规与运维要求。
加密 DNS 与 DNSSEC 解决的是不同问题：前者管机密性，后者管真实性。要同时防窃听与伪造，两者需要一起用。
加密 DNS 与系统级 VPN 或代理会互相影响：部分客户端把全部解析交给隧道，配置冲突时表现为解析时通时不通，排查要先确认最终生效的解析路径。