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出站的流量。我绝对是菜鸟，因此对于我的问题不符合要求，我们深感抱歉，并告诉我我应该如何修改。

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

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

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

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

因此，安全审核应密切注意查询类型AXFR，而DNS系统应仅接受来自特定IP地址的AXFR交换。

SANS研究所InfoSec阅览室 sans.org

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

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

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

• 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查询，dnscap就是一个示例。

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

1. 介绍

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

[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（或在网络层通过TCP阻止DNS）可能会导致解析失败和/或应用程序级别超时。

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

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