从本质上讲,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出站的所有其他流量.我绝对是新手,所以如果我的问题不符合我很抱歉,让我知道我应该如何修改.
解决方法
Network Ports Used by DNS | Microsoft Docs
因此,如果您计划对网络上的DNS查询进行一些安全监听,则需要考虑上述因素.
对于非查找流量,请考虑DNS还使用区域传输(查询类型AXFR)来更新具有新记录的其他DNS服务器.处于中间攻击状态的人可以从这样的转移开始,DDOS是主要名称服务器,因此它太忙而无法响应要求更新记录的辅助服务器.然后,黑客会欺骗相同的主节点将“有毒”记录提供给辅助节点,将流行的DNS域重定向到受感染的主机.
因此,您的安全审核应密切关注查询类型AXFR,并且您的DNS系统应仅接受来自特定IP地址的AXFR交换.
