How to test DNS resolution and response time with dig

What is DNS and why you need the dig command

When we type a web address into our browser, an invisible operation called name resolution takes place. The Domain Name System, or simply DNS, acts as the internet phonebook, translating easy-to-remember names like marciocunha.net into IP numbers that machines understand. In practice, when this translation fails or lags, the website appears offline even if the server itself is completely healthy.

To investigate these bottlenecks, system administrators and tech enthusiasts rely on the dig command, which stands for Domain Information Groper. Unlike simpler tools, dig does not just guess the answer; it interacts directly with naming infrastructure to show exactly what is happening at every step of the journey. This surgical capability makes it essential when we need to audit network connections and traffic bottlenecks.

Understanding key DNS records in practice

Before opening your terminal, it helps to understand the most common record types you will query. The A record is the most basic, mapping a domain name to an IPv4 address. Meanwhile, the CNAME record acts as an alias, pointing a subdomain to another primary domain, which is very useful when using third-party services.

Another critical record is MX, responsible for telling mail servers where to deliver your domain's emails. If your MX record points to the wrong place, your messages simply vanish into the digital void. Knowing these three record types is the starting point for any efficient troubleshooting session in the terminal.

How to run your first basic query with dig

The simplest use of dig consists of typing the command followed by the domain name you want to investigate. In your Linux or macOS terminal, run the command below to see the full response provided by the default servers configured in your operating system.

dig marciocunha.net

Upon pressing enter, you will see a large amount of information divided into sections. The most important part for quick diagnosis is the answer section, which displays the final IP address found, alongside the query completion time and the server that answered the request.

Diagnosing propagation issues by changing the query server

One of the biggest nightmares for website managers is updating a server's IP address and noticing that some users are still hitting the old machine. This happens due to DNS propagation time and cached entries spread across internet service providers worldwide. To find out if the change has reached a specific server, we can use the @ symbol followed by the target server IP.

For instance, if we want to ask Google's public servers directly, we can run the command below. This technique allows real-time response comparisons to figure out if your local provider is still stuck on an outdated version of your domain records.

dig @8.8.8.8 marciocunha.net

If the IP returned by Google differs from your local server, you have confirmation that propagation is delayed or local cache needs to expire. This clarity saves hours of guesswork regarding infrastructure and service configurations.

Measuring latency and server response time

The time a DNS server takes to reply directly affects how fast websites start loading in the browser. At the footer of standard dig output, there is a line called Query time, measured in milliseconds. If this number is too high, say above two hundred milliseconds, your visitors will experience noticeable lag before the first HTML file even begins downloading.

To investigate response time without cluttering your screen, we can use output modifiers. The following command filters the output to display strictly the time spent on the operation, easing automated tests or quick performance comparisons between different DNS providers. To explore these architectural concepts further in production, see our related technical analysis on How to clean Docker cache and free up disk space.

dig marciocunha.net +stats | grep 'Query time'

Final Thoughts

Mastering the dig command transforms how we handle connectivity and web infrastructure issues. Instead of guessing where errors lie, using this terminal tool correctly reveals whether the problem stems from incorrect records, delayed propagation, or slow name servers. With practice, such troubleshooting becomes automatic and indispensable in technical daily routines.

Keep in mind that the health of your online presence relies on a stable and predictable network ecosystem. Making a habit of inspecting A, CNAME, and MX records ensures your applications and email services remain accessible and operate at optimal speeds for the end user.