HTTPS 会隐藏您发送到网站的内容,但在您的 Mac 打开该连接之前,它必须以纯文本形式询问一个问题:“这个名称指向哪个服务器?”这个问题(DNS 查找)默认在大多数网络上以未加密的方式传输,这意味着您的互联网提供商、办公室网络管理员或共享不安全 Wi-Fi 网络的任何人都可以看到您解析的每个域,即使页面本身随后已完全加密。
为什么普通 DNS 会泄漏
传统 DNS 在 HTTPS 成为网络默认标准之前几十年就已标准化,通过端口 53 上的纯 UDP 或 TCP 发送查询,没有加密,并且在大多数家庭和公共网络设置中,也没有对解析器进行身份验证。网络运营商不需要破坏 HTTPS 来构建您访问的每个域的列表 - 它只需要监视您的 DNS 流量,该流量位于其旁边的空白区域。这也是许多基于 DNS 的内容过滤器和某些形式的网络级监视的工作方式:不是通过检查加密流量,而是通过简单地记录或阻止在该流量存在之前必须进行的查找。
DoH 和 DoT:加密同一查找的两种方法
两个 IETF 标准通过对 DNS 查询本身进行加密来解决这个问题。 RFC 7858 中定义的 DNS-over-TLS 将 DNS 查询包装在端口 853 上的专用加密 TLS 连接中,将其与普通流量区分开来,使网络易于识别,原则上,如果网络想要专门停止加密 DNS,则可以完全阻止它。 RFC 8484 中定义的 DNS-over-HTTPS 而是将 DNS 查询映射到端口 443 上的标准 HTTPS 请求,几乎所有普通 Web 流量都使用同一端口 - 这种设计选择使 DoH 查询更难以区分,因此与一般 Web 浏览分开阻止。
自 macOS 11 起 Apple 的原生支持
Apple 将加密 DNS 直接构建到其网络堆栈中,而不是将其留给第三方应用程序,并在 WWDC 2020 上与 macOS Big Sur (macOS 11) 和等效的 iOS 14 版本一起宣布了该功能。会议提出了两种打开它的方法:NEDNSSettingsManager API供应用程序以编程方式配置它,以及大多数人实际使用的选项-携带com.apple.dnsSettings.managed有效负载的配置文件,记录在Apple的设备管理参考中,它允许您指定DoH或DoT解析器的地址,并让系统上的每个应用程序默认使用它,不需要第三方软件。
示例配置文件
配置描述文件是一个 XML 属性列表(.mobileconfig 文件),双击它或将其拖到“配置文件”窗格中后,macOS 可以通过“系统设置”进行安装。下面的示例将 Mac 指向 Quad9 的公共 DNS-over-HTTPS 解析器,这是一种广泛使用的、无需帐户的服务,默认情况下还会阻止与已知存在网络钓鱼和其他恶意活动的域的连接。使用前替换占位符标识符和UUID值;每个真实的配置文件都需要自己独特的PayloadUUID。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<dict>
<key>PayloadType</key>
<string>com.apple.dnsSettings.managed</string>
<key>PayloadIdentifier</key>
<string>com.example.dns.quad9-doh</string>
<key>PayloadUUID</key>
<string>REPLACE-WITH-A-UNIQUE-UUID-1</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>PayloadDisplayName</key>
<string>Quad9 Encrypted DNS (DoH)</string>
<key>DNSSettings</key>
<dict>
<key>DNSProtocol</key>
<string>HTTPS</string>
<key>ServerURL</key>
<string>https://dns.quad9.net/dns-query</string>
<key>ServerAddresses</key>
<array>
<string>9.9.9.9</string>
<string>149.112.112.112</string>
<string>2620:fe::fe</string>
<string>2620:fe::9</string>
</array>
</dict>
</dict>
</array>
<key>PayloadDisplayName</key>
<string>Encrypted DNS - Quad9</string>
<key>PayloadIdentifier</key>
<string>com.example.dns.quad9-doh.root</string>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>REPLACE-WITH-A-UNIQUE-UUID-2</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>要使用 Cloudflare,请将 ServerURL 设置为 https://cloudflare-dns.com/dns-query,将 ServerAddresses 设置为 1.1.1.1 和 1.0.0.1(对于 IPv6,使用 2606:4700:4700::1111 和 2606:4700:4700::1001) — 或者,对于 DNS-over-TLS 而不是 DoH,根据 Cloudflare 发布的 DoT 文档,将 DNSProtocol 设置为 TLS,将 ServerName 设置为 one.one.one.one。
安装它
- 使用
.mobileconfig扩展名保存文件并双击它,或打开“系统设置”,转到“隐私和安全”,然后转到“配置文件”,然后将文件拖入。 - 在您批准之前,macOS 将显示有效负载内容 - 包括您配置的解析器;每次都要检查这一点,因为如果您从不受信任的来源安装配置文件,恶意行为者就可以通过配置文件重定向您的 DNS。
- 单击安装并验证。像此示例这样的未签名配置文件将显示为“未签名”验证状态;这是手工构建的配置文件所期望的,本身并不是篡改的迹象,但对于个人测试之外的任何内容,您应该签署配置文件,以便验证其完整性。
验证它是否有效
不要只信任设置窗格 - 从终端进行检查。
# Show the resolvers macOS is actually configured to use
scutil --dns
# Look for your interface's resolver entry — it should now show
# the DoH/DoT server address you configured, not your router or ISP's resolver
# Confirm a lookup succeeds and see which resolver answered
dig example.com
# Cloudflare's own diagnostic page also reports whether your
# connection is using encrypted DNS when you open it in a browser
open https://1.1.1.1/help如果 scutil --dns 仍然将您的路由器地址或 ISP 的解析器列为活动 DNS 服务器,则配置文件没有生效 - 检查您是否将其安装在配置文件下,而不仅仅是下载它,并且没有其他网络配置(见下文)覆盖它。
使其停止默默工作的陷阱
- VPN 应用程序在连接时通常会覆盖系统 DNS 设置,而是通过其自己的解析器进行路由查找 - 在连接到 VPN 后(而不是之前)再次检查您的 DNS 配置。
- 酒店、机场和咖啡店 Wi-Fi 上的强制门户通常无法通过加密的 DNS 完成登录流程,因为它们依靠拦截普通 DNS 请求来将您重定向到登录页面;您可能需要暂时删除或禁用该配置文件才能上网,然后在连接后重新安装。
- 一些浏览器(其中包括 Firefox 和 Chrome)提供自己的独立 DoH 设置,可以覆盖或复制系统级配置;如果浏览器的行为与
scutil --dns报告的不匹配,请检查浏览器自己的网络设置。 - iCloud Private Relay 和加密 DNS 解决了不同的、重叠的问题 — Private Relay 向您在 Safari 中访问的站点隐藏您的 IP,而加密 DNS 则隐藏您从网络解析的域;使用其中之一并不会使另一个变得多余。
FireAI 和 HisnLabs 在其中扮演的角色
FireAI does not provide encrypted DNS today — it is on the roadmap, not in the current release — so a configuration profile like the one above is what actually closes the DNS-leak gap; FireAI’s job is different, watching and controlling which apps get to make a connection at all once that lookup resolves.
FireAI 是 HisnLabs 自己的产品:一款直接在 Mac 上运行的 AI 防火墙。它用通俗易懂的语言显示你的应用建立的每一个连接,并让你决定哪些数据可以离开你的 Mac——它的 AI 在本地运行,因此你的流量永远不会发送给我们或任何其他人。HisnLabs 的安全研究团队负责让这些判断保持准确:归类哪些域名只是普通的遥测、哪些属于真正的服务,追踪连接背后的国家和网络,并用真实的流量模式训练设备端模型(Autopilot 功能)——这一切都不会离开你的 Mac。
你可以阅读它背后的技术决策,或试用 FireAI 17 天:HisnLabs 出品的 FireAI。
