Introducing DNS Hammer, Part 2: Introducing a new tool

Part one of the series discusses DNS reflection attacks and DNS rate limiting. This post shows how to use DNS Hammer to audit a DNS server’s rate limit configuration.

A dedicated web site https://www.dnshammer.com offers the tool for download and instructions how to use it.

Summary for busy readers (tl;dr)

This blog posts shows how DNS Hammer is used to audit a name server’s rate limiting configuration. Selected real-life examples show results of restrictive and permissive configurations.

Running DNS Hammer

DNS Hammer runs on Windows computers. The only supported Windows version is Windows 10, but you may get lucky with older versions. Just download and run the executable.

For starters we need a domain to audit plus the IP address of an authoritative name server. Don’t worry if you only have a domain name, DNS Hammer will locate the name servers IP address for you. The authoritative name server holds a full copy of the domain database. The NS Finder in DNS Hammer will locate the known authoritative name servers.

Type the name of your target domain into the field, then click Go. In this screenshot we are pointing the tool towards govcert.ch. (In case you wonder: This domain refers to the GovCERT of the Swiss Government. And yes, they know that we use them as an example in this article).

Once you click “Go”, DNS Hammer will query the three name servers that are listed as “auxiliary name servers”. All three servers are well known open resolvers that can be used by everyone.

The screenshot shows the result: All three public resolvers find the same result: 2 name servers. Each name server has an IPv4 and an IPv6 address associated to it. These are the IP addresses to audit.

Right-click on one of the rows result-table where you find an IPv4 address.  At this time, DNS Hammer only supports IPv4, but support for IPv6 is on it’s way. Select the option “Test Forward Lookup” from the pop-up menu. DNS Hammer will copy the IP address of the name server and the domain name to the forward lookup section.

The program will switch to the Forward Lookup section and fill in the domain name and the IP address for you.

Click Go once more to start your first test. If you stick with the default values, DNS Hammer will send a mix of DNS queries to that server. The test takes 15 seconds. In each second the program will send the following packets:

• 5 queries for the IPv4 address of www.govcert.ch (the A record)
• 5 queries for the IPv6 address of www.govcert.ch (the AAAA record)
• 30 queries for the IPv4 address of random host names within the govcert.ch domain
• 5 queries for ANY
• 5 queries for the MX record
• The Flag for “Recursion Desired” will not be set, since we test an authoritative name server.

Watch the results coming in. By the end of the test run you will see a result similar to this one:

Note that DNS Hammer will send packets for the specified time (15 seconds by default). After the packets came in the program will wait for a few seconds to catch any responses that might be coming in late.

Interpreting the results

Let’s have a closer look at the results:

• We send 50 queries per second, but only received 35 responses.
• 15 responses per second are truncated. Only 20 requests got a full answer.

Note that DNS Hammer provides two more tabs in the result section, labeled “Bytes per second” and “Report”.

Bytes per second shows the number of bytes send and received. The chart visualizes if and how useful the DNS server might be for a reflection attack.

For one second, an attacker could amplify the traffic by a factor of 5. After that, a potential amplification factor goes down to 3, which is not very useful for an attack at all. If you start poking around you will soon find domains that amplify traffic by a factor of 20 or more.

The report tab gives a rough textual description of the test run. Here is the result:

Test Report for Domain govcert.ch
Name server: 84.254.110.74, recursion disabled

Test configuration:
A records per second: 5
AAAA records per second: 5
Random A records per second: 30
ANY records per second: 5
Random MX records per second: 5
Total requests per second: 50

Start time: 16/01/2021 20:38 Test duration: 15 sec

Requests send: 750
Responses received: 528
Truncated responses received: 223

The following DNS errors were encountered:
Error code 3 (Non-existent Domain): 228 (likely caused by random queries)

Bytes send:53,6 kB
Bytes received:220,4 kB
Amplification factor 4,1:
Test completed normally

More testing

Let’s play around with the parameters. If you read part 1 of this series you know, that queries for the ANY record are quite popular for DNS reflection attacks.

(Note: ANY is strictly speaking not a DNS record, since it is not defined in the servers database file. If a client is asking for “ANY” the server will multiple records. This feature is mostly useful for debugging purposes).

Let’s send 50 requests for ANY to the DNS server. The following screenshot shows both the configuration for the test run and the result:

For the first few seconds the server happily sends answers and then sets the “truncated” flag. This flag instructs the DNS client to use TCP connection for the query.

You might notice, that we send 50 requests per second. Once the rate limit fully kicks in the server only sends 25 responses. If you look at the BIND best practice guide published by ISC you will notice the parameter slip: ISC recommends a value of 2, so every second request will be answered. Clearly, slip is set to 2, so we get 25 responses to 50 requests.

Pro tip:

Don't trust the tool.
Verify the findings using Wireshark
before relying on the output of DNS Hammer.
This will a topic for a follow-up article.

Please let us know, if you find that DNS hammer reports incorrect values. This is version 1 after all.

You might want to file away the result for later reference. Right-click on the chart, copy it to the clipboard and paste it into your documentation.

If you paste the chart into another application you might notice a few details:

• The first line list the domain that is being tested and the number of requests per second.
• The second line shows the IP address of the name server that’s being audited and a time stamp.
• The third line documents the mix of DNS request was used to get this result.

More examples

The DNS Hammer Getting Started page holds a walk through for the domain ripe.net, home of RIPE, the organization that administrates all IP addresses in Europe.

A domain worth tuning

One of the reasons for writing DNS Hammer was to see, how other administrators configure their rate limit. Alas, most domains (or most domain servers) run without a limit.

Rather peculiar, if not outstanding, is one domain belonging to a very large company. Note that I have send 500 requests per second over 15 seconds. This would be a total of 7500 requests.

Most remarkably, my 7500 requests generated 7726 responses. And yes, I have double checked the number with Wireshark. With the parameters shown in the screenshot the server would amplify traffic by a factor of 34.

My curiosity being spiked, I send 500 requests per second for ANY records. This time I received 8051 responses, giving me an amplification factor of 70.

Alas, my mails to their security staff went unanswered.

What would be a good result?

Let’s look at a few restrictive configuration examples:

Strategy 1: Clam up under attack

You don’t want to stop your name server from sending responses, just because a single client / remote IP is sending requests like mad. Look at the configuration used by the German federal authorities for their domain bund.de:

The server initially sends 25 responses, then stops answering. That’s great to keep the server from participating in a DNS reflection attack. Unfortunately an attacker can keep a victim from contacting the domain, just by constantly sending queries:

Strategy 2: Rely on Truncation

Let’s go back to the configuration for govcert.ch. For this test I have send 500 requests per second. Overall, the server sends approximately 100 responses per second. The majority of responses is truncated:

 

The chart for bytes for second documents, that the name server is not useful for an attacker:

Note that the number of bytes send roughly matches the number of bytes received, making it useless for a DNS reflection attack. Even under attack, a legitimate client has a reasonable chance to get a response with the “truncated” flag. As a properly configured DNS resolver will switch to TCP, a potential victim can still contact the domain. Good job, guys!

Strategy 3: Rate limiting

In case you haven’t done so, I suggest that you hammer on the domain servers that are responsible for dnshammer.com. This DNS server is run by the German provider Hetzner. When sending 500 requests per second we initially get 100 responses, then things slow down at lot more.

That way, the domain is not useful for a DNS reflection attack. Still, visitors have a chance to get a response for their DNS queries. Another great strategy.

Choosing a Strategy

You might wonder, which strategy is best for you. This is a question, that only you can answer: How often are your servers participating in a DNS reflection attack? Are you part of a critical infrastructure? Are you or your clients subject to targeted DDoS attacks?

I am pretty sure, that each domain configuration presented in this post, has been implemented for one reason or another. Personally, I choose to host my domain with Hetzner because of their DNS configuration.

Do you have other ideas how to configure rate limiting? Did you implement or observe an interesting strategy, that we did not cover? Leave a comment!

Wait, there is more!

Thank you for your interest in DNS rate limiting. This series of blog posting is not complete yet. Part 3 will cover open resolvers.