Quick Answer: To debug DNS, use dig for granular, authoritative record analysis or nslookup for quick, universal verification. Use dig +trace to follow the path from root servers down to the authoritative source. If results vary between servers, you have a propagation or synchronization issue.
Why DNS Debugging Matters?
When you type a domain into your browser, the site appears. There is a lot going on behind the scenes. Your computer is talking to servers all around the world. If this conversation breaks down, your site will not work.
Usually, people think the problem is with the server or the network. Most of the time, the hardware is okay. The problem is with the DNS, which is like a phone book for the internet. If the phone book has the number, you will not get to where you want to go.
To fix DNS problems, you need to know what is going on. You need to see what the nameserver says when you ask it something. Tools, like dig and nslookup, help you do this. They let you ask the servers directly, instead of relying on what your browser remembers. This way, you can see what is really happening with your domain.
Defining DNS Debugging Tools
So you want to know about DNS Debugging. DNS Debugging is when you ask the servers, the ones that know everything, to help you figure out what is going wrong. You do this to fix DNS problems, such as when servers do not agree on something or when changes take a long time to show up. You use DNS Debugging to find out what is wrong with the nameservers, the ones that’re in charge of telling people where to find your website.
Dig (Domain Information Groper):
The industry-standard tool for network administrators. It returns raw, detailed responses from DNS servers, allowing you to see the full “answer” section, including TTL values and authoritative source data.
Nslookup:
A legacy utility still bundled with most operating systems. It is simpler and less detailed than Dig, making it useful for basic tasks, though it lacks the granular control needed for complex network diagnostics.
Comparison: Dig vs. Nslookup
| Feature | Dig (Domain Information Groper) | Nslookup |
| Output Detail | Highly verbose, raw format | Concise, simplified |
| Control | Granular flag support (+trace, +short) | Limited interactivity |
| Standard Usage | Preferred for professional diagnostics | Best for quick, casual checks |
| Default Availability | Linux/macOS (Unix-based) | Universal (Windows/Linux) |
| Recommended for | Senior Sysadmins & DevOps | Basic user troubleshooting |
Step-by-Step: Debugging DNS with Dig
If you are using a Unix system, the program dig is usually the best option. The reason for this is that dig handles complex queries. It is actually better at this than any available graphical user interface tools. When you need to do something, Dig is the way to go because it can handle complex queries much better than other tools.
Perform a standard lookup:
by typing “dig example.com”. This sends a query to your system’s default resolver. Check the “ANSWER SECTION” to see if the IP address matches your expectations.
Query a specific server:
If your local resolver is cached or unreliable, bypass it. Use the dig @8.8.8.8 example.com command to query Google’s Public DNS directly. Replace 8.8.8.8 with your authoritative nameserver’s IP to test if the record exists on the source.
Trace the delegation path:
If you suspect your domain is not resolving due to a delegation error, run dig +trace example.com. This performs a recursive lookup, showing you the exact chain of servers from the Root (.) down to the TLD (.com) and finally to your authoritative nameserver.
Check for specific records:
To verify your mail setup, use the dig example.com MX command. To check for text records (like SPF), use the dig example.com TXT command.
Look at the raw headers:
if you need to see exactly what the server is sending, omit the flags. The “FLAGS” section in the output (e.g., qr, rd, ra) indicates whether the server is authoritative or just passing on a cached result.
Debugging with Nslookup
While dig is superior for detail, nslookup is always available. If you are stuck on a machine without dig installed, use this workflow.
- Standard Query: Type nslookup example.com. You will get the address of the server used to find the record, along with the result itself.
- Switch to Interactive Mode: Type nslookup. You enter a prompt to set types. Type set type=mx and then the domain name to query specifically for mail records.
- Debug Mode: Use set debug. This forces the tool to show you the packet header information. It is significantly messier than dig, but it provides enough detail to see whether the server is returning an error code.
Use Cases: Who Needs These Tools?
The DevOps Engineer:
You just migrated a massive application to a new IP address. You need to verify that your nameservers are serving the new records before you shut down the old infrastructure. You use dig +short across multiple global nodes to ensure parity.
The Security Auditor:
You suspect your DNS has been hijacked. You use dig to inspect the SOA (Start of Authority) record and the NS (Nameserver) records. If the authoritative nameservers listed are not the ones you configured, you have confirmed a compromise.
The Email Administrator:
Users complain they aren’t receiving mail. You use nslookup or dig to verify that your MX records point to the correct mail gateway and that your SPF records are correctly formatted.
Security and Best Practices
Your security stack has many components. People often forget about the Domain Name System. If you do not pay attention to the Domain Name System, it is like leaving your door open. This makes it easy for someone to do a man-in-the-middle attack on the Domain Name System. The Domain Name System is a part of your security, so you should not ignore it.
- Verify Authoritative Sources: Never trust your local ISP’s cache during a migration. Always query your authoritative nameserver directly using @ syntax to verify the record is live at the source.
- Watch for Delegation Errors: If dig +trace fails before it hits your nameserver, your issue is at the registrar level—not your server. Check your glue records immediately.
- Check Time-To-Live: When you debug, look at the Time-To-Live. If it is high like 86,400 seconds, your updates will not show for 24 hours. Lower it before you plan maintenance.
- Verify NS Records: Make sure your NS records match those your registrar has. If they do not match, your site may fail at times.
Troubleshooting Common DNS Errors
| Problem | Likely Cause | Fix |
| NXDOMAIN | Record does not exist | Create the A record |
| SERVFAIL | Nameserver unreachable or misconfigured | Check firewall/nameserver logs |
| REFUSED | Recursion not allowed | Allow queries from your IP |
| NOERROR (empty) | Record exists but is wrong type | Match query type to record type |
| Timeout | Network filter or down server | Ping the nameserver IP |
Conclusion: Mastering Your Network
Debugging the Domain Name System is an important skill for any network administrator. When you do not rely on your browser to tell you a website is not found and instead use tools like dig or nslookup to inspect the traffic yourself, you can see how the internet really works. The Domain Name System is, like a mystery that becomes clear when you use these tools.
- Start at the source: Query your authoritative nameservers directly.
- Verify the path: Use dig +trace to ensure delegation is intact.
- Check for consistency: Use dig @server to ensure all nameservers return the same record.
Here is the thing: even if you do a good job of debugging, the internet can still cause problems because of its cache. You can double-check that your records are correct. Some people will still see the old information until the global time-to-live expires. Do not worry about this. Fix the problem at the source, set the time-to-live for changes, and give the network some time to update. You can use the tools on dnsrecordschecker.com to make it easier to check how your DNS looks on parts of the internet, so you can be sure that what you see is what everyone else sees.
Frequently Asked Questions
Why does dig return different IPs than nslookup?
When you use dig and nslookup, they might be asking computers for information. This can happen if your system has more than one computer that helps answer questions about websites, such as a local computer and your internet service provider’s computer. In this situation, dig and nslookup might be asking computers for help. To make sure you get information from both dig and nslookup, always specify the computer to query using the @ symbol. This way, you can be sure that you are comparing the information from both dig and nslookup.
What does the “AD” flag mean in dig output?
“AD” stands for Authenticated Data. It’s a stamp of approval from the DNS server saying, “I’ve checked the digital signature (DNSSEC) for this record, and it’s valid.” It essentially tells you the data hasn’t been tampered with or intercepted in transit. If you see it, you can trust the response is authentic.
Can I use dig to test TTL propagation?
Absolutely. TTL stands for Time-To-Live. It acts like an expiration date for the record. To check if a record is cached, I run a dig query. Note the TTL value. Then I run it again a second later. If the TTL number decreases over time, I am looking at a cached record. The record is likely from a cache. If the TTL remains unchanged, I am probably hitting the authoritative source directly. That means I am getting the information from the source.
Is Dig available on Windows?
Native dig isn’t included in Windows, so don’t waste time looking for it in Command Prompt. It won’t be there. If you need it, the best way to get it is by installing the Windows Subsystem for Linux (WSL). Once you have that, you get the standard Linux dig tool, which works perfectly, exactly as it does on a server.
What is the difference between recursion and iteration?
Think of it like getting a document from a company.
Recursion: You ask a manager, and they go get the document for you, doing all the legwork until they hand it over.
Iteration: You ask a receptionist, and they point you to the file room. You go there, they point you to a specific shelf, and you find the document yourself.
In DNS, recursion means your server does the searching for you; iteration means it gives you a referral to the next server in the chain, and you keep digging. dig +trace lets you see that iterative process in action.
Why does my dig query say “connection timed out”?
This is a loud-and-clear sign that your request is being blocked. DNS queries almost exclusively use UDP port 53. If the server is ignoring your request or a firewall is dropping the packet, your query will hang and eventually time out. Check your local firewall rules or verify that the DNS server you’re querying is actually up and listening for traffic.
Latest Posts