DNS 与 HTTPS

这一课你将能做到

1. 说清 DoH、DoT、传统 DNS 三者在端口、报文封装、典型客户端上的差异，并亲手配置一次 DoH
2. 解释 CAA 记录如何约束 CA 签发，并用 dig 检查本站的 CAA 策略
3. 说清 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

JSON 接口示例返回：

{
  "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 极少见）；所以「换服务器不改证书」成立，「改域名不换证书」不成立。

讲清楚要点

1. HTTPS 不保护 DNS 查询：TLS 隧道是解析完成后才建立的；此前的 53 端口查询依然明文。要加密查询必须单独用 DoH/DoT。
2. DoH 与 DoT 安全性相同（都是 TLS），差别在流量形态：DoT 专端口便于网络层封禁或放行；DoH 走 443 与 Web 混合，隐蔽性强，企业内网因此需要专门策略管理。
3. CAA 是可选但强烈建议的记录：无 CAA 等于默认允许所有 CA；配置后 CA 必须强制查询，能防止攻击者通过未授权 CA 骗取证书。
4. HTTP-01 依赖 80 端口与解析指向本机：CDN 橙云、多机负载均衡、纯内网域名都可能让 HTTP-01 失败；这些场景首选 DNS-01。
5. DNS-01 支持泛域名、支持不开 Web 端口的主机，且可以通过 DNS 厂商 API 全自动续期；代价是需要保管 API Token（权限最小化，只给 Zone DNS 编辑权）。
6. 证书绑定的是主机名不是 IP：证书校验时客户端比对的是 URL 里的名字与 SAN；因此迁移 IP 不影响证书有效性。
7. 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 验证链路，再切强制

卡点急救

1. 启用 DoH 后网页打不开：换一个 DoH 端点（先排除服务商故障）；公司网络可能拦截外部 DoH，关闭安全 DNS 或改用公司指定端点。
2. 续期报 CAA record does not permit CA：dig 域 CAA 查现有策略，补一条对应 CA 的 issue；注意检查是否是父域或 CDN 平台设置了继承策略。
3. 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 凭证。

自测三问

1. 为什么说「网站上了 HTTPS，DNS 查询仍是裸奔」？要补哪一层？
2. 一张 *.coderoadmap.cn 证书申请时 CA 做了哪几步 DNS 检查与验证？
3. CAA 中 issue、issuewild、iodef 各管什么？什么时刻被检查？

小结一句话

DoH/DoT 给 DNS 查询本身穿上 TLS 外衣，CAA 给 CA 立规矩，ACME 借 HTTP 或 TXT 验证域名控制权——DNS 是整个 HTTPS 信任体系的地基。

延伸

• RFC 8484：DNS 查询的 HTTPS 编码（DoH）
• RFC 7858：DNS over TLS（DoT）
• RFC 8555：ACME 协议
• RFC 8659：CAA 记录
• 下一课预告：邮件相关记录——SPF/DKIM/DMARC 反伪造三件套与 MX/PTR 的协作。