How to measure DNS latency in Linux with tcpdump

In this case I was trying to identify which DNS resolver would be the best for my infrastructe in remote sites.

Usually configuring 8.8.8.8 would be ok, yes is simple, but there are a couple of things going on in the background that deserves some checking if you want to achieve best performance. Which was my case since we have high perfomance robots in the remote sites infrastructure.

So the first step is to measure right? If you don’t measure you don’t know if you are improving or even what to improve.

In the remote sites I only and a very small Linux distro running in routers and luckly tcpdump was included. So creating a shell script was the way to go.

You can find the script here.

The script will measure DNS response latency from multiple remote providers and the local router which has a DNS daemon included.

It uses TCPDUMP timestamps with microsecond fractional resolution, then capture the traffic while issuing 3 nslookup query per provider, discard first nslookup which is usually higher because DNS cache might not exist yet, and finally calculate the average.

Basically script will match 2 lines (these number of tests can be customized in the script)and calculate the time difference based on the network timestamps. These network timestamps is the more precise meassure you can get, since it eliminates any CPU/memory influence at the local host.

I’m going to compare the resolution latency for 3 providers and local.

1. Google 8.8.8.8
2. Cloudflare 1.1.1.1
3. Cloudflare Family 1.1.1.3 <— this is super cool and free service which includes Malware and/or adult content filter by blocking the DNS request. Check it at this link.
4. And my local Router 172.21.192.1.

Now caching is a key component in DNS resolution, because the resolver will keep a local cache of the IP address the first time it send the query, and then it will not ask again to the authoritative DNS resolver for that record as long as the TTL is not expired. Instead it will reply with the local cached value. We will see that in action in a second.

Below is the script output, and from there I will comment the important parts and a conclusion.

Pay attention to the Response time for Test 1 of each provider. They all take longer than the rest of the tests, because is the first query and they need to forward the query to the root resolver of the record. The following 2 tests will always be lower because they use their cache.