DNS Hammer LogoDNS Hammer

User Guide


Auditing Forward Lookups

DNS Hammer starts with the configuration panel for Forward Lookups. The majority of DNS requests asks for the IP address of a given hostname. The sender can either ask for a "classic" IPv4 address or the newer IPv6 address. These addresses are stored in the A and AAAA records. Searching for information in a domain is also known as "forward lookup".
Screenshot Forward Lookup
To audit a name server’s forward lookup configuration, you need two pieces of information:
  • An IP address of one of your name servers (1)
  • The domain name to audit (2)
As part of the audit DNShammer can send up to 500 queries per second. The queries can be a mix of the following record types (3):
  • A record for a given hostname (asking for an IP v4 address)
  • AAAA record for a given hostname (asking for an IPv6 address)
  • A record for a random hostname
  • MX record (asking for a mail server that accepts mail to this domain)
  • ANY record (asking for whatever interesting information is available)
The hostname used for A and AAAA queries can be configured in the dialog and has a default value of www. (4)
By default, DNS Hammer will send these requests for 15 seconds to the name server. If desired, the test can take up to 2 minutes (120 seconds). (5)
A drop-down menu (6) decides, what type of name server is being tested: Either an authoritative name server or an open resolver.
Options for Recursion
An authoritative name server holds a full copy of the domain database. If the requested record exists it will send an answer. If it does not exist, it will signal the client accordingly. Most domains use at least two authoritative name servers, that synchronize their databases.
An open resolver does not hold a full copy of the database. Instead, it will retrieve the requested record from an authoritative name server. The record will be cached for a certain time, that is specified by the original domain administrator. Further requests will be answered through the cached record.
Select "Desire Recursion" if you test an open resolver. In nearly all other cases "No Recursion" is your best choice.
The test starts when you click the "Go!" button. Here are a few noteworthy details:
  • DNS Hammer is sending the requests in the background.
  • The requests do not come as a steady stream, but in bursts.
  • Each burst starts at the beginning of a one-second interval
A simple logic counts all incoming responses and checks, if the "truncated" flag is set, and if the server signals an error other than "record not found". Usually, a DNS error is only signalled by an open resolver, where a typical error would be "query refused".

A Short Test Run

Let's take a look at the domain hp.com. For this test, I have selected the name server 15.72.96.180. The test sends 100 queries of each type. The chart (7) showing the responses reveals, that server only sends 400 answers. This is usually, because some blocked the server from answering to ANY record.
HP analysis: 400 responses
400 responses is a good place to start. But how many bytes did the server send? Switch to the tab "Byte per sec" to see the network traffic.
Note that DNS Hammer send about 35 kByte per second while server responded with approx. 75 kByte per sec. If you need to write a report, you can right-click on the chart and copy it to the clipboard.
HP analysis: 75 kByte per sec
Switch to the report section to get a text with a few statics. Note that DNS Hammer has send 7500 requests and counted 5999 responses. Following best practices, HP's server did not responsd to queries for the ANY record. 100 queries for ANY times 15 seconds accounts for 1500 missing responses. Clearly, one of the servers responses fell of the wagon. DNS is using the UDP protocol after all, and datagrams might be dropped without notice somewhere along the way.
HP analysis: Report
Yes, the report section could look nicer. If I find more time to spend on the program, this might improve.

Interpreting the result

While the responses are coming in, the following results are shown in a chart:
  • Total number of responses per second
  • Number of responses with the "truncated" flag set
  • Number of responses with a DNS error code other than "no such domain"
In rare cases you might see send errors. This indicates that a request could not be send. The send error is caused by a local condition on your computer on in your network. For example, if your computer is not connected to network, this would trigger a send error.
Note that the chart header shows the domain name, target IP address, and number of queries send per record type. With a right-click the chart can be copied into the clipboard and inserted into whatever documentation you are maintaining.
A later version might reveal more information through a mouse-over event. If or when more features are added depends on feedback from the user community (if there ever will be one) and my personal time table.
The second graph in the tab "Byte per sec" gives details about the network traffic. This helps to understand, if, for how long, and under which conditions the server could be abused for a reflection attack. The more bytes the server sends, the more likely it is to be abused for an attack.
None of the charts reveals, which record types are delivered by the server, or which record types generate the "truncated" flag. Personally, I find, that this level of detail would generate a confusing graph. Try changing the mix of queries (like only ANY records) to find out, if certain requests are simply discarded by the server.
The report section gives a few more details on the result. Arguably the most important number to look at is the potential amplification factor. At the time of this writing (end of 2020) it seems to be easy to find servers with an amplification factor of 25 or higher. These numbers are often found in DNSSEC-enabled domains. Personally, I would worry if the amplification factor exceeds 5.
During one of the first tuning sessions on a BIND server hosting a DNSSEC-enabled domain we could bring the amplification factor down to 2.5.

Change your parameters

I highly suggest to change the mix of requested record types. This can reveal more details about the configuration and potential vectors for a DNS reflection attack.
  • Ask for mostly (or only) ANY records. These records are usually the most powerful ones to leverage a DNS reflection attack.
  • Ask for mostly (or only) non-existing records. This emulates are dictionary attack, where someone tries to find services like VPN-gateways or test-servers through a DNS enumeration.
  • Exclude ANY from the mix. Once you made sure, that your server does not respond to ANY, you don’t want to use the limit of 500 queries per second for something useful.
  • Change the run time. I found a few DNS servers where the rate limiting would only kick in after 30 seconds or more.

Change your view point

While developing DNShammer I found, that my ISP limits the number of UDP packets that I can send. I was constantly hitting a limit that oddly increased. Here is a typical result that I had when investigating one of Googles name servers:
ISP limiting UDP packets
Note that I received initially about 100 responses per second. Every 30 seconds the response rate went up by another 100 packets per second. I found this rather confusing. This looks like the server spills out more responses while it’s realizing that I am trying really hard to get some information. Clearly not, what I would expect from a reasonable rate limiting algorithm.
Things looked different when I switched to a different network. Note that I send 500 queries per second over a time of two minutes (60,000 requests in total). All 60,000 requests were answered, though come of the responses arrived a little late. The resulting graph quite exactly met my expectations.
Analysis without rate limit

Aborting a scan

You have probably noticed that the "Go!" button morphs into an "Abort" button as the test run starts. Of course, there are a number of reasons to abort a scan:
  • You notice, that the name server simply stopped responding after a certain time and don’t want to wait another two minutes for the next test run.
  • You want to change your query mix, destination IP or domain name after the test started (sorry, you can’t do this on the fly).
  • You are giving a presentation and don’t want to bore your audience with a slowly filling progress bar.
If you want to abort a running scan, just click "Abort", give it a few seconds to clean things up and you are set for the next run. During clean up, DNS Hammer will wait for responses that might be arriving late and close the network connections, that were opened for the scan.

Auditing Reverse Lookups

DNS can also translate an IP address to a host name, but only if the owner of the IP address has stored this information in a public database. Locating the hostname to a given IP address is called a "reverse lookup". This information is kept in the DNS database in a pointer record, PTR for short.
If you are the owner of an IP address block you have certainly seen remote IP addresses that try to locate a host name for all of your IP addresses. The scans hit your server like cosmic radiation: There is nothing that you can do about it. Except, of course, implement DNS rate limiting. While this will not block the scan, it slows the remote host down.
DNS Hammer can systematically request all pointer records for a given IPv4 subnet. The configuration options are somewhat limited as we only have to check for pointer records.
Reverse Lookup Configuration
Similar to the forward lookups, DNS Hammer enforces a few limits on reverse lookups:
  • The maximum rate is 500 requests per seconds.
  • The test duration is limited to 2 minutes.
  • A scan is limited to a 16-bit subnet mask. In other words: You can scan a maximum of 65.536 addresses.
The 16-bit subnet mask is not really a limit: A 2-minute test with 500 requests per second generates 60.000 requests. Please remember that the goal is not the complete enumeration of a subnet, but to test the rate limit configuration.

NS Finder

DNS can also translate an IP address to a host name, but only if the owner of the IP address has stored this information in a public database. Locating the hostname to a given IP address is called a "reverse lookup". This information is kept in the DNS database in a pointer record, PTR for short.
The NS Finder – short for "Name Server Finder" – can identify authoritative name servers for a given domain. Enter the target domain, click "Go!" and watch the results coming in.
The NS Finder will contact up to 5 name servers that are listed as "auxiliary name servers" in the window. By default, DNShammer will contact three well known and widely used open resolvers.
Here is how we use these name servers:
  • First the auxiliary name server is queried for an NS record. This will always return one or more hostnames for the authoritative name servers.
  • Next, we retrieve A and AAAA records that put an IP address to the name server hostname.
The table on the right will list the result. Right-click on any line to send this name server to the forward lookup page and commence testing.
In case you have to create a report about your findings you don’t want to retype the server’s hostname or IP address. Since typing an IP address (especially IPv6) is prone to errors I have added another function to the pop-up menu that will copy the hostname and IP address to the clipboard.

Using Auxiliary Name Servers

In very rare cases the domain might be served through an unusual load balancing construct. One example for this is an anycast network, where the resulting IP address depends on the client’s geographical location.
By using a different auxiliary name server, you may or may not reveal new authoritative name servers. You can either choose an auxiliary name server of your own or let DNShammer select them for you. Click the button "Pick Random Servers" to download a list of open resolvers from the web site public-dns.info. DNShammer will randomly select up to 5 IPv4 address from the list and use these for the next queries. The list will not be stored on disk.
Check the third column in the result table to see, if the new auxiliary name server finds a new host name or a new IP address for an authoritative name server. In most cases the column "Reported by" will have the same value.
The domain ciso.com is one example, where the auxiliary name servers report different results. Note that the IP address 173.37.146.41 is reported as ns1, ns2 and ns3. Overall, the names still point to the same set of IP addresses.
NS Finder for for cisco.com
Please note, that the auxiliary name servers have to be IPv4 addresses. While Windows can use IPv6 to send DNS queries to name server, I am simply too stupid to make the function DnsQueryEx work.
Here are a few links to publications, knowledgebase articles and presentations regarding DNS rate liming