我不知道为什么这个数据包进来：dns响应127.0.0.1

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

1. 您以前使用过的设备使用了侦听端口53的IP地址，过去知道该设备的设备仍在尝试使用该IP地址。 （可能是一个权威的服务器或一个开放的parsing器）
2. 您的设备正在参与攻击。
3. 这些数据包正在被reflection到你身上，而你正在怀疑是攻击的目标。
4. 这些数据包正在反映到你身上，而你并不是攻击的目标。 你的IP恰好是他们伪装的那个。

很多人误认为＃1是他们的服务器（＃3）的攻击。 您必须查看传入stream量的数量，因为您不抱怨带宽因此被扼杀，所以不太可能。 我们来统治＃3。

我们的下一个提示是查询名称： tnczmz.x99moyu.net 。 这样的名字对于那些在过去几年中运行大容量recursionDNS服务器的人来说是很熟悉的（并且一直在关注）：这是一个“伪随机子域”，也就是“水酷刑”攻击 。 在这里我不会详细讨论这个细节，但是我们的想法是在一个域下生成数以千计的不可caching的随机查询，这样所有的请求都会发送给域名的域名服务器，而这个域名是攻击的真正受害者。 在这种情况下，他们是Cloudflare的名称服务器：

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

由于我非常肯定你不是Cloudflare的服务器pipe理员，我们现在需要考虑数据包的方向，以排除＃1。 以下是我们需要处理的内容：

• 资料来源：171.125.150.23（中国）
• 源端口：53
• 目的地：您的服务器
• 目标端口：随机

中国的IP正在向您发送DNS答复数据包。 我们知道他们是回复数据包，因为他们包含一个DNS答案部分。 由于您或此远程IP都不是由Cloudflare所有（其名称服务器pipe理域），因此我们可以假设其中一个IP被欺骗。 鉴于攻击的受害者（Cloudflare）以及攻击是如何运作的，这里最有可能被欺骗的地址就是你的。 这将使中国IP成为接收recursion查询的服务器。

我的结论是，你既不是攻击的目标，也不是参与攻击的目标（这种情况往往不是，你很幸运）。 这是＃4的一个例子：你的源IP被欺骗作为其他人的一部分，在对Cloudflare进行攻击时覆盖他们的踪迹。

事后看来，＃2依然是可能的。 即使持有IP的服务器没有提供DNS侦听器，您的服务器也可能受到威胁，并运行生成查询的恶意软件。 这假定您的数据包捕获忽略了出站查询，当然。 （对我来说，这是不好的假设，这将被注意到）

我不是系统pipe理员，而是编写DNS服务器软件的程序员。 我在我们的testing服务器上和我们的客户（IS提供商）的服务器上看到与域x99moyu.net相同的问题。 这是我们的客户，ISP提供商不久前报道的。 他们抱怨他们的networking显着减速，所以我们拿了tcpdump样本并检查了它们。

我在日志中看到的是UDP上泛滥的stream量，发往53端口，A？ 请求xxx.x99m​​oyu.net，为不存在的域名。 数据包有错误的UDP校验和，所以他们只是在DNSnetworking和负载服务器上创build寄生通讯。 它为一些ISP服务器提供了2/3的DNSstream量。 它不会加载服务器，但是由于DNS答案的延迟增加，它会降低客户端的networking速度。 所以这很烦人 我在一些我们的testing服务器上看到的也不是公有的DNS服务器。 所以我认为机器人攻击他们可以发现的端口53的任何服务器。源IP的范围是巨大的。 我检查，他们看起来像后续数字（欺骗地址）。 有一段时间，我不知道如何阻止这种stream量。