题目与适用场景
这道题适合网络、安全、后端、SRE 和售前工程岗位。强回答要把 DNS over HTTPS（DoH）当作协议边界，而不是“给 DNS 加证书”。DoH 把 DNS 查询和响应放进 HTTPS 交换中。它能隐藏受保护链路上的查询内容，但选定的解析器仍会收到查询并可能记录或过滤。选择取决于谁需要看到 DNS、需要哪些策略控制，以及客户端能否稳定访问解析器。
面试官考察点
- 能否区分 DNS 消息语义与 HTTP 状态、传输行为。
- 能否说清隐私边界：到指定解析器的加密不等于匿名。
- 是否理解 GET、POST、内容类型、缓存行为和启动解析。
- 能否按部署方、可观测性、延迟和策略比较 DoH、DoT 与普通 DNS。
- 能否定义降级和测试，而不是认为加密自动改善所有结果。
回答前需要澄清的问题
先确认客户端和解析器由谁管理，企业过滤或审计策略是否必须继续生效，网络是否阻断外连 HTTPS 或 UDP/TCP DNS，以及目标是隐藏本地网络观察、给应用提供 API，还是防篡改。确认由浏览器、操作系统解析器还是管理代理发起查询。还要问延迟预算、强制门户、分流 DNS、DNSSEC 校验、日志保留和解析器不可达时的可接受回退。这些答案可能让企业托管解析器、应用 DoH、DoT 或普通 DNS 更合适。
30 秒回答框架
DoH 把每个 DNS 查询响应映射为 HTTPS 请求响应，通常使用 application/dns-message 承载 DNS wire format。它加密客户端到解析器的链路，并可穿过允许 HTTPS 的网络，但解析器仍能看到查询，企业策略也可能要求固定端点。GET 更容易复用 HTTP 缓存；POST 不把编码后的查询放进 URL，更适合敏感请求。我会在明确需要隐私或应用 API 时选择 DoH；如果托管解析器和专用传输边界更重要，会比较 DoT，并先定义启动解析、缓存、分流 DNS、降级、日志最小化和验证方案。
分步骤深入解答
1. 画清协议分层
DNS 问题本身仍是 DNS 消息。RFC 8484 把一次查询响应映射为一次 HTTP 交换，并定义 application/dns-message 二进制表示。HTTPS 提供 TLS 机密性与完整性，HTTP 提供方法、状态码、连接复用和缓存控制。DNS 的 NXDOMAIN 或 SERVFAIL 仍是 DNS 响应码，可以装在 HTTP 2xx 中；HTTP 4xx 或 5xx 表示 HTTP 交换失败，不包含原始 DNS 答案，因此客户端要分开处理两层错误。
2. 有意识地选择 GET、POST 和缓存
RFC 8484 要求 DoH 服务端为该媒体类型支持 GET 与 POST。GET 把 Base64URL 编码的 DNS 消息放进 dns 查询参数，可能提高普通 HTTP 缓存复用率，但也会让查询进入 URL 日志、中间设备或浏览器历史，除非这些表面都受控。POST 把二进制消息放入请求体并设置内容类型。敏感域名优先使用 POST，或使用严格治理的 GET 路径；减少请求头，并确保缓存不会用自己的新鲜度规则覆盖 DNS TTL。Google 同时提供 RFC 8484 端点和独立 JSON 端点，两者是不同的 API 契约。
3. 定义隐私和策略边界
DoH 能阻止本地观察者读取受保护链路上的明文 DNS 包，但解析器仍可看到查询、客户端元数据、时间特征和策略上下文。HTTPS 不会自行验证 DNS 答案；解析器的 DNSSEC 行为和客户端信任模型仍然重要。企业托管环境可能需要批准的解析器、分类过滤、分流区域、保留策略和审计证据。允许应用任意选择公共解析器，可能绕过这些控制，即使流量已经加密。
4. 处理启动解析、故障和回退
客户端必须先获得 DoH 服务器地址，才能通过同一服务解析该服务器。启动解析可以使用配置的 IP、可信解析器或其他配置通道；每条路径都要做证书校验和轮换。区分 HTTP 错误、DNS 响应错误、超时、强制门户拦截和策略拒绝。解析器故障可以回退到批准的传输，但静默切到不受信任解析器会违反隐私或企业策略。默认不保留完整查询内容，只记录回答所用的解析器和传输。
5. 比较部署选择并验证
传统 DNS 简单且网络运营方可见，但明文传输会暴露链路上的查询。DoT 通过专用 TLS 服务加密 DNS，通常适合操作系统解析器。DoH 把 DNS 融入 HTTPS，可复用 HTTP 基础设施、浏览器 API 和 443 端口可达性，但会增加 HTTP 层策略与可观测性复杂度。用受控抓包、解析器侧 DNS 与 HTTP 状态日志、缓存命中和 TTL、分流 DNS、DNSSEC 失败、强制门户、解析器故障、证书轮换和回退策略验证选择。测量 p50/p95/p99、错误类别和查询泄露，不只看平均延迟。
高质量示范回答
DoH 是把 DNS 查询响应放进 HTTPS 交换的协议。DNS 消息保持原有含义；HTTPS 保护客户端到指定解析器的链路，HTTP 提供方法、状态码、连接复用和缓存行为。NXDOMAIN 可以放在 HTTP 2xx 中，HTTP 5xx 则表示没有 DNS 答案的传输或服务失败。我会在需要应用级 API 或隐藏本地网络查询、且能指定批准解析器时使用 DoH。敏感域名优先 POST，减少请求头，并明确解析器策略、DNSSEC、分流区域和日志保留。启动解析要通过配置或可信路径完成，回退必须符合策略。上线前测试缓存和 TTL、GET 的 URL 日志暴露、强制门户、证书轮换、解析器故障、DNSSEC 错误，以及是否有查询绕过指定解析器。
常见错误
- 说“HTTPS 让 DNS 匿名” → 指定解析器仍能看到查询和元数据 → 说明具体加密链路与解析器信任边界。
- 把 DNS
NXDOMAIN当 HTTP 错误 → DNS 响应码可以在 HTTP 2xx 中 → 分开解析 HTTP 与 DNS 状态层。 - 使用 GET 传敏感查询却不讨论 URL 日志 → 编码后的查询可能进入历史或中间日志 → 使用 POST 或受控缓存与日志策略。
- 说 DoH 永远优于 DoT → 部署方、策略、可达性和可观测性不同 → 先比较实际环境。
- 通过同一个尚未解析的解析器启动 DoH 主机名 → 形成循环依赖 → 预置地址或可信启动路径。
- 超时后回退到任意公共解析器 → 可能绕过隐私和企业过滤 → 限制批准的传输与端点。
- 只测平均延迟 → 故障、缓存未命中和泄露被隐藏 → 分段看 p95/p99、错误类别、TTL 与解析器身份。
追问及应对
DoH 会验证 DNS 答案真实吗？
不会。TLS 认证的是客户端选择的 HTTPS 服务器。答案真实性取决于解析器的校验行为以及客户端对解析器的信任；DNSSEC 和 HTTPS 是两件事。设计应明确是否强制校验，以及校验失败如何呈现。
为什么 HTTP 200 里可能是失败的 DNS 查询？
因为 HTTP 交换本身成功并传输了合法 DNS 消息。DNS 消息可能带有 NXDOMAIN、SERVFAIL 等响应码。客户端必须解析两层，不能把合法的 DNS 负面答案当 HTTP 失败重试。
什么时候 DoT 更合适？
当操作系统或企业解析器控制传输、需要专用 DNS 端口和清晰网络策略、又不需要面向浏览器的 HTTP API 时，DoT 很合适。需要现有 HTTPS 可达性或应用 API 时可选 DoH。依据应是所有权和策略，而不是“加密一定更好”。
强制门户下 DoH 解析器不可达怎么办？
检测门户或反复 TLS/HTTP 失败，停止重试放大，然后按配置策略使用批准的回退、暂停解析并提示恢复，或仅在允许时暂时使用网络提供的 DNS。上线前必须测试，因为盲目回退会泄露所有查询。