问我不知道为什么这个包会进来: dns响应127.0.0.1

EN

由于远程数据包的源端口为53，通常有四种情况之一：

1. 您获得了以前由具有监听端口53的设备使用的IP地址，而过去知道它的设备仍在尝试使用它。(可能是权威服务器或开放解析器)
2. 你的设备正在参与攻击。
3. 这些数据包被反射到你身上，而你是攻击的目标，正如你所怀疑的那样。
4. 这些数据包被反射到您身上，而您不是攻击的目标。你的IP恰好是他们伪造的那个。

很多人把#1误认为是对他们服务器的攻击(#3)。你必须看看输入的流量来衡量，因为你没有抱怨你的带宽被这阻塞了，这是不可能的。让我们把第三条排除在外。

下一个提示是查询名：tnczmz.x99moyu.net。对于在过去几年中操作过高容量递归DNS服务器(并且一直在关注)的人来说，这样的名称是很熟悉的:这是一个“伪随机子域”又称“水刑”攻击。我不会在这里详细介绍，但是我们的想法是在一个域下生成数千个不可缓存的随机查询，这样所有的请求都会被发送到该域的名称服务器，该域是攻击的真正受害者。在这种情况下，它们是Cloudflare的名称服务器：

$ dig +short x99moyu.net NS
darwin.ns.cloudflare.com.
uma.ns.cloudflare.com.

由于我非常肯定您不是Cloudflare的服务器管理员，所以我们现在需要考虑数据包的方向，以排除#1。

• 资料来源: 171.125.150.23 (中国)
• 资料来源: 53
• 目的地:您的服务器
• 目的地端口:随机

中国的IP正在向您发送DNS应答数据包。我们知道它们是应答包，因为它们包含DNS应答部分。因为您或这个远程IP都不属于Cloudflare (它们的名称服务器管理域)，所以我们可以假设其中一个IP是被欺骗的。考虑到攻击的受害者(Cloudflare)和攻击的运作方式，这里最有可能被欺骗的地址是您的。这将使中文IP成为接收递归查询的服务器。

我的结论是，你既不是攻击的目标，也不是参与攻击的对象(通常情况下，你很幸运)。这是一个#4的例子:在执行针对Cloudflare的攻击时，您的源IP只是作为其他人掩盖其踪迹的一部分而被欺骗。

事后看来，#2仍然是一种可能性。即使持有您的IP的服务器没有提供DNS侦听器，您的服务器也可能受到破坏，并运行正在生成查询的恶意软件。当然，这假设您的数据包捕获忽略了出站查询。(我突然意识到，假设这件事会被注意到是错误的)

我不是一个系统管理员，而是一个编写DNS服务器软件的程序员。在我们的测试服务器和客户端(IS提供者)的服务器上，域x99moyu.net也存在同样的问题。一段时间前，我们的客户，ISP供应商报道了这件事。他们抱怨他们的网络速度明显减慢，所以我们采集了tcpdump样本并对其进行了检查。

我在日志中看到的是UDP上的洪水流量，地址是53端口和A？对xxx.x99moyu.net的请求，对于不存在的域名.数据包有错误的UDP校验和，所以它们只是在DNS网络和负载服务器中创建寄生虫流量。它占部分ISP服务器DNS业务量的2/3。它不会加载太多的服务器，但是由于DNS应答中的延迟增加，它会减慢客户端的网络速度。所以这很烦人。我在一些不是公共DNS服务器的测试服务器上也看到了同样的情况。所以我想机器人攻击任何他们能找到的监听端口53的服务器。源is的范围很广。我查过了，它们看起来像相应的数字(伪造地址)。有一段时间，我不知道如何堵住这些交通。