IETF 100 会议在新加坡召开，DNS over HTTPS 工作组（DOH）首次亮相。文章梳理了将 DNS 查询封装进 HTTPS 的三种技术路径，指出核心差异在于 DNS 应用与加密会话的交互层级，为后续标准化奠定分类基础。
HTTPS PROXY 隧道模式
最基础的思路是把 HTTPS 会话当作安全隧道，在双向 HTTP 请求中封装 IP 数据包。客户端通过 HTTP PUT 发送数据，服务端通过 GET 返回响应；HTTP 层完全不感知隧道内的二进制 DNS 报文，仅作透明封装。这种方式能让客户端在本地网络中隐藏 DNS 流量，但需要内侧客户端与外侧汇聚点预先协作，类似早期 SSL/TLS 隧道把加密通道作为虚拟接口传递 IP 包的做法。GitHub 已有示例实现。
HTTPS CONNECT 方法
HTTP CONNECT 指令将上述代理隧道能力标准化，仅限 TCP 连接而非原始 IP。客户端向 HTTPS 代理发送 CONNECT 命令，代理建立到目标服务器端口的 TCP 连接并转发数据。结合 DNS over TCP，可在本地部署解析器代理，经隧道与远程递归解析器通信。但支持 CONNECT 的代理通常实施严格访问控制，部署受限。
DNS 直接映射 HTTPS
第三种路径是将 DNS 报文直接映射为 HTTPS 请求/响应体，HTTP 层感知 DNS 语义。客户端以 HTTP POST 或 GET 发送编码后的 DNS 查询，服务端在 HTTPS 响应体中返回 DNS 答案。这种方式绕过代理隧道的协商开销，便于 Web 基础设施复用，但需定义 DNS 与 HTTP 的消息编码对应关系，原文未给出具体数据。
三种模式分别对应透明隧道、标准代理、语义映射三个层级，工程师在选型时需权衡部署复杂度、中间设备兼容性与流量特征暴露程度。DOH 工作组的分类框架为后续 RFC 8484 等标准制定提供了参照。
原文: APNIC Blog（2017-11-28）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog