DNS 查询是否总是通过 UDP 传输？

Question

我花了一些时间研究这个话题，似乎找不到确切的答案，所以我相当有信心它不是重复的，虽然我的问题是基于安全需要，但我认为它仍然是安全的在这里问，但如果我需要将其转移到安全社区，请告诉我。

本质上，DNS 查询是否曾经使用 TCP（如果是，会发生什么情况）？同样，我只是在谈论查询。它们是否可以通过 TCP 传输？如果域的最大长度只能为 253 个字节，而 UDP 数据包的最大长度为 512 个字节，那么查询不会总是以 UDP 的形式发出吗？我不认为可解析的查询大到需要使用 TCP。如果 DNS 服务器收到对大于 253 字节的域的请求，服务器会丢弃它/不尝试解析它吗？我确定我在这里做了一些错误的假设。

在某些情况下，我正在与安全组合作将 DNS 查询加载到他们的安全监控工具中，出于各种原因，我们决定通过 DNS 服务器和域控制器上的标准数据包捕获来捕获此流量。核心要求是捕获所有 DNS 查询，以便他们可以识别尝试解析任何给定域的客户端。基于此要求，我们不关心捕获 DNS 响应或其他流量（如区域传输），这也是由我们需要尽可能限制日志量这一事实驱动的。因此，我们计划仅捕获发往 DNS 服务器并通过 UDP 发送的 DNS 查询。对于更多上下文（这里的问题范围正在蔓延），现在有人提出我们可能需要扩展安全性” s 可见性，因此他们可以监视活动，例如通过 DNS 运行的隐蔽通道（这也需要捕获 DNS 响应，以及随后的 TCP 流量）。但即使在那种情况下，我认为任何出站 DNS 流量都将采用查找/查询的形式，并且这些流量始终通过 UDP，即使来自恶意来源（因为我在第一段中的推理）。所以这带来了一些额外的问题：

• 我们至少会用我概述的方法捕获一半的对话吗？或者客户端是否会发送非查询形式的 DNS 流量？（也许就像对 DNS 服务器响应的某种回复，最终可能会通过 TCP 发送出去）

• 是否可以修改 DNS 查询以使用 TCP？DNS 服务器会接受并响应来自 TCP 的 DNS 查询吗？

不确定它是否相关，但我们确实将 DNS 请求限制为授权的 DNS 服务器并阻止所有其他通过端口 53 出站的流量。我绝对是一个菜鸟，所以如果我的问题不合规，我很抱歉，并让我知道我应该如何修改。

Answer 1

普通 DNS 查询使用 UDP 端口 53，但较长的查询（> 512 个八位字节）将收到“截断”回复，这会导致 TCP 53 对话以促进发送/接收整个查询。此外，DNS 服务器绑定到端口 53，但查询本身源自发送到端口 53 的随机高编号端口（49152 或更高版本）。响应将从端口 53 返回到同一端口。

DNS 使用的网络端口 | 微软文档

因此，如果您计划对来自网络的 DNS 查询进行一些安全侦听，则需要考虑以上内容。

对于非查找流量，请考虑 DNS 还使用区域传输（查询类型 AXFR）来使用新记录更新其他 DNS 服务器。中间人攻击可以从这样的传输开始，对主名称服务器进行 DDOS，因此它太忙而无法响应辅助请求更新记录。然后，黑客欺骗同一个主节点，将“中毒”记录提供给辅助节点，从而将流行的 DNS 域重定向到受感染的主机。

所以你的安全审计应该密切关注查询类型 AXFR，你的 DNS 系统应该只接受来自特定 IP 地址的 AXFR 交换。

SANS Institute InfoSec 阅览室 | sans.org

Answer 2

这开始是对乔治回答的评论，但时间很长。更大的图景有些复杂，因为它需要了解一些历史。

• RFC 1035最初要求限制为 512 字节以避免 UDP 分段。分片的 UDP 数据报和 TCP 被选为最后的选择，以最大限度地减少 DNS 事务的开销。区域传输总是使用 TCP，因为区域传输本质上占用 >512 字节。（从 UDP 开始会浪费带宽）

• TCP 截断重试得到广泛支持，因为它自 1989年以来已在RFC 1123 中指定。

• EDNS(0) 由RFC 6891 (2013)定义，在此之前作为建议标准存在于 1999 年。它定义了一种机制，客户端和服务器可以协商大于 512 的 UDP 大小。由于 EDNS(0) 的新颖性，许多硬件设备对 DNS 数据包的结构做出假设，导致兼容数据包被丢弃。最常见的原因是假设超过 512 字节的 DNS 消息无效，但这只是其中的一个。

如果我们将其分解为观察到的行为：

1. DNS 查询通常以 UDP 开始，除非提前知道回复太大而无法开始。（区域转移）
2. 如果看到截断的回复，回复可能会在客户端触发 TCP 重试。这得到了很好的支持。
3. 如果客户端使用 EDNS(0) 来通告更大的有效负载，并且接收服务器支持它，则可能会看到大于 512 字节的 UDP 回复。只有当介于两者之间的硬件不会干扰并导致数据包丢失或损坏时，才会发生这种情况。
4. 如果没有看到回复，客户端可以选择使用较小的广告负载重试 EDNS(0) 查询，但具体情况会因实现而异。
   • 重要的是要注意，最终通过的回复可能太大而无法适应请求的大小，这会导致上述行为 #2。（你们老 TCP 重试）
   • 客户端可以选择记住最终导致成功的大小。这允许它避免浪费不必要的查询再次探测它。否则会非常浪费，特别是如果最终结果需要 TCP 回退。

您还应该记住，RFC 7766 允许通过 TCP 进行连接重用，并且可能会在野外遇到通过 TCP 的查询管道。除了在 TCP 会话中看到的第一个 DNS 查询之外，一些工具不会检测 DNS 查询，dnscap 就是这样的一个例子。

Answer 3

这里是 RFC 7766，DNS运输通过TCP -执行要求。

1. 介绍

大多数 DNS [ RFC1034 ] 事务发生在 UDP [ RFC768 ] 上。TCP [ RFC793 ] 始终用于全区传输（使用 AXFR），并且通常用于大小超过 DNS 协议原始 512 字节限制的消息。DNS 安全 (DNSSEC) 和 IPv6 的不断部署增加了响应大小，从而增加了 TCP 的使用。增加 TCP 使用的需求也受到它提供的保护以防止地址欺骗，从而在反射/放大攻击中利用 DNS。它现在被广泛用于响应速率限制 [ RRL1 ] [ RRL2 ]。此外，最近在 DNS 隐私解决方案方面的工作，例如 [ DNS-over-TLS] 是重新审视 DNS-over-TCP 要求的另一个动机。

[RFC1123] 的第 6.1.3.2 节指出：

  DNS resolvers and recursive servers MUST support UDP, and SHOULD
  support TCP, for sending (non-zone-transfer) queries.

然而，一些实现者认为上面引用的文本意味着 TCP 支持是 DNS 协议的一个可选功能。

大多数 DNS 服务器运营商已经支持 TCP，并且大多数软件实现的默认配置是支持 TCP。本文档的主要受众是那些对 TCP 的有限支持限制了互操作性并阻碍新 DNS 功能部署的实现者。

因此，本文档更新了核心 DNS 协议规范，以便对 TCP 的支持从此成为完整 DNS 协议实现的必需部分。

增加使用 TCP（见附录 A）有几个优点和缺点，以及需要考虑的实现细节。本文档解决了这些问题，并将 TCP 作为 DNS 的有效传输替代方案。它扩展了 [ RFC5966 ]的内容，并从 DNS 和其他 Internet 协议中 TCP 的研究、开发和实施中获得了额外的考虑和经验教训。

虽然本文档没有对 DNS 服务器的运营商提出具体要求，但它确实为运营商提供了一些建议，以帮助确保其服务器和网络对 TCP 的支持是最佳的。应该注意的是，不支持 TCP（或在网络层阻止 DNS over TCP）可能会导致解析失败和/或应用程序级超时。