How to test DNS latency on Linux using the dig command

What is name resolution on the internet and why does it matter

When we type an address into our browser, the internet does not understand words like marciocunha.net; it requires numeric sequences known as IP addresses. This translation process is called name resolution and acts as the phone book of the global network. However, before any data packet travels across network routes, your computer must query a name server to discover where the website is hosted, a process that consumes precious milliseconds.

If this process takes too long, the entire browsing experience feels sluggish, even if your fiber optic connection is extremely fast. To diagnose bottlenecks and understand why certain pages take a while to start loading, we need to look inside network traffic and measure server response times. This is precisely where the dig command comes in, one of the most powerful and enduring utilities available for system administrators and enthusiasts who use Linux daily.

How the dig command works and its basic anatomy

The dig command, short for Domain Information Groper, is a command-line utility designed to interact with the Domain Name System, or DNS. Unlike simpler tools like ping, which only measure round-trip times for generic network packets, dig interacts directly with the name resolution protocol. It allows you to query specific zone records, such as A records for IPv4 addresses, MX records for mail servers, or TXT records for security validations, showing exactly what the server responded.

For anyone looking to optimize infrastructure, monitor connections, or troubleshoot corporate problems similar to those we solve when we track active TCP connections on Linux with ss, mastering dig is fundamental. In practice, when you run the command without advanced parameters, it interacts with the default resolver configured in your operating system, sending a structured query over UDP and waiting for the response packet to return.

Measuring real latency with the Query Time field

When we run a query in the terminal, the output printed on the screen brings a huge amount of technical information. For those who want to discover network speed, the most important line of the entire report is the Query Time, usually displayed near the bottom of the standard output. This value is measured in milliseconds and represents the exact time the queried server took to process the request and return the answer to our computer.

To see this in practice, open your terminal and run the following command:

dig marciocunha.net

When analyzing the response, look for the line containing the query time. If the value is below 30 milliseconds, the response is excellent. Values above 100 milliseconds indicate that the recursive server is geographically distant, overloaded, or that there are routing issues that can be investigated by learning how to inspect network routes with the mtr command on Linux.

Querying specific servers to compare performance

The great differentiator of dig is its ability to point to any name server in the world, temporarily bypassing the resolver configured by your internet service provider. This allows you to directly compare the performance of different public providers, such as Cloudflare, Google, or Quad9. To do this, simply add the @ symbol followed by the IP address of the server you want to test right after the domain name.

If you want to compare response times between different DNS infrastructures, use the following command structure:

dig @1.1.1.1 marciocunha.net

Repeating the same test with Google's IP, such as 8.8.8.8, will allow you to verify which one delivers the lowest latency from your current physical location. This practice is excellent for diagnosing whether perceived slowness in web applications is caused by an internal flaw in the local network or by an unstable public server.

Understanding the difference between recursive and iterative queries

To correctly interpret dig results, you need to understand the path data packets travel across the internet. When we ask a public server like 1.1.1.1 about a domain, it acts as a recursive server, meaning it assumes responsibility for fetching the complete answer if it does not have it in its cache memory. It first asks the internet root servers, then the top-level domain servers (like .net or .com), and finally the authoritative server of the website owner.

This cascading process generates varying response times. The first query a recursive server makes is usually slower, known as cache-miss latency, while subsequent queries respond almost instantaneously because the record is cached in memory. Understanding this dynamic prevents false network slowness diagnoses when the only factor at play is the natural expiration of the DNS record's time-to-live. To explore these architectural concepts further in production, see our related technical analysis on How to test a Zener diode on board with a multimeter.

Final thoughts on monitoring DNS latency

Testing DNS latency with the dig command goes far beyond a simple terminal exercise; it is an indispensable diagnostic skill to ensure the agility and reliability of any internet-connected service. By understanding how zone records are distributed and how to accurately measure recursive server response times, engineers and enthusiasts gain the autonomy to identify invisible bottlenecks that affect the end-user daily experience.

In short, mastering dig turns raw network data into actionable intelligence. Whether choosing the best public resolver for your home network or troubleshooting complex incidents in corporate environments, the command line remains the most faithful ally in the pursuit of a faster and more predictable internet.