DNS 查询是否加密？

Question

我想知道 DNS 查询是否加密。如果是这样，您能否简要解释一下我认为要进行加密的过程，两方之间至少应该有一个最小的共同点（例如共享密钥），但是由于 DNS 使用 UDP 并且它是无连接的，我无法想象在这种情况下如何加密您的有效负载。

谢谢

Answer 1

默认情况下，DNS 在创建时既不提供真实性（确保您从区域的真正权威名称服务器获得响应）也不提供机密性（确保线路上的任何人都无法理解您的查询或答案）。

DNSSEC 的创建是为了解决真实性问题，因为它允许对记录进行签名，并通过密钥机制建立信任链并可以验证您得到的答案。从某种意义上说，它解决了中间人问题，如果相关区域已签名（目前仍占所有区域的 0.53% 左右），并且如果有人试图更改此类区域的回复，那么您将能够发现变化。

与直觉相反，真实性比保密更重要。为什么？因为如果你也不能保证你在说谁，即使答案是加密的，它有什么价值？如果您不对其进行身份验证，您可以与任何邪恶的第三方进行加密。

现在确实如此，如果您已经拥有真实性，例如因为 DNSSEC，您可能希望拥有机密性，因为 DNS 可以传达敏感信息或至少是个人信息。这也是QNAME 最小化现在存在的原因，以减少发送到每个名称服务器的信息量。这越来越受支持（即将在 Bind 中）

所以现在至于加密，您的第一个错误是考虑 UDP。DNS 使用 UDP和TCP，现在使用TCP 的频率更高，原因我们将在下面看到。除此之外，请注意，即使对于 UDP，您也有加密选项，请参阅DTLS，它基本上是 UDP 中的 TLS。QUIC由谷歌创建（基本上是为了能够创建一个优化的 HTTP，它在成为 SPDY 之后变成了现在的 HTTP/2），也是基于 UDP 构建的，其安全性类似于 TLS 提供的。看看这两个来揭穿你的想法，即在这种情况下无法加密有效载荷。

今天，对于加密的 DNS，您可以无特定顺序地使用这些选项：

• DNSCrypt：这不是 IETF 意义上的标准，而是一个开放协议，由各种参与者实施。见https://dnscrypt.info/
• DNS over TLS 现在是一个标准（RFC7858和RFC8310），您有各种文档解释初始握手应该如何发生，请参阅上面的第二个 RFC 和定义的两个安全配置文件，并注意 DANE 如何以及何时有用，在哪里DANE 强制要求使用 DNSSEC；下一版本的 Android 将默认支持 DNS over TLS（请参阅https://security.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html），即使它对我有用“私有DNS”的轻微用词不当。
• DNS over HTTPS（当时它本身使用 TLS）还不是 IETF 标准，但正在成为一个标准。
• Oblivious DNS是该块上的最新产品，它需要更新的客户端和服务器才能使用它，以及新的odnsTLD。

当然，在所有这些情况下，您都需要使用特定的服务器来执行协议。一些开放式解析器已经提供基于 TLS 的 DNS。然而，您只是转移了您的问题：您的连接由他们“保护”，但是您必须相信他们可以正常工作而不是对您撒谎，特别是在验证 DNSSEC 时。

你可以：

• 在https://dnscrypt.info/public-servers/ 上搜索支持 DNSCrypt 协议的服务器列表，或查看https://github.com/DNSCrypt/dnscrypt-resolvers/blob/master/v2/public-resolvers .md
• 当前使用CloudFlare、Quad9或CleanBrowsing在端口 853 上打开解析器以通过 TLS 进行 DNS，或者查看https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers以获取某些列表或https： //dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers
• 当前使用CloudFlare、Google Public DNS或CleanBrowsing，它们通过 HTTPS 提供 DNS，或者再次访问https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers获取一些列表。

Answer 2

标准 DNS 未在任何地方加密。DNSSEC 具有加密签名（但仍未加密）的响应。多年来出现了一些非标准的想法和实现，但没有什么重大的。

DNS 也应该通过 TCP 工作，因为它是处理太大答案的标准机制（替代方案是 IP 分段）。服务器本质上发送一个 UDP 响应，表示“答案太大，通过 TCP 重试”。

关于您的问题，一个简单但缓慢的解决方案是执行 HTTPS 所做的相同操作 - 进行三步 TLS 握手，以某种方式验证证书，然后交换数据。真正的挑战是减少往返次数，同时仍提供某种形式的安全性。