如何通过 DNS 获取隐私和真实性？

信息安全 隐私 dns 托 监视 dnssec
2021-08-17 01:31:09

我使用 pfSense (Unbound) 作为我的本地解析器。从历史上看，我将其指向根递归解析，因为我认为我的主要威胁是数据的可信度和新近性（中毒/无效的 DNS）和本地 ISP DNS 跟踪。（我不知道是不是这样，但我觉得海外的根 DNS 服务器可能与我个人的连接较少，并且对我生成的任何查询不太感兴趣。）我主要使用可能相关的 IPv4。

随着对 DNS 跟踪的所有关注，出现了一些担忧和看法：

  • 为了隐私/确定性，我应该使用某种 DNS 加密或签名方法吗？我没有使用 DNSSEC 或任何其他扩展，因此我的 DNS 查询是“明文”纯文本。它们在这里和各种 DNS 服务器之间是可以观察到的，并且肯定没有“在线”过度操纵（不太可能但注意到）。但是使用什么以及它会有多大帮助，因为它不是每个人都支持的。
  • 我应该使用外部解析器而不是查询根服务器吗？我从一开始就查询根服务器，所以我从根服务器发出许多查询到实际感兴趣的子网，而不是在一些现有的 DNS 解析器/缓存上使用预缓存条目。但是每个 DNS 服务器只能看到域的一个组成部分，他们看不到整个目标。如果我使用中间解析器，尤其是带有签名/加密的解析器，我发出的 DNS 请求要少得多，而且我发出的问题总是会被加密和签名。但它需要一个具有相当信任（缓存等）的选定中介，并且不影响拦截的风险。
  • 我应该通过某种匿名代理路由 DNS 吗？第一次请求的速度较慢，但​​ Unbound 会在本地缓存任何回复，并在缓存数据过期之前请求刷新数据，我猜 80/20 规则适用（大多数查询将针对我所在的域的同一子集已经有缓存的数据），所以我不太担心速度方面。但这有多实用？最突出的匿名方法是tor。Tor 不执行 UDP，因此它通过要求出口节点执行 DNS 查询并信任结果来处理 DNS。我可以将 Unbound 配置为仅通过 TCP 查询 DNS，并通过本地 tor 路由，如果这样可以解决它（=如果大多数出口节点允许端口 53，并且如果大多数 DNS 服务器都使用 TCP）。如果有特定于 DNS 的 tor 等效项，我也很乐意运行 DNS 匿名节点，如果它可以帮助其他人（这可能让我的流量与一般 DNS 查询合并）但是这样的事情存在吗？

所以我目前的风险模型大概是这样的——

  • 中毒/无效数据；
  • 在服务器上记录/监控，以及“在线”修改/监控；
  • 将查询绑定到源 IP / DNS 匿名化。
    如果我不使用 DNS 代理/匿名化，那么只有 2 个选项。我可以自己解决从根服务器向下的所有问题，在这种情况下，我相信每个域上的每个 DNS 服务器都不会记录不太可能的查询，但是识别查询目标不太容易，因为生成的子域查询分布非常广泛。如果我使用公共解析器，我会将“我所有的鸡蛋放在一个篮子里”，因为他们会看到整个目标域，而不仅仅是其中的一部分，而且我相信它们不会被记录，这也可能是不现实的。所以 DNS 匿名化似乎是必要的，但它是否现实尚不清楚。

我很高兴投入工作来解决这个问题，我相信我可以改进我正在做的事情。但是将需要解决方法，因为 DNS 从根本上说是不安全的。

鉴于 DNS 的当前状态和匿名技术的当前状态，对于 DNS 查询缓解威胁的最佳方法是什么？

1个回答

简而言之，要么在您的计算机上安装启用了 QNAME 最小化 ( RFC 7816 ) 的 DNSSEC 解析器，要么对您信任/控制的远程服务器使用 DNS over TLS ( RFC 7858 )。

现在更详细地说，因为以前的设置适合​​不同的情况，也可以以某种方式组合。

首先，DNSSEC 不是您可以在任何地方都使用的东西，也不是有助于保护隐私的东西。对于启用了 DNSSEC（具有签名）的区域，如果您的解析器验证了它们，那么您就可以保证真实性（您无法获得虚假数据）和完整性（无法更改或降级）。这很有用并解决了一些问题，但是：

  1. 并非所有域名都启用了 DNSSEC，甚至远非如此
  2. 它不会阻止任何人读取您的 DNS 流量，因为请求和回复都保持清晰

因此，如果您这样做，您必须相信您的 ISP 或网络上的任何人不会嗅探您的流量。任何人都可以查看您的 DNS 消息，并更改未启用 DNSSEC 的消息。

另一种选择是通过 TLS 连接到一些使用这个新协议的远程 DNS 服务器。这给您带来两个好处：

  1. 没有人能够窥探或更改您的 DNS 消息，因为它们都受 TLS 保护，这适用于 DNSSEC 和未启用 DNSSEC 的域
  2. 您查询的权威域名服务器只会看到其他域名服务器 IP，而不会看到您的 IP。

当然，穷人的替代方案是使用 IPSEC 或 SSH 隧道，以获得几乎相同的好处，但并非没有一些复杂性，因为您需要同时处理 UDP 和 TCP。或 SOCKS 代理。但是由于基于 TLS 的 DNS 现在是一种标准（至少是 RFC），因此采用这种方式可能更有意义。

我说你需要信任/控制这个远程 DNS 服务器，因为它显然会看到你所有的 DNS 流量。所以这取决于你来定义你可以信任或不信任谁。一些公共开放 DNS 提供商现在也提供基于 TLS 的 DNS，例如 CloudFlare：https ://developers.cloudflare.com/1.1.1.1/dns-over-tls/但您可以在此处找到许多其他的：https:// dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers

如果您需要使用无法完全控制的此类名称服务器，有些人可能会建议您以使用多个服务器的方式进行设置，并在它们之间传播查询，这样就没有一个人可以重建您的整个 DNS会议。实施起来有点复杂，因为这不是名称服务器列表默认运行的标准方式。

附带说明一下，基于 HTTPS 的 DNS 标准目前正在酝酿中，应该“很快”就会到来。我想很多提供商都会提供这项服务，所以你将面临与今天与 VPN 提供商相同的困境（信任谁等）

您还说“但是每个 DNS 服务器只能看到域的一个组件，他们看不到整个目标。” 这在今天的实践中是错误的。该协议允许这样做，但由于各种原因，因为没有人记得递归名称服务器在每个步骤中将整个名称（每个标签）发送到每个权威名称服务器的时间。只有现在使用 QNAME 最小化标准 (RFC 7816)，解析器才能通过每次仅发送一个标签来进行遍历。这并非没有问题，因为一些名称服务器无法解决这个问题（因此一些递归的实现了回退策略：首先尝试使用 QNAME 最小化，如果失败，则像以前一样使用全名重新开始）

其它你可能感兴趣的问题
上一篇在哪里放置带有 EV 代码签名证书和插入式 HSM 的代码签名服务器 下一篇防病毒软件中基于云的提交有哪些隐私问题？