SPF question
Question asked by John A Coutts - January 12 at 4:06 PM
I have built a program to filter out excess DNS requests so that SimpleDNS does not have to process them. Recently we encountered a problem with excessive type 99 (SPF) requests, which our server does not support. The bulk of these requests are coming from Google and Amazon (3100 from Amazon alone on one morning from dozens of servers). Why these biggies are asking for a deprecated DNS type and not accepting the answer is beyond me, and to make matters worse, they started asking for another deprecated type A6. So I added them both to the filter. It worked like a charm when I tested it with an SPF request (timed out), but there are still queries that are making it through the filter. SimpleDNS responds to SPF requests with:
Request from for ?99?-record for xxxxxxx.com.
-> Header: Not implemented.
Any ideas?
J.A. Coutts

5 Replies

Reply to Thread
John A Coutts Replied
January 15 at 12:26 AM
It turns out to be a DoS attack. Requests being sent through as type 32,768 are being interpreted by SimpleDNS as type 99, and requests sent through as type 0 are being interpreted as type A. I have adjusted my filter to block all non-essential query types.
J.A. Coutts
After modifying the filter, the statistics for Sun. Jan 15, 2017 are:
Requests received by filter - 49,905
Requests passed onto SimpleDNS - 6,075
Requests dropped by filter - 43,830 or 88%
John A Coutts Replied
January 24 at 11:54 AM
Is a type 32,768 (0x8000) a legitimate request? There is no RFC covering this type, so that is the reason I ask. Would it be safe to assume that any IP making such a request is spoofed?
J.A. Coutts
JH Software Replied
February 7 at 5:11 AM
Employee Post
32768 is "TA" / "DNSSEC Trust Authorities".
See https://en.wikipedia.org/wiki/List_of_DNS_record_types
So I would assume that it is legitimate, and I would not consider such requests spoofed by default.
John A Coutts Replied
February 7 at 2:42 PM
The traffic is now well over 100,000, so I have had to block any IP making a recursive query of this type (over 400 per day). If it was legitimate, why would they be asking for recursion for one of our domain names? The bulk of the IP addresses used are from Level 3 Communications, Google, and Amazon, with a lesser amount from Yahoo and AOL. Noticeably absent is Microsoft.. Because legitimate sites could get caught up in the Block List, it is reset every 4 hours. I have also noticed an increase in the use of TCP recently. The TCP requests look legitimate, so I have left them alone. J.A. Coutts
John A Coutts Replied
February 21 at 12:36 AM
The situation has deteriorated further. Yesterday, we got these results.
Requests received by filter - 103,390
Requests passed on to DNS - 1,095
Requests dropped by filter - 102,295 or 99%
This is after modifying the filter once again. The Drop List was changed from a static Drop List to a dynamic Drop List. After analyzing the incoming requests, we determined a commonality to the spoofed requests, and used that criteria to add IP addresses to the Drop List. Because it is conceivable that a legitimate server may be requesting the experimental type that we are triggering on, we clear the Block List every 4 hours.
The question might arise as to how we know these are spoofed requests. The first clue is that on Jan. 05, we recorded a DNS volume about 4 times normal. It then fell back to normal volumes for 3 days, before climbing steadily every day thereafter. This is a common hacker technique. You test your code for a brief period of time to prevent the target from recognizing it as an attack and adjusting for it. The second clue is the fact that they are requesting DNS translations for record types that do not exist or are experimental. The third clue is the fact that the IP addresses seem to added to the Drop List in groups over a very short period of time (1 to 2 seconds).
So why are the hackers still continuing the attack using our DNS server when it obviously isn't working? When you spoof an IP address using UDP, you never know that the target is not responding, because the responses would normally go to the spoofed address.
In the filter, we make 4 different checks on the query question.
1. Is the IP address on the Drop List? If so, drop it.
2. Is the query of the trigger type? If so, add it to the Drop List.
3. Is the query for a domain that we do not host? If so, drop it.
4. Is the query a duplicate of one already requested? If so, drop it.
J.A. Coutts
02/15/2017 (Block List not implemented)
Total queries processed - 49,905
Queries forwarded to DNS - 6,075
02/20/2017 (Block List implemented)
Total queries processed - 103390
Queries forwarded to DNS - 1095
Total queries processed - 133025
Queries forwarded to DNS - 1056
Total queries processed - 240771
Queries forwarded to DNS - 601
Total queries processed - 669611
Queries forwarded to DNS - 1111
Total queries processed - 511333
Queries forwarded to DNS - 842
Total queries processed - 977501
Queries forwarded to DNS - 834
Total queries processed - 873405
Queries forwarded to DNS - 843
Total queries processed - 627842
Queries forwarded to DNS - 1507

I find it difficult to imagine that we are the only victim in this attack.

Reply to Thread