How to test DNS latency on Linux using the dig command

Why slow DNS paralyzes your application without you knowing

When we type an address into a browser or fire an API request, the system must translate that human-readable name into a numerical IP address. This invisible process, called name resolution, relies on a complex chain of servers distributed across the globe. If this communication fails or slows down, the user experiences that famous blank screen or inexplicable timeouts. In practice, this means your application might be perfectly healthy, but the time wasted waiting for a response from the name server strangles the final user experience.

To deeply investigate this behavior, engineers and system administrators turn to command-line tools capable of inspecting every detail of this message exchange. Among them, the dig (Domain Information Groper) command stands out as the ultimate Swiss Army knife for the job. Unlike simpler utilities, it allows you to directly interrogate the global name infrastructure, simulating the exact path a data packet takes to translate domains. In corporate networks or cloud environments, understanding how to master this tool is the turning point between guessing a problem and isolating its root cause in seconds.

How the dig command works and why it beats ping

Many people make the mistake of using the ping command when they suspect DNS issues. In practice, ping tests basic IP connectivity and route latency for an already resolved destination, but it hides the entire name translation process. When you type dig in the terminal, the tool sends a raw request and displays the raw response sent by the queried server. This includes not only the final IP address but also crucial metadata such as response time in milliseconds, packet size, and which intermediate servers participated in the conversation.

To better understand the impact of infrastructure bottlenecks, it is worth correlating these tests with complementary diagnostics, such as how to diagnose packet loss and high latency with mtr, ensuring a holistic view of network health. When we run the command without additional arguments, it queries the default resolver configured in the operating system, usually defined in the /etc/resolv.conf file. Observing the Query time field in the standard output footer is the first step to quantify sluggishness and discover if the name server is taking too long to process the request.

Isolating bottlenecks with targeted queries and the trace parameter

When resolving a specific domain takes seconds to respond, we need to find out exactly at which stage of the path the delay occurs. DNS operates hierarchically, starting from global root servers, passing through TLD servers (like .com or .org), and finally reaching the authoritative servers for the domain. The dig command features an extraordinary flag called +trace, which forces the tool to retrace this entire path step by step, displaying the time spent at each level of the hierarchy.

To run this detailed diagnostic in your terminal, execute the instruction below:

dig +trace example.com

Analyzing the output of this command will show you the response time of each DNS tree layer. If the delay is concentrated in the root or TLD servers, the problem lies in global infrastructure or upstream connectivity faults. On the other hand, if the slowness appears only when querying your company's local resolver or your ISP's IP, the bottleneck resides in internal configuration or the overload of that specific server. For scenarios where manual mapping needs to be tested before hitting the external network, you can also simulate local changes by checking how to configure the hosts file on Linux to redirect IPs and validate application behavior in a controlled environment.

Measuring actual latency of multiple DNS servers

Often, the problem isn't the network itself, but the chronic slowness of the DNS server your machine is using by default. To compare the performance of different public providers — such as Google (8.8.8.8) or Cloudflare (1.1.1.1) — against your own network server, you can direct the dig query explicitly to the desired IP by placing the address right after the @ character.

The procedure to compare response speeds between two different servers involves the following practical terminal steps:

1. Open your Linux terminal and query the Google server directly by running the command dig @8.8.8.8 marciocunha.net.
2. Note the value of the Query time field displayed in the footer statistics to understand the response time in milliseconds.
3. Repeat the query pointing to the Cloudflare resolver with the command dig @1.1.1.1 marciocunha.net and compare which one presented the lowest latency.

This simple test eliminates guesswork and allows you to scientifically choose which resolver to configure on your servers' network interfaces. If latency remains high even when using globally optimized public servers, the problem might stem from hardware bottlenecks or network card saturation, scenarios that often require additional I/O and processing validations, as explained in analyses of how to find Linux disk I/O bottlenecks to rule out underlying physical limitations.

Final considerations on DNS troubleshooting in Linux

Mastering the dig command transforms how you approach network incidents and slowness in Linux systems. Instead of accepting that the system is slow and blindly restarting services, using recursive queries, hierarchy tracing, and IP latency measurement allows you to isolate the problem with surgical precision. Whether identifying overloaded authoritative servers or choosing faster public resolvers, name layer observability is indispensable to guarantee the resilience of any modern infrastructure.

Maintaining the habit of inspecting DNS traffic saves hours of debugging and protects applications against intermittent failures that are hard to reproduce. By integrating these diagnostic practices into your engineering routine, you gain the autonomy to audit networks, validate cloud configurations, and deliver much more stable and fast services to end users.