`dig` Should Be the First Tool You Use When a Domain Looks Broken Before You Blame the App
A practical dig guide for developers who need to inspect DNS answers, check specific resolvers, and separate domain issues from application issues before wasting hours in the wrong layer.
Why DNS bugs waste so much time: when a domain fails, people often start at the application layer because that is where they feel comfortable. Sometimes the app is fine and DNS is lying to them upstream.
Why dig matters
The BIND documentation describes dig as a flexible DNS lookup utility, and that is exactly why it stays essential. DNS problems are rarely solved by pinging a domain once and declaring it mysterious. You need to ask better questions:
- what record is being returned
- by which resolver
- with what TTL
- is the answer consistent across resolvers
That is what dig gives you.
The simplest useful command
dig example.comThis already tells you a lot more than a browser error page. But in practice, most developers quickly benefit from a few slightly more targeted variants.
Use +short when you want signal, not ceremony
dig +short example.comNow you get a terse answer instead of the full diagnostic output. This is great when you just want to see the returned IPs quickly.
Check a specific record type:
dig +short example.com MX
dig +short example.com TXTThis matters because the question is often not “does DNS exist?” The question is “is the exact record I need actually there?”
Query a specific resolver on purpose
If you suspect resolver inconsistency:
dig @1.1.1.1 example.com
dig @8.8.8.8 example.comNow you are comparing actual upstream answers instead of assuming your local resolver is representative of the world.
This is a crucial debugging move when deployments have just changed, TTLs are in play, or one network sees different answers than another.
Why +trace is sometimes the right escalation
If you need to follow delegation:
dig +trace example.comThis is not the first command for every issue, but it is useful when you need to understand where DNS authority and delegation are breaking down. It turns “the domain seems weird” into a more specific path through the DNS hierarchy.
A practical debugging flow
When a domain looks broken:
- ask for the exact record you expect
- compare answers across resolvers
- check whether the result is short-lived or cached
- escalate to
+traceif the delegation path is suspicious
That sequence is much better than immediately redeploying the application and hoping the symptom moves.
Why application teams misdiagnose DNS
Because DNS issues often present as app issues:
- SSL provisioning fails because the record is wrong
- webhook callbacks miss the right host
- staging points at old infrastructure
- one region resolves differently than another
When you only inspect app logs, you can miss that the name resolution itself is the unstable layer.
Why small DNS checks prevent big wasted effort
A two-minute dig session can save an hour of redeploys, cache purges, and speculative app changes. That is why the command belongs near the start of the debugging chain. If the name resolves incorrectly, nothing above that layer will behave consistently anyway.
Final recommendation
If a domain or endpoint looks broken, run dig before rewriting application code or redeploying in frustration. Use +short for quick answers, query specific resolvers when consistency matters, and escalate to +trace when you need to understand the delegation path. DNS becomes less mystical once you start asking exact questions.