Detect DNS Spoofing: dnstraceroute

Another great tool from Babak Farrokhi is dnstraceroute. It is part of the DNSDiag toolkit from which I already showed the dnsping feature. With dnstraceroute you can verify whether a DNS request is indeed answered by the correct DNS server destination or whether a man-in-the-middle has spoofed/hijacked the DNS reply. It works by using the traceroute trick by incrementing the TTL value within the IP header from 1 to 30.

Beside detecting malicious DNS spoofing attacks, it can also be used to verify security features such as DNS sinkholing. I am showing the usage as well as a test case for verifying a sinkhole feature.

This blogpost is part of a series about DNSSEC. Refer to this list for all articles.

./dnstraceroute

To use dnstraceroute, the GitHub repository must be cloned, as already shown on other sites or on the official documentation:

1

2

3

git clonehttps://github.com/farrokhi/dnsdiag.git

cddnsdiag

git submodule update--init

Since dnstraceroute needs root privileges, it must be run with sudo (or the like). It basically needs the hostname to be tested against the first DNS resolver of the system. With other options the DNS server can be set manually
-s<server> or some expert information can be displayed
-x .

Here is a typical execution of dnstraceroute. I tested the domain “blog.webernetz.net” to the Google public DNS server 8.8.8.8:

Captured with Wireshark, it looks like this: Beginning with a TTL of 1, the value is incremented until the reply came. The ICMP time-to-live exceeded messages are displayed as the hops by dnstraceroute:

DNS Sinkholing

I am happy that my ISPs here in Germany are not spoofing my DNS queries. That is, I could not test such a scenario. (Refer to “Is Your ISP Hijacking Your DNS Traffic?” at RIPE Labs for such examples.) BUT, with dnstraceroute some “good” spoofing examples can be tested, too, such as DNS sinkholing. With this technique, next-generation firewalls such as the Palo Alto Networks firewall reply to DNS queries for malicious sites with a sinkhole IP address in order to protect the client before he even TCP-SYNed to the destination.

I tested a domain name that was listed as malicious with dnstraceroute. Obviously, the real 8.8.8.8 is not directly connected to my network ;), but listed as the first and only hop by dnstraceroute:

A look at the Wireshark capture shows the DNS query with a TTL with 1, but instead of an ICMP TTL exceeded reply, the Palo Alto firewall directly replied with the DNS sinkhole address:

Yeah, the DNS sinkholing works and dnstraceroute was able to verify it.

What it does not detect

Note that this tool does not detect false DNS answers from a correct DNS server. For example, though my German ISP “Deutsche Telekom” is not hijacking DNS queries, their DNS resolvers are answering with falsified A records for unregistered domains. Of course, this is a spoofed reply, but not from a man-in-the-middle but from the real DNS resolver.

In the following example I queried my home router (FRITZ!Box) which uses the DNS resolvers from Deutsche Telekom about “weberfoobar.de”, which does not exists. The DNS proxy is two hops away, so nothing seems to be wrong:

That is, such types of DNS spoofing must be detected with manual queries, e.g., with dig. Note that the Telekom DNS resolver answers with two A records, while the Google DNS resolver (correctly) has no answer: