Hello, Who Are You, Won't You Tell Me Your Name!
Charly's Column – DNSDiag
If some transactions take an inexplicably long time, you don't have to blame yourself for the delayed transmission of user data. Name resolution issues might be to blame. Sys admin Charly has three tools to study the DNS server.
Pure randomness took me by the hand recently and led me to dnsping
, dnstraceroute
, and dnseval
. The tool collection for name resolution is entitled DNSDiag [1]. You need Python 3 and pip3
to install and run the trio and sudo
to let it create ICMP sockets.
dnsping
lives up to its name, repeatedly querying a DNS server and displaying the response times. The hostname to be resolved is a mandatory parameter. dnsping
prompts you for the system's default name server, which can be changed using -s <nameserver>
. After typing
sudo dnsping.py -v -s 8.8.8.8 linux-magazine.com
I queried a public DNS server from Google. Its responses took 20 milliseconds to reach me, four times more than my provider's DNS.
dnseval
queries several servers in parallel. As a competition judge, it presents the results so that you can immediately see which server responds fastest or slowest. I redirected the list of servers to be checked into a text file, with one server in each line. Lists of public DNS servers are easy to find; I used [2] and took the first five servers from the list. The call looks like this:
sudo dnseval.py -f ./liste.txt -c 5 linux-magazine.com
The result in Figure 1 shows a remarkable discrepancy between minimum and maximum response times.

Highwayman?
dnstraceroute
determines the path my DNS query takes to reach the target. By comparing this with a classic ICMP traceroute
, I can identify an attacker trying to kidnap my DNS queries. My test call is:
sudo dnstraceroute.py --expert --asn -C -s 8.8.4.4 linux-magazine.com
The result is shown in Figure 2. The --expert
parameter provides tips if something seems to be suspicious in the output – for example, if the target server is only a hop away from a private IP address (RFC 1918). False alarms also occur if you are not working on a cloud server, but locally, and a DNS cache such as Dnsmasq [3] is running on the router.

For each hop, the --asn
parameter shows you the autonomous system providing the network for the address. I can thus quickly see where the process crosses my provider's boundaries.
Infos
Buy this article as PDF
(incl. VAT)