服务器 Gind.cn
  1. 服务器 Gind.cn
  3. DNS查询是否总是通过UDP传输？
Intereting Posts
Oracle数据库11g速成版 – 内置备份文件将被保存 smbfs是否创build了不变的inode数字？ 将vCPU添加到现有的OS安装 预读值会在启动时自动更新 Linux：如何在界面上configurationdot1ad（双标签）？ GPO安全性使用组进行筛选 戴尔T7500 PERC RAID 监控各种Nagios？ Coffeesaint的替代品 在两个或更多RAID1磁盘对之上构buildLVM卷是否“安全”？ MAMP MySQL不会启动 如何让活动目录authentication用户使用Nagios的networking界面？ Ubuntu服务器随机hangups VNC通过SSH与一个命令 多个testing活动目录环境与生产域控制器一起使用 什么时候需要将Apache httpd与Apache Tomcat（mod_jk）集成？

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

我花了一些时间研究这个话题，似乎无法find一个确切的答案，所以我相当有信心，这不是一个重复的，虽然我的问题是基于安全需要，我认为它仍然是安全的请问这里，但让我知道如果我需要把它移动到安全社区。

从根本上说，DNS查询是否使用TCP（如果是这样，这种情况会发生）？ 再次，我只是在谈论查询。 他们可以通过TCP旅行吗？ 如果域最多只能有253个字节的长度，而UDP数据包最多只能有512个字节，那么不会总是以UDP的forms出现。 我不认为一个可parsing的查询可能足够大，需要使用TCP。 如果DNS服务器收到一个大于253字节的域的请求，服务器是否会放弃/不尝试并解决它？ 我确信我在这里做了一些错误的假设。

在某些情况下，我正在与安全小组合作，将DNS查询纳入他们的安全监控工具，由于各种原因，我们决定通过DNS服务器和域控制器上的标准数据包捕获来捕获此stream量。 核心要求是捕获所有DNS查询，以便他们可以识别客户端尝试parsing任何给定的域。 基于这一要求，我们不关心如何捕获DNS响应或其他stream量（如区域传输），这也是由于我们需要尽可能限制日志量。 因此，我们计划只捕获目的地为DNS服务器并通过UDP发送的DNS查询。 对于更多的上下文（问题范围在这里蔓延），现在已经提出，我们可能需要扩大安全的可见性，以便他们可以监视像DNS上运行的隐蔽通道这样的活动（这也将需要捕获DNS响应，和随后的TCPstream量）。 但即使在这种情况下，我认为任何出站DNSstream量都将以查找/查询的forms出现，而且即使是来自恶意来源（由于我在第一段中的推理），它们也始终是UDP。 所以这带来了一些额外的问题：

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

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

https://technet.microsoft.com/en-us/library/dd197515(v=ws.10).aspx

因此，如果您打算对networking中的DNS查询进行一些安全监听，则需要考虑上述问题。

至于非查找stream量，请考虑DNS也使用区域传输（查询typesAXFR）来更新其他具有新logging的DNS服务器。 一个处于中间人攻击的人可以开始这样的转移，DDOS的一个主要的名字服务器，以便忙于响应一个辅助请求更新的logging。 黑客然后欺骗相同的主要饲料“中毒”的logging，将stream行的DNS域redirect到受感染的主机。

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

https://www.sans.org/reading-room/whitepapers/dns/securing-dns-zone-transfer-868

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

  • 为避免UDP碎片， RFC 1035最初要求512字节的限制。 select分段的UDP数据报和TCP作为最后的select，以最小化DNS事务的开销。 区域传输总是使用TCP，因为区域传输本质上占据了> 512字节。 （根本就是以UDP开始，这会浪费带宽）

  • 截断时的TCP重试被广泛支持，因为自从1989 年以来它已经在RFC 1123中被指定了。

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

如果我们将这一点分解为观察到的行为：

  1. DNS查询通常以UDP开始，除非事先知道答复太大而无法开始。 （区域转移）
  2. 如果看到截断的答复，则答复可能触发客户端中的TCP重试。 这得到很好的支持。
  3. 如果客户端使用EDNS（0）通告更大的有效载荷， 并且接收服务器支持，则可以看到大于512字节的UDP回复。 只有在两者之间的硬件不会干扰并导致数据包丢失或损坏的情况下，才会发生这种情况。
  4. 如果没有看到回复，则客户端可以select重试更小广告负载的EDNS（0）查询，但具体情况会因实现而有所不同。
    • 重要的是要注意，最终实现的回复可能太大而不能满足要求的大小，这导致上面的行为＃2。 （如果TCP重试）
    • 客户端可能会select记住最终导致成功的大小。 这样可以避免浪费不必要的查询再次探测出来。 否则将是相当浪费，特别是如果最终结果需要TCP后备。

您还应该记住， RFC 7766允许通过TCP进行连接重用 ，并且可能会遇到通过TCP进行查询stream水线操作的情况。 有些工具不能检测到TCP会话中第一次看到的DNS查询，dnscap就是这样的一个例子。

有RFC 7766，基于TCP的DNS传输 – 实现要求 。

  1. 介绍

大多数DNS [ RFC1034 ]事务通过UDP [ RFC768 ]发生。 TCP [ RFC793 ]始终用于全区域传输（使用AXFR），并且通常用于大小超过DNS协议原始512字节限制的邮件。 DNS安全（DNSSEC）和IPv6的日益增长的部署增加了响应大小，因此使用了TCP。 增加TCP使用的需求也是由于它提供了对反欺骗和因此在reflection/放大攻击中利用DNS的保护而推动的。 它现在被广泛用于响应速率限制[ RRL1 ] [ RRL2 ]。 此外，近期有关DNS隐私解决scheme的工作，如[ 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，而大多数软件实现的默认configuration是支持TCP。 本文档的主要读者是对TCP的有限支持限制互操作性并阻碍新DNSfunction部署的实现者。

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

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

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

你不应该在任何方向上过滤TCP / 53。 例如， nsupdate查询可能在请求太大（可能发生得很快）时立即使用TCP。 所以你应该让UDP和TCP端口53（在IPv4和V6！）四通八达。

此外，通过TLS进行的DNS工作也越来越多，因此需要在两个方向上使用TCP。 请参阅RFC7858。