DNS 与 HTTPS
证书验证 TXT、CAA 概念。
DNS 与 HTTPS
这一课你将能做到
- 说清 DoH、DoT、传统 DNS 三者在端口、报文封装、典型客户端上的差异，并亲手配置一次 DoH
- 解释 CAA 记录如何约束 CA 签发，并用
dig 检查本站的 CAA 策略
- 说清 ACME 的 HTTP-01 与 DNS-01 验证流程，判断什么场景必须用 DNS-01
为什么要学
DNS 与 HTTPS 有两层关系：一是 DNS 查询本身可以被加密（DoH/DoT），防止域名被监听、劫持；二是 HTTPS 证书的签发与域名验证深度依赖 DNS——CA 要靠 DNS 确认你真的控制这个域名，CAA 记录则是给 CA 立的规矩。
很多初学者以为「上了 HTTPS，DNS 查询也就安全了」——恰恰相反，传统 DNS 查询始终是 53 端口的明文，你访问哪个网站，运营商、咖啡厅 Wi-Fi、中间网络设备一清二楚，还可以把你的解析悄悄改掉（域名劫持）。本课把「加密 DNS」和「DNS 如何支撑证书体系」两件事讲透。
先建立图像
① DNS 查询加密的三种形态
传统 DNS 客户端 ── UDP/TCP 53 明文 ──► 递归器 可监听、可篡改
DoT 客户端 ── TCP 853 + TLS ───► 递归器 报文加密，端口固定易识别
DoH 客户端 ── TCP 443 + HTTPS ─► 递归器 混在普通网页流量里，URL路径 /dns-query
② 证书签发时 DNS 的角色
你 ──申请证书(domain=www.coderoadmap.cn)──► CA（如 Let's Encrypt）
CA 先查 CAA：coderoadmap.cn 是否允许我签发？
│ 允许（或无CAA）
▼
CA 发起控制验证：
HTTP-01：给你一个 token，要求 http://域名/.well-known/acme-challenge/token 可访问
DNS-01 ：给你一个值，要求 _acme-challenge.域名 的 TXT 记录等于该值
│ 验证通过
▼
CA 签发证书（证书里不写 IP，只写域名）
| 方案 | 端口 | 封装 | 优势 | 代价 |
|---|
| DNS | 53/UDP,TCP | 裸报文 | 快、兼容好 | 明文 |
| DoT | 853/TCP | TLS | 加密、专端口易管控 | 端口特征明显，可能被封 |
| DoH | 443/TCP | HTTPS | 隐蔽、穿透性好 | 企业难审计、排查更复杂 |
跟着做
步骤 1：检查浏览器/系统是否已启用 DoH
Chrome/Edge：设置 → 隐私和安全 → 安全 → 使用安全 DNS。Firefox：设置 → 隐私 → 基于 HTTPS 的 DNS。
用公共解析器的 DoH 地址做手动配置，常见模板：
Cloudflare : https://cloudflare-dns.com/dns-query
Google : https://dns.google/dns-query
阿里 : https://dns.alidns.com/dns-query
启用后访问 Cloudflare 的开发帮助页 https://1.1.1.1/help，其中 "Using DNS over HTTPS (DoH)" 显示 YES 即成功。
步骤 2：用 curl 直接发一条 DoH 查询
# RFC 8484：GET 方式，dns 参数是 base64url 编码的 DNS 报文
curl -s -H 'accept: application/dns-message' \
'https://cloudflare-dns.com/dns-query?dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' \
| hexdump -C | head
# 更简单的 JSON 接口（Google/Cloudflare 提供，非标准但直观）
curl -s 'https://dns.google/resolve?name=www.coderoadmap.cn&type=A' | head -40
{
"Status": 0,
"Answer": [
{"name": "www.coderoadmap.cn.", "type": 1, "TTL": 293, "data": "104.21.5.10"}
]
}
这就是 DoH 的本质：DNS 报文装进 HTTPS 的 body，中间设备看到的只是普通 TLS 流量。
步骤 3：Linux 上配置 systemd-resolved 使用 DoT
sudo mkdir -p /etc/systemd/resolved.conf.d
sudo tee /etc/systemd/resolved.conf.d/dot.conf >/dev/null <<'EOF'
[Resolve]
DNS=1.1.1.1#one.one.one.one 2606:4700::1111#one.one.one.one
FallbackDNS=8.8.8.8#dns.google
DNSOverTLS=opportunistic
EOF
sudo systemctl restart systemd-resolved
resolvectl status | grep -A2 -i "DNSOverTLS\|DNS Servers"
opportunistic 模式在对端不支持时回退明文；验证全部正常后可改 yes 强制 DoT，不支持则直接失败（更安全）。
步骤 4：检查与配置 CAA
dig coderoadmap.cn CAA +short
dig +trace coderoadmap.cn CAA | grep -i caa
本站推荐的最小 CAA 集（Cloudflare 面板添加）：
# 只允许 Let's Encrypt 为普通域名签发
类型 CAA 主机 @ 值 0 issue "letsencrypt.org"
# 禁止泛域名证书（如确需泛域名，改成指定 CA）
类型 CAA 主机 @ 值 0 issuewild ";"
# 违规签发事件通知邮箱（iodef 标签）
类型 CAA 主机 @ string 0 iodef "mailto:admin@coderoadmap.cn"
dig coderoadmap.cn CAA +short
0 issue "letsencrypt.org"
0 issuewild ";"
0 iodef "mailto:admin@coderoadmap.cn"
注意 CAA 会沿名字树向上查：a.b.coderoadmap.cn 没有 CAA 时，就用 coderoadmap.cn 的策略。CA 对多次 CNAME 后的最终名字执行检查（RFC 8659）。
步骤 5：演练 ACME DNS-01 验证（泛域名场景）
HTTP-01 验证不了泛域名证书（*.coderoadmap.cn），必须 DNS-01。用 certbot 的 Cloudflare 插件自动写 TXT：
sudo apt install python3-certbot-dns-cloudflare
cat > /etc/letsencrypt/cf.ini <<'EOF'
dns_cloudflare_api_token = 你的Cloudflare_API_Token
EOF
chmod 600 /etc/letsencrypt/cf.ini
sudo certbot certonly --dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cf.ini \
-d '*.coderoadmap.cn' -d coderoadmap.cn
插件会自动完成：创建 _acme-challenge.coderoadmap.cn TXT → 等待权威生效 → CA 查询验证 → 删除记录。手工流程等价于：
# 1) 面板添加 TXT：主机 _acme-challenge，值为 CA 给的随机串
# 2) 验证记录已在权威生效
dig TXT _acme-challenge.coderoadmap.cn @ns1.cloudflare.com +short
# 应看到："xxxxxx随机串xxxxxx"
# 3) 回到 CA 页面点「验证」
步骤 6：确认证书与域名、解析三者对齐
# 看证书覆盖的域名（SAN）
openssl s_client -connect www.coderoadmap.cn:443 -servername www.coderoadmap.cn </dev/null 2>/dev/null \
| openssl x509 -noout -text | grep -A1 "Subject Alternative Name"
X509v3 Subject Alternative Name:
DNS:coderoadmap.cn, DNS:www.coderoadmap.cn
证书不含 IP（IP 需用 iPAddress SAN，公网 Web 极少见）；所以「换服务器不改证书」成立，「改域名不换证书」不成立。
讲清楚要点
- HTTPS 不保护 DNS 查询：TLS 隧道是解析完成后才建立的；此前的 53 端口查询依然明文。要加密查询必须单独用 DoH/DoT。
- DoH 与 DoT 安全性相同（都是 TLS），差别在流量形态：DoT 专端口便于网络层封禁或放行；DoH 走 443 与 Web 混合，隐蔽性强，企业内网因此需要专门策略管理。
- CAA 是可选但强烈建议的记录：无 CAA 等于默认允许所有 CA；配置后 CA 必须强制查询，能防止攻击者通过未授权 CA 骗取证书。
- HTTP-01 依赖 80 端口与解析指向本机：CDN 橙云、多机负载均衡、纯内网域名都可能让 HTTP-01 失败；这些场景首选 DNS-01。
- DNS-01 支持泛域名、支持不开 Web 端口的主机，且可以通过 DNS 厂商 API 全自动续期；代价是需要保管 API Token（权限最小化，只给 Zone DNS 编辑权）。
- 证书绑定的是主机名不是 IP：证书校验时客户端比对的是 URL 里的名字与 SAN；因此迁移 IP 不影响证书有效性。
- DoH 可能改变「就近解析」：本机把查询远端发给海外 DoH 服务器，CDN 调度可能被带偏（第 11 课讲）；选用与用户位置匹配的解析器。
你可能会懵的地方
-
开了 DoH，为什么公司还是能知道我访问什么网站？
DNS 只藏住了「查名字」这一步；随后的 TLS 握手会明文暴露 SNI（目标域名，除非启用 ECH 加密 Client Hello），IP 也暴露。DoH 不是隐身术，只是补上 DNS 这一环。
-
CAA 配错了会不会导致现有证书失效？
不会。CAA 只在「新签发/续期」时刻被 CA 检查，已签发证书在到期前始终有效。但续期前必须修正，否则续期会被拒。
-
DoT 端口 853 被封怎么办？
改 DoH（443 几乎不会被全封）；或在本机先 TLS 到一台自建中继、再由中继转发查询。
-
DNS-01 的 TXT 记录验证完要删吗？
自动插件会删除；手工操作建议删除——每次 CA 给的随机值不同，留旧值无意义且干扰下次（多条 TXT 并存时 CA 要求其中一条匹配，通常也能过，但保持整洁更稳）。
-
为什么 dig +trace 看到的是 UDP 53，和 DoH 没关系？
+trace 是诊断工具、按传统协议做迭代；DoH/DoT 是终端用户到递归器这一段的加密，权威之间的迭代至今基本仍是传统 DNS（部分有加密趋势但未普及）。
错法对照
| 错法 | 后果 | 正确做法 |
|---|
| 以为 HTTPS 即 DNS 加密 | 查询仍被劫持监听 | 单独启用 DoH/DoT |
| CAA 只写 issue 忘记 issuewild | 攻击者仍可能骗取泛域名证书 | 明确 issuewild 策略 |
| 用 HTTP-01 申请泛域名 | CA 直接拒绝 | 泛域名必须 DNS-01 |
| 给 certbot 的 API Token 给全域账号权限 | Token 泄露=域被接管 | 建专用 Token，仅 DNS 编辑、限指定 Zone |
| DoT 直接设强制模式后验证不充分 | 解析全断、无法上网 | 先 opportunistic 验证链路，再切强制 |
卡点急救
- 启用 DoH 后网页打不开：换一个 DoH 端点（先排除服务商故障）；公司网络可能拦截外部 DoH，关闭安全 DNS 或改用公司指定端点。
- 续期报
CAA record does not permit CA：dig 域 CAA 查现有策略，补一条对应 CA 的 issue；注意检查是否是父域或 CDN 平台设置了继承策略。
- DNS-01 一直验证失败：
dig @权威NS _acme-challenge.域 TXT 确认记录已生效（注意多 TXT 多权威同步）；值或主机名拼错是首因；CDN 代理不影响 TXT，不要去橙灰云上找原因。
面试常问
-
DoH 和 DoT 有什么区别？各自解决什么问题？
都把传统 53 端口的明文 DNS 报文用 TLS 加密，解决窃听与篡改。DoT 走专用 853 端口，特征明显，适合企业统一管控；DoH 走 443 端口、封装成 HTTPS，和普通网页流量混合，穿透性强但不利于审计。选择取决于网络策略：运营商/企业出口多用 DoT 做合规，终端浏览器默认 DoH 提升隐私。
-
什么是 CAA？没有配会怎样？
CAA（RFC 8659）是域所有者发布的证书签发授权记录，声明哪些 CA 可以为该域签发证书、是否允许泛域名以及违规上报地址。CA 签发前必须查询并遵守；没有 CAA 记录时默认任何 CA 均可签发。它能显著降低未授权证书风险，建议配合 issuewild 和 iodef 一起配置。
-
Let's Encrypt 的 HTTP-01 和 DNS-01 验证有何区别？
HTTP-01 要求域名解析到申请机且 /.well-known/acme-challenge/ 路径公网可访问，配置简单，但 CDN 代理、多后端、80 受限场景不稳，且不支持泛域名；DNS-01 要求在 _acme-challenge 下放指定 TXT，支持泛域名和无 Web 服务的主机，配合 DNS 厂商 API 可全自动续期，代价是管理 API 凭证。
自测三问
- 为什么说「网站上了 HTTPS，DNS 查询仍是裸奔」？要补哪一层？
- 一张
*.coderoadmap.cn 证书申请时 CA 做了哪几步 DNS 检查与验证？
- CAA 中 issue、issuewild、iodef 各管什么？什么时刻被检查？
小结一句话
DoH/DoT 给 DNS 查询本身穿上 TLS 外衣，CAA 给 CA 立规矩，ACME 借 HTTP 或 TXT 验证域名控制权——DNS 是整个 HTTPS 信任体系的地基。
延伸