How to troubleshoot DNS failures on Linux step by step with dig

Why DNS fails and how dig helps with diagnosis

When a website fails to open in the browser or an application cannot talk to an external service, the blame almost always falls on DNS, the system responsible for translating human-readable domain names into numerical IP addresses that computers understand. In the Linux ecosystem, the most powerful tool to investigate this behavior is the dig command, which stands for Domain Information Groper. Unlike simpler commands like ping, dig does not just test if the destination responds, but opens the black box of name resolution to show exactly where the process is getting stuck.

In practice, this means you can completely bypass your machine's cache and ask the source directly, whether it is your internet service provider's server or the domain's official infrastructure. In complex infrastructure scenarios, understanding network health saves hours of frustration and complements other essential auditing routines, such as when you need to audit active network connections with the ss command to check for open ports and stuck connections waiting for a response.

Making your first direct query with dig

To start using the utility, you do not need administrator privileges on the system. Just open the terminal and type the command followed by the domain name you want to investigate. The generated output is a complete report containing the header section, the question asked, the answer obtained, and network performance statistics.

An important point when analyzing the standard output is to observe the answer section, where the final IP address associated with that name appears. If the command returns a valid IP quickly, the access problem in your application might be elsewhere, such as in firewall rules or application layer bugs. Otherwise, if the return takes too long or fails, dig provides the necessary status codes to understand whether the domain simply does not exist or if the queried server is offline.

How to isolate issues by changing the name server

One of the command's greatest advantages is the ability to point the finger at a specific DNS server using the at sign right after the domain. This technique is essential when you suspect that the server automatically configured by your router or provider is unstable or corrupted. By directly querying trusted public servers, you immediately discover whether the problem is local or global.

To execute this test in practice, use the recommended structure below in your terminal:

dig @8.8.8.8 marciocunha.net

In this example, we are bypassing our local network servers and asking Google's public servers directly. If the query returns the correct result immediately, it becomes clear that your local network or company's default DNS server is failing and needs to be replaced or investigated.

Investigating response times and network latency

Sluggishness when loading pages or connecting to APIs is often not caused by a lack of broadband, but by delays in the name server's response. The footer of the output generated by dig displays crucial information, such as the total time the query took in milliseconds, the port used, and the size of the transmitted packet.

If you notice response times exceeding two or three hundred milliseconds on basic queries, there is a strong indication of throttling on the network route or physical overload in the queried server's infrastructure. This type of thorough diagnosis is the first step before making deeper changes to machine configuration, such as when we decide to set a static IP on Linux using NetworkManager to standardize network interface behavior and fix reliable primary and secondary DNS servers.

Discovering corrupted records and tracing the complete path

Some trickier problems involve corrupted DNS records, where an intermediate server stores outdated or malformed information. To trace each step of the resolution process, from the internet root servers to the domain's final authoritative server, we use the trace flag in the command.

Here is how to run the complete trace step by step in the terminal:

1. Open your Linux terminal and type the tracing command with the trace flag to inspect all stages.

2. dig +trace marciocunha.net

3. Follow the detailed flow ranging from global root servers to the final domain registrar.
4. Identify at which exact layer the response time spiked or if there was a delivery failure for the specific record.

This step-by-step view shows exactly which intermediate server failed to respond or returned incorrect data, allowing you to notify the responsible administrator or flush the poisoned cache.

Conclusion and best practices in DNS debugging

Isolating network infrastructure problems in Linux stops being a mystery when we master surgical tools like dig. The ability to query specific servers, measure exact latencies, and trace the complete path of name resolution puts the control of stability back into the hands of the engineer or systems administrator. Integrating these verification routines into your daily workflow ensures that intermittent failures are identified and fixed before they impact end users or take down production services.

Keeping the habit of testing name resolution in isolation prevents wasting time changing configurations blindly. Combine these analyses with constant monitoring of connections and routes to build a highly resilient, predictable, and easy-to-debug infrastructure environment.