I need you guys help.

I am using lots of public IP for servers which are opened only one port for service. And also using L3 switch for load-balance. ( I used them for EXDNS, Pulic-web, etc.)

In this surrounding, I found some packets which came from many public IPs with 53 port to my public IPs with any port, not the port i am using. And the Domain name was xxxx.x99moyu.net (Lowest part of domain was randomly changed.) This is ACK packet and include the answer 127.0.0.1 for query. But our servers' never send DNS query for those domains. One of the packets I've got is

*------------------------------------------------------------------

IPv4, Src : 171.125.150.23, Dst: 112.x.x.x (my ip)
UDP, Src Port: 53, Dst Port: 54162
Domain Name System (response)
Questions: 1
Answer RRs: 1
Queries : tnczmz.x99moyu.net : type A, class IN
Answers : tnczmz.x99moyu.net : type A, class IN, addr 127.0.0.1
--------------------------------------------------------------------*

When I saw these packets first, write a senario about DNS amplification attack. Using DNS Servers on the internet and my public ip for src.ip, then my server will get many answer packets from DNS servers. But targets are too wide to success this attack, because over 200 servers got those packets and each servers got only 3-5 dns responses.

So, if anyone has a similar experience or know the reason why it happened, please let me know. Thx.

With the remote packets having a source port of 53, one of four things is usually the case:

  1. You were given IP addresses that were previously used by devices with a listening port 53, and devices who knew about it in the past are still trying to use it. (could have been an authoritative server or an open resolver)
  2. Your devices are participating in an attack.
  3. These packets are being reflected onto you and you are the target of the attack, as you are suspecting.
  4. These packets are being reflected onto you and you are not the target of the attack. Your IP just happens to be the one they're faking.

Lots of people mistake #1 to be an attack on their server (#3). You have to look at the amount of incoming traffic to gauge, and since you aren't complaining about your bandwidth being choked by this it's unlikely. Let's rule #3 out.

Our next hint is the query name: tnczmz.x99moyu.net. Names like this are familiar to anyone who has operated high volume recursive DNS servers in the last few years (and have been paying attention): this is a "Pseudo Random Subdomain" aka "Water Torture" attack. I won't get into exhaustive detail here, but the idea is to generate thousands of uncacheable random queries under a domain so that all the requests are sent up to the nameservers for that domain, the true victim of the attack. In this case they're the nameservers for Cloudflare:

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

Since I'm pretty sure you aren't a server admin for Cloudflare, we now need to consider the direction of the packets in order to rule out #1. Here's what we have to work with:

  • Source: 171.125.150.23 (China)
  • Source Port: 53
  • Destination: Your Server
  • Destination Port: Random

A Chinese IP is sending you DNS reply packets. We know they're reply packets because they contain a DNS answer section. Since neither you or this remote IP are owned by Cloudflare (their nameservers manage the domain), we can assume that one of these IPs is spoofed. Given the victim of the attack (Cloudflare) and how the attack operates, the address most likely being spoofed here is yours. That would make the Chinese IP a server that is receiving the recursive queries.

My conclusion is that you are neither the target of the attack or participating in the attack (which is the case more often than not, you got lucky). This is a case of #4: your source IP is just getting spoofed as a part of someone else covering their trail while performing an attack against Cloudflare.


In hindsight, #2 is still a possibility. Even if the server holding your IP does not provide a DNS listener, your server could be compromised and running malware that is generating the queries. This assumes that your packet capture is overlooking the outbound queries, of course. (it dawned on me that it's bad to assume that this would have been noticed)

  • I'd appreciate it if another DNS admin with experience in this area could double check my work. There were a number of factors to consider here and it's easy to end up going down the wrong rabbit hole. Feel free to post your own answer. – Andrew B Dec 14 '15 at 18:28

I'm not a system administrator, but a programmer writing DNS server software. I see the same problem with domain x99moyu.net on our testing servers and on servers of our clients (IS providers). It was reported a while ago by our client, ISP provider. They complained their network slowed down significantly, so we took tcpdump samples and checked them.

What I see in logs is a flooding traffic on UDP, addressed to port 53, with A? requests for xxx.x99moyu.net, for non-existing domain names. Packets have wrong UDP checksum, so they just create parasite traffic in DNS network and load servers. It makes up to 2/3 of DNS traffic volume for some ISP servers. It does not load servers much, but it slows down the client's network speed due to increasing delays in DNS answers. So this is quite annoying. And I see same on some our test servers that are not public DNS servers. So I figure the bots attack whatever server they can find that listens to port 53. The range of source IPs is huge. I checked, they look like consequent numbers (spoofed addresses). For a while I do not know how to block this traffic.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.