# macOS 上的加密 DNS：带有配置文件的 DoH 和 DoT > 为什么普通 DNS 会泄漏您访问的每个站点，DNS-over-HTTPS 和 DNS-over-TLS 如何修复它，以及如何使用经过终端验证的签名配置文件在 Mac 上进行本机配置。 HisnLabs Security & Research Team · Published 2026-09-15 Canonical: https://hisnlabs.com/zh/blog/encrypted-dns-macos-guide 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`。 *quad9-doh.mobileconfig* ```xml PayloadContent PayloadType com.apple.dnsSettings.managed PayloadIdentifier com.example.dns.quad9-doh PayloadUUID REPLACE-WITH-A-UNIQUE-UUID-1 PayloadVersion 1 PayloadDisplayName Quad9 Encrypted DNS (DoH) DNSSettings DNSProtocol HTTPS ServerURL https://dns.quad9.net/dns-query ServerAddresses 9.9.9.9 149.112.112.112 2620:fe::fe 2620:fe::9 PayloadDisplayName Encrypted DNS - Quad9 PayloadIdentifier com.example.dns.quad9-doh.root PayloadType Configuration PayloadUUID REPLACE-WITH-A-UNIQUE-UUID-2 PayloadVersion 1 ``` 要使用 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`。 ## 安装它 1. 使用 `.mobileconfig` 扩展名保存文件并双击它，或打开“系统设置”，转到“隐私和安全”，然后转到“配置文件”，然后将文件拖入。 2. 在您批准之前，macOS 将显示有效负载内容 - 包括您配置的解析器；每次都要检查这一点，因为如果您从不受信任的来源安装配置文件，恶意行为者就可以通过配置文件重定向您的 DNS。 3. 单击安装并验证。像此示例这样的未签名配置文件将显示为“未签名”验证状态；这是手工构建的配置文件所期望的，本身并不是篡改的迹象，但对于个人测试之外的任何内容，您应该签署配置文件，以便验证其完整性。 ## 验证它是否有效 不要只信任设置窗格 - 从终端进行检查。 *终端* ```console # 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 则隐藏您从网络解析的域；使用其中之一并不会使另一个变得多余。 > **Note:** 加密的 DNS 保护的是查找，而不是其下游的所有内容。无法看到您解析的域的网络运营商通常仍然可以看到您随后通过 TLS 握手连接到的 IP 地址，除非您还使用类似 DNS-over-HTTPS 之类的技术并在两端结合加密客户端 Hello 支持——这是一种单独的、支持程度仍然不均匀的保护。 ## 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 的安全研究团队负责让这些判断保持准确：归类哪些域名只是普通的遥测、哪些属于真正的服务，追踪连接背后的国家和网络，并用真实的流量模式训练设备端模型（FireAI Pilot 功能）——这一切都不会离开你的 Mac。 你可以阅读它背后的技术决策，或试用 FireAI 17 天：[HisnLabs 出品的 FireAI](https://hisnlabs.com/fireai/zh/download)。 ## Sources - [RFC 8484: DNS Queries over HTTPS (DoH)](https://www.rfc-editor.org/rfc/rfc8484) - [RFC 7858: DNS over TLS (DoT)](https://www.rfc-editor.org/rfc/rfc7858) - [Apple Developer, WWDC20: Enable encrypted DNS](https://developer.apple.com/videos/play/wwdc2020/10047/) - [Apple Developer Documentation: DNSSettings payload](https://developer.apple.com/documentation/devicemanagement/dnssettings) - [Cloudflare: DNS over HTTPS](https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/) - [Cloudflare: DNS over TLS](https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-tls/) - [Cloudflare: 1.1.1.1 IP addresses](https://developers.cloudflare.com/1.1.1.1/ip-addresses/) - [Quad9: Service addresses and features](https://quad9.net/service/service-addresses-and-features)