DNS 隐私注意事项

本文档描述了与 Internet 用户使用 DNS 相关的隐私问题。它提供了对当前典型隐私实践的一般观察。它旨在分析​​当前情况，并不规定解决方案。本文档废弃了 RFC 7626。 ¶ 本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。 ¶ 本文档是互联网工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导组 (IESG) 批准出版。并非所有 IESG 批准的文件都适用于任何级别的互联网标准；请参阅 RFC 7841 的第 2 节。¶ 有关本文档的当前状态、任何勘误表以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc9076。 ¶ 版权所有 (c) 2021 IETF Trust 和确定为文档作者的人员。版权所有。 ¶ 本文件受 BCP 78 和 IETF Trust 的与 IETF 文件相关的法律规定 (https://trustee.ietf.org/license-info) 的约束，在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。 ¶ 本文档是对 DNS 隐私问题的分析，本着 [RFC6973] 第 8 节的精神。 ¶

域名系统 (DNS) 在 [RFC1034]、[RFC1035] 和许多后来从未被合并的 RFC 中指定。它是互联网最重要的基础设施组件之一，经常被互联网用户（甚至许多专业人士）忽视或误解。互联网上的几乎所有活动都以 DNS 查询（通常是几个）开始。它的使用涉及许多隐私问题，本文档试图提供一个全面而准确的列表。 ¶ 让我们从 DNS 工作原理的简单提示开始（另见 [RFC8499]）。客户端（存根解析器）向称为递归解析器（也称为缓存解析器、完整解析器或递归名称服务器）的服务器发出 DNS 查询。让我们使用查询“www.example.com 的 AAAA 记录是什么？”举个例子。 AAAA 是 QTYPE（查询类型），www.example.com 是 QNAME（查询名称）。 （下面的描述假设一个冷缓存，例如，因为服务器刚刚启动。）递归解析器将首先查询根名称服务器。在大多数情况下，根名称服务器将发送推荐。在此示例中，引用将指向 .com 名称服务器。解析器向 .com 名称服务器之一重复查询。 .com 名称服务器反过来将引用 example.com 名称服务器。然后 example.com 名称服务器将返回答案。根名称服务器、.com 的名称服务器和 example.com 的名称服务器称为权威名称服务器。在分析隐私问题时，重要的是要记住向所有这些名称服务器提出的问题始终是原始问题，而不是衍生问题。发送到根名称服务器的问题是“www.example.com 的 AAAA 记录是什么？”，而不是“.com 的名称服务器是什么？”。通过重复完整的问题，而不是只是问题的相关部分到下一行，DNS 向名称服务器提供了比必要更多的信息。在这个简化的描述中，递归解析器没有实现 [RFC7816] 中描述的 QNAME 最小化，它只会将问题的相关部分发送到上游名称服务器。 ¶ DNS 严重依赖缓存，所以上面描述的算法实际上有点复杂，并不是所有的问题都发送到权威的名称服务器。如果存根解析器几秒钟后询问递归解析器，“_xmpp-server._tcp.example.com 的 SRV 记录是什么？”，递归解析器将记住它知道 example.com 的名称服务器，并且只会查询它们，绕过根和 .com。由于存根解析器中通常没有缓存，与权威服务器不同，递归解析器会看到所有 DNS 流量。 （应用程序，如 Web 浏览器，可能具有某种形式的不遵循 DNS 规则的缓存，例如，因为它可能会忽略 TTL。因此，递归解析器不会看到所有名称解析活动。）¶ 应该注意DNS 递归解析器有时会将请求转发到其他递归解析器，通常是更大的机器，具有更大和更多的共享缓存（查询层次结构可以更深，具有两级以上的递归解析器）。从隐私的角度来看，这些转发器类似于解析器，只是它们看不到所有发出的请求（由于第一个解析器中的缓存）。 ¶ 在撰写本文时，几乎所有这些 DNS 流量目前都未加密发送。然而，DNS over TLS (DoT) [RFC7858] 和 DNS over HTTPS (DoH) [RFC8484] 的部署越来越多，尤其是在移动设备、浏览器和任播递归 DNS 解析服务提供商。在少数情况下，存在一些替代通道加密，例如，在 IPsec VPN 隧道中，至少在存根解析器和解析器之间。最近对加密 DNS 流量的服务质量的一些分析可以在 [dns-over-encryption] 中找到。 ¶ 今天，几乎所有的 DNS 查询都是通过 UDP [thomas-ditl-tcp] 发送的。在考虑将流量加密作为一种可能的隐私技术时，这具有实际影响。一些加密解决方案只为 TCP 而设计，而不是 UDP，尽管新的解决方案仍在出现 [RFC9000] [DPRIVE-DNSOQUIC]。 ¶ 在分析 DNS 的隐私问题时要记住的另一个重点是，服务器收到的 DNS 请求是出于不同原因触发的。假设窃听者想知道用户查看了哪个网页。对于典型的网页，会发出三种 DNS 请求： ¶

这是用户键入、从书签中选择或通过单击超链接选择的 URL 中的域名。据推测，这正是窃听者感兴趣的地方。 ¶ 这些是由用户代理（此处为 Web 浏览器）执行的附加请求，用户没有任何直接参与或知识。对于 Web，它们由嵌入内容、级联样式表 (CSS)、JavaScript 代码、嵌入图像等触发。在某些情况下，单个网页上可能有数十个不同上下文中的域名。 ¶ 这些是 DNS 服务本身执行的附加请求。例如，如果查询的答案是对一组名称服务器的引用并且未返回粘合记录，则解析器将不得不发送额外的请求以将名称服务器的名称转换为 IP 地址。同样，即使返回了胶水记录，谨慎的递归服务器也会发送第三方请求来验证这些记录的 IP 地址。 ¶ 还可以注意到，在典型的 Web 浏览器的情况下，会发送比绝对必要更多的 DNS 请求，例如，预取用户稍后可能查询的资源或在地址栏中自动完成 URL 时。两者都是重要的隐私问题，因为它们甚至可能泄露有关非显式操作的信息。例如，仅读取本地 HTML 页面，即使不选择超链接，也可能触发 DNS 请求。 ¶ 本文档主要侧重于研究最终用户（执行 DNS 请求的用户）的隐私风险。普遍监视的风险 [RFC7258] 被考虑以及来自更集中监视的风险。在本文档中，术语“最终用户”按照 [RFC8890] 中的定义使用。 ¶ 本文档不尝试比较个别网络或组织提供的特定隐私保护；它仅对典型的当前做法进行一般性观察。 ¶ 区域持有者的隐私风险（某人获取数据的风险）在 [RFC5155] 和 [RFC5936] 中讨论。 ¶

递归运营商（包括访问提供商和企业网络中的运营商）的隐私风险，例如私有命名空间或阻止列表的泄漏，超出了本文档的范围。 ¶ 这里不考虑与使用其他利用 DNS 信息的协议相关的隐私风险。 ¶ 以下四节概述了与最终用户的 DNS 不同方面相关的隐私注意事项。在阅读这些部分时，需要记住许多注意事项（例如，递归解析器和传输协议）可能特定于设备在给定时间点使用的网络上下文。用户可能有许多设备，并且每个设备可能在一段时间内甚至同时使用许多不同的网络（例如，家庭、工作、公共或蜂窝）。对单个用户的隐私考虑的详尽分析需要考虑所使用的设备集和每个设备的多个动态上下文。本文档并未尝试进行如此复杂的分析；相反，它概述了可能构成此类分析基础的各种考虑因素。 ¶ 已经声明“DNS 中的数据是公开的”。这句话对于 Internet 范围的查找系统很有意义，并且所涉及的数据和元数据有多个方面值得更详细地查看。首先，尽管有访问控制列表 (ACL) 和私有命名空间，但 DNS 的运行假设面向公众的权威名称服务器将响应对其授权的任何区域的“通常”DNS 查询，而无需客户端的进一步身份验证或授权（解析器）。由于缺乏搜索功能，只有给定的 QNAME 才会显示与该名称相关联的资源记录（或该名称不存在）。换句话说：一个人需要知道要请求什么才能收到回复。目前所谓的“私有”资源泄漏的方式有很多。一些示例是 DNSSEC NSEC 区域行走 [RFC4470]、被动 DNS 服务 [passive-dns] 等。区域传输 QTYPE [RFC5936] 通常被阻止或限制为经过身份验证/授权访问以强制执行此差异（可能出于其他原因） ）。 ¶ DNS 数据与特定 DNS 事务（即 DNS 名称查找）之间的另一个区别：DNS 数据和 DNS 查询的结果是公开的，在上述范围内，并且可能没有任何保密要求。但是，单笔交易或一系列交易并非如此；这些交易不是/不应该是公开的。单个事务同时显示查询的发起者和查询内容；这可能会泄露有关特定用户的敏感信息。 DNS 世界之外的一个典型例子是，Alcoholics Anonymous 的网站是公开的，但您访问它的事实不应该公开。此外，链接查询的能力揭示了有关个人使用模式的信息。 ¶ DNS 请求包括许多字段，但其中两个字段似乎与隐私问题特别相关：QNAME 和源 IP 地址。 “源IP地址”在“源IP地址+可能是源端口号”的松散意义上使用，因为端口号也在请求中，可以用来区分共享一个IP地址的几个用户（在一个运营商后面-等级 NAT (CGN)，例如 [RFC6269]）。 ¶ QNAME 是用户发送的全名。它提供有关用户做什么的信息（“example.net 的 MX 记录是什么？”意味着他们可能想向 example.net 上的某人发送电子邮件，该域名可能只有少数人使用，因此非常揭示沟通关系）。一些 QNAME 比其他 QNAME 更敏感。例如，查询知名网络统计域的 A 记录揭示的很少（每个人都访问使用此分析服务的网站），但查询 www.verybad.example 的 A 记录，其中 verybad.example 是组织的域有些人认为令人反感或令人反感的内容可能会给用户带来更多问题。此外，有时，QNAME 嵌入了人们使用的软件，这可能是一个隐私问题（例如，_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org。还有一些 BitTorrent 客户端查询 _bittorrent-tracker._tcp.domain.example 的 SRV 记录。¶

QNAME 隐私的另一个重要事项是未来的使用。今天，缺乏隐私是将潜在敏感或个人身份数据放入 DNS 的障碍。目前，您的 DNS 流量可能会显示您正在交换电子邮件，而不是与谁交换电子邮件。如果您的邮件用户代理 (MUA) 开始在 DNS [RFC7929] 中查找 Pretty Good Privacy (PGP) 密钥，那么隐私就变得更加重要。电子邮件只是一个例子；对隐私更友好的 DNS 还会有其他真正有趣的用途。 ¶ 对于存根解析器和递归解析器之间的通信，源IP地址是用户机器的地址。因此，有关收集 IP 地址的所有问题和警告都适用于此。对于递归解析器和权威名称服务器之间的通信，源IP地址具有不同的含义；它与 HTTP 连接中的源地址的状态不同。通常，递归解析器的 IP 地址在某种程度上“隐藏”了真实用户。但是，隐藏并不总是有效。有时会使用 edns-client-subnet (ECS) EDNS0 选项 [RFC7871]（请参阅 [denis-edns-client-subnet] 中的一项隐私分析）。有时最终用户在他们的机器上有一个个人递归解析器。在这两种情况下，向权威服务器发起查询的 IP 地址与 HTTP [sidn-entrada] 一样敏感。 ¶ 关于 IP 地址的说明：尽管 [RFC7721] 确实讨论了 IPv6 地址生成机制的隐私注意事项，但目前还没有 IETF 文档详细描述有关 IP 地址的所有隐私问题。同时，这里的讨论旨在包括 IPv4 和 IPv6 源地址。由于多种原因，它们的分配和使用特性不同，这可能对与源地址收集相关的信息泄漏细节产生影响。 （例如，在公共 Internet 上看到的特定 IPv6 源地址比 IPv4 地址更不可能源自地址共享方案。）但是，对于 IPv4 和 IPv6 地址，重要的是要注意源地址是传播的通过 ECS 选项进行查询，并包含有关发起它们的主机、用户或应用程序的元数据。 ¶ 在撰写本文时，DNS 负载本身中不包含标准化的客户端标识符（如 [RFC7871] 中所述，ECS 被广泛使用；然而，[RFC7871] 只是一个信息 RFC）。 ¶ DNS Cookies [RFC7873] 是一种轻量级的 DNS 事务安全机制，它提供有限的保护，以防止路径外攻击者进行的各种日益普遍的服务和放大/伪造或缓存中毒攻击。然而，需要注意的是，它们仅用于验证 IP 地址（并​​且应该在客户端的 IP 地址更改后更改），但它们并非旨在主动跟踪用户（如 HTTP cookie）。 ¶ 在非标准 EDNS(0) 选项 [RFC6891] 中插入了媒体访问控制 (MAC) 地址甚至用户名的轶事帐户，用于存根到解析器通信以支持在解析器上实现的专有功能（例如，父母过滤）。 ¶ 递归解析器缓存的内容可以揭示有关使用它的客户端的数据（隐私风险取决于客户端的数量）。有时可以通过发送 RD=0 的 DNS 查询来检查此信息以检查缓存内容，尤其是查看 DNS TTL [grangeia.snooping]。由于这也是后续缓存中毒攻击的侦察技术，因此已经开发并部署了一些对策[缓存-窥探-防御]。 ¶

对于未加密的传输，DNS 流量可以像任何其他流量一样被窃听者看到。 （[RFC4033] 中指定的 DNSSEC，明确将机密性排除在其目标之外。）因此，如果发起方开始与接收方进行 HTTPS 通信，HTTP 流量将被加密，但之前的 DNS 交换将不会被加密。当其他协议变得越来越注重隐私并防止监视时（例如，[RFC8446]、[RFC9000]），使用未加密的 DNS 传输可能成为隐私中的“最薄弱环节”。需要注意的是，在撰写本文时，正在尝试加密 TLS 握手 [RFC8744] 中的服务器名称标识 (SNI)，这是连接目标最后剩余的非 DNS 明文标识符之一。 ¶ DNS 流量的一个重要特性是它可能采用与发起方和接收方之间的通信不同的路径。例如，窃听者可能无法窃听发起者和接收者之间的线路，但可以访问通往递归解析器或权威名称服务器的线路。 ¶ 从窃听者的角度来看，最好的窃听位置显然是在存根解析器和递归解析器之间，因为流量不受 DNS 缓存的限制。 ¶ 存根解析器和世界其他地方之间的攻击面可能会有很大差异，具体取决于最终用户设备的配置方式。按增加攻击面的顺序： ¶ 递归解析器可以位于最终用户的设备上。在（目前）少数情况下，个人可能会选择在本地机器上运行自己的 DNS 解析器。在这种情况下，stubresolver 和缓存解析器之间连接的攻击面仅限于该单机。递归解析器将向权威解析器公开数据，如第 6.2 节所述。 ¶ 递归解析器可能位于本地网络边缘。对于任何/大多数企业网络和一些住宅网络，缓存解析器可能存在于本地网络边缘的服务器上。在这种情况下，攻击面是本地网络。请注意，在大型企业网络中，DNS 解析器可能不会位于本地网络的边缘，而是位于整个企业网络的边缘。在这种情况下，企业网络可以被认为类似于下面提到的 Internet AccessProvider (IAP) 网络。 ¶ 递归解析器可以在 IAP 网络中。对于大多数住宅网络和可能的其他网络，典型情况是用户设备配置（通常通过 DHCP 或中继代理选项自动）客户驻地设备 (CPE) 中的 DNS 代理地址，然后指向 DNS 递归解析器在 IAP。因此，在线攻击的攻击面是从终端用户系统跨本地网络和跨 IAP 网络到 IAP 的递归解析器。 ¶

递归解析器可以是公共 DNS 服务（或托管在公共 Internet 上的私人运行的 DNSresolver）。某些机器可能被配置为使用公共 DNS 解析器，例如 tho ......