DNS 响应带有签名、查询通过 HTTPS 发送、递归解析器承诺不记录，这三件事解决的不是同一个问题。DNSSEC 验证数据来源与完整性，DoT/DoH 保护一段传输，递归端仍需要看到查询才能代为解析。

第 21 篇讨论递归与权威解析，第 24 篇讨论 TLS。本篇用同一查询的配置矩阵分别验证数据真实性、传输加密范围和递归端可见性。

DNSSEC 验证的是 DNS 数据

DNSSEC 为 DNS 数据加入 DNSKEY、DS、RRSIG 等记录。验证器从信任锚沿委派链检查签名，最终得到 Secure、Insecure、Bogus 或 Indeterminate 等结果。签名证明数据经过授权密钥签署且未被无痕修改，不为查询内容加密。

验证位置很重要。若递归解析器完成验证并给 stub 返回结果，stub 是否能信任该结论还依赖它与递归端之间的受信通道和配置。若 stub 本地验证，它需要取得并验证完整链。仅看到响应中的 AD 位，不能在任意不受信链路上自动等同于本地验证成功。

DNSSEC 也不隐藏域名。权威服务器和参与解析的递归端仍会处理相应名字，旁路观察者还可能从未加密 DNS 流量看到查询。

模式提炼：先问保护对象和观察者

机制 = 保护对象 + 覆盖链路 + 信任端点 + 仍可见元数据

“已加密”必须回答哪一段对谁加密；“已验证”必须回答由谁基于哪个信任锚验证。

DoT 与 DoH 加密 stub 到递归端

DoT（DNS over TLS）把 DNS 消息放入 TLS 连接，RFC 7858 定义了专用传输和默认端口。DoH（DNS over HTTPS）按 RFC 8484 用 HTTPS 交换 DNS 消息。二者都能保护客户端与所选递归解析器之间的传输，前提是 TLS 身份验证正确。

加密范围通常止于递归端。递归解析器需要读取查询名并向缓存或权威层查找答案，因此仍能看到客户端提交的名字、时间和来源关联信息。递归到权威之间是否加密是另一条链路，不能由 stub 使用 DoH 推出。

DoT/DoH 也不自动验证权威 DNS 数据。若递归端与客户端都不做 DNSSEC 验证，TLS 只保证从当前递归端收到的字节未被链路中间人修改，并不证明权威数据签名有效。

三个配置的静态矩阵

dns_security_model.py 检查三种固定配置：明文传输加本地 DNSSEC 验证、DoT 但不做 DNSSEC 验证、DoH 加递归端验证。输出分别列出真实性结论、stub 到递归端的加密和递归端可见性。

1
2
python3 source/_posts/2026-09-24-计算机网络E03-DNSSEC与加密DNS/dns_security_model.py --help
python3 source/_posts/2026-09-24-计算机网络E03-DNSSEC与加密DNS/dns_security_model.py

素材包括查询配置矩阵、静态验证脚本、矩阵结果、资料与运行记录和审阅记录。

矩阵中，明文 DNSSEC 案例具有数据真实性但没有 hop 加密；DoT 案例具有传输加密但没有 DNSSEC 验证；DoH 加递归验证同时具备两项，但递归端仍看见查询名。

条件、限制和反例

DNSSEC 验证失败可能来自签名过期、时钟错误、链不完整或真实篡改，不能把所有 Bogus 都归为攻击。

DoH 使用 HTTPS，不表示查询对 DoH 服务商不可见，也不隐藏 IP 地址、流量时序和连接目的地。与其他 HTTPS 复用可能改变旁路识别难度，但不消除元数据。

加密解析器不可用时是否回退到明文，是客户端策略。机会式回退与严格失败具有不同隐私和可用性取舍，部署结论必须记录所选模式。

练习

练习一：stub 通过明文 UDP 查询一个做 DNSSEC 验证的递归端，并只信任 AD 位。列出数据真实性和链路篡改方面仍需满足的条件。

练习二：浏览器使用 DoH，递归端不验证 DNSSEC。分别列出本地网络观察者、递归服务和权威服务可能看到的信息。

模式速查表

机制 主要保证 仍然不能保证
DNSSEC DNS 数据来源与完整性验证 查询机密性
DoT 指定 TLS 链路上的 DNS 传输加密 权威数据已签名验证
DoH 指定 HTTPS 链路上的 DNS 传输加密 递归端不可见查询
严格模式 加密失败时不降级 解析服务自身可信

官方一手参考资料

验证边界

已验证：Python 3 标准库对三种固定配置分别判定 DNSSEC 验证、stub 到递归端加密和递归端可见范围，验证类型为 STATIC。

NOT_RUN：未启动权威/递归解析器、DNSSEC 信任链、DoT 或 DoH 服务，未抓包验证 TLS、缓存、回退和真实查询隐私。静态矩阵不代表端到端部署结果。