打开网页时，浏览器地址栏的小锁图标让人安心，说明连接是 HTTPS 加密的。很多人以为这意味着整个访问过程都安全了，连域名解析也受到保护。其实没那么简单。
HTTPS 保护的是哪一段？
HTTPS 加密的是客户端（比如你的电脑）和网站服务器之间的通信内容。你输入的网址、提交的表单、浏览的页面，这些数据在传输过程中不会被中间人看到或篡改。但这个加密从你已经知道目标 IP 开始才生效。
而 DNS 查询，是你访问网站的第一步——把像 baidu.com 这样的域名翻译成 IP 地址。这一步通常发生在 HTTPS 建立连接之前，而且默认使用的是明文协议。
DNS 查询为什么可能暴露？
假设你在公司用 Wi-Fi 访问一个医疗咨询网站。虽然网站本身是 HTTPS 的，但你的设备会先向本地 DNS 服务器发起查询："baidu.com 的 IP 是多少？" 这个请求如果是通过传统 DNS（端口 53），数据包在网络中是明文传输的。路由器、ISP 甚至局域网里的其他人，理论上都能看到你查了什么域名。
也就是说，即便后续通信加密了，别人仍能通过 DNS 记录推测你的上网行为。比如频繁查询某心理诊所的域名，虽看不到具体内容，但访问意图已经泄露。
那 HTTPS 能不能顺带保护 DNS？
不能直接保护。标准的 HTTPS 不包含 DNS 加密机制。但技术在演进，现在有几种方案可以补上这个缺口：
DNS over HTTPS（DoH） 把 DNS 查询裹进 HTTPS 流量里，发往支持 DoH 的服务器，比如 Cloudflare 的 1.1.1.1 或 Google 的 8.8.8.8。这样 DNS 请求就和普通 HTTPS 流量混在一起，外人看不出区别。
配置 Firefox 使用 DoH 的示例：
设置 -> 网络设置 -> 启用基于 HTTPS 的 DNS
选择："使用系统首选项" 或自定义提供者DNS over TLS（DoT） 则是在传输层用 TLS 加密 DNS 通信，端口通常是 853。和 DoH 类似，只是封装方式不同。企业内网部署时，管理员可以在本地 DNS 服务器上启用 DoT，让所有设备自动走加密通道。
服务器端怎么做更安全？
如果你维护的是企业出口网关或公共 Wi-Fi，建议配置递归 DNS 服务支持 DoT 或转发到 DoH 上游。例如用 dnsmasq 配合 stubby 实现本地 DoT 转发：
listen-address=127.0.0.1
port=53
server=127.0.0.1#5333再让 stubby 将请求加密发往 9.9.9.9 等支持 DoT 的服务器。这样一来，局域网内所有设备的 DNS 查询都会被自动保护，无需逐个设置。
另外，应用服务本身也可以推动加密 DNS 的使用。比如在移动端 App 内集成 getdns 或系统 API 直接发起 DoH 请求，绕过系统默认的明文 DNS。
所以，别再以为开了 HTTPS 就万事大吉。真正的隐私保护，得从第一步——域名查询开始加密。