☰

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

tag-icon • tag-icon domain-name-system tcp udp
DNS 查询总是通过 UDP 传输吗？

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

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

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

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

  • 是否可以修改 DNS 查询以使用 TCP？DNS 服务器是否会接受并响应通过 TCP 发送的 DNS 查询？

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

答案1

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

DNS 使用的网络端口 | Microsoft Docs

因此，如果您计划对网络的 DNS 查询进行一些安全监视，则需要考虑上述因素。

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

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

SANS 研究所信息安全阅览室 | sans.org

答案2

这篇文章最初是乔治的回答的评论，但后来很长。整体情况有些复杂，因为它需要了解一些历史。

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

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

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

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

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

你还应该记住RFC 7766 允许通过 TCP 进行连接重用，并且有可能在现实中遇到通过 TCP 进行的查询流水线。一些工具不要检测 TCP 会话中第一次看到的 DNS 查询，dnscap 就是一个例子。

答案3

那里是 RFC 7766，TCP 上的 DNS 传输 - 实施要求。

  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 和其他互联网协议中的 TCP 的研究、开发和实施中获得了额外的考虑和经验教训。

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

答案4

您不应在任何方向上过滤 TCP/53。例如，nsupdate只要请求太大（这种情况可能很快就会发生），查询就可能会使用 TCP。因此，您应该让端口 53 的 UDP 和 TCP（在 IPv4 和 V6 中！）在所有方向上流动。

此外，针对 TLS 上的 DNS 的工作也越来越多，因此双向都需要 TCP。请参阅 RFC7858。

相关内容