DNS record investigation with dig cheat sheet
Compare DNS answers, authoritative servers, response codes and TCP fallback using dig.
BIND 9 dig on a host with access to the intended DNS resolvers. Queries send DNS traffic.
Updated · BIND · 6 min read
| Command | What it does |
|---|---|
dig app.example.com A | Query an IPv4 host record |
dig app.example.com AAAA | Query the IPv6 host record |
dig @192.0.2.53 app.example.com A | Query a chosen resolver |
dig example.com NS | Find nameservers advertised for a zone |
dig +tcp @192.0.2.53 app.example.com A | Repeat the query over TCP |
dig -x 192.0.2.25 | Inspect reverse DNS for an address |
Walkthrough
Replace app.example.com, example.com and 192.0.2.53 with approved names and resolvers. Compare results from the affected network; public and internal DNS can intentionally differ.
Step 1: Query an IPv4 host record
dig app.example.com A
Read the response status, answer section, TTL and responding server. NXDOMAIN and a timeout are different observations. A successful A answer does not establish application or TLS health.
Step 2: Query the IPv6 host record
dig app.example.com AAAA
Compare any IPv6 answer with the application’s supported network path. No AAAA answer can be expected for an IPv4-only service; an answer alone does not prove IPv6 reachability.
Step 3: Query a chosen resolver
dig @192.0.2.53 app.example.com A
Replace the documentation address with an approved DNS server and compare its response with the default resolver. Differences can result from split DNS, caches or resolver configuration.
Step 4: Find nameservers advertised for a zone
dig example.com NS
Record the returned nameserver names and TTL, then verify authority for the actual zone with the DNS owner. An NS answer from a recursive resolver can itself be cached.
Step 5: Repeat the query over TCP
dig +tcp @192.0.2.53 app.example.com A
Compare the TCP result with the normal query to help investigate transport filtering or truncated responses. A successful TCP query does not prove that every UDP path or application resolver works.
Step 6: Inspect reverse DNS for an address
dig -x 192.0.2.25
Replace the documentation address with an authorized target. PTR data can be absent or independently managed and should not be assumed to match the forward record.
WORKED INCIDENT
Practical case: Two clients receive different service addresses
Fictional teaching scenario; observations are examples, not captured production output.
Situation
An internal application resolves to different addresses from two client networks.
Investigation sequence
1. Query an IPv4 host record
dig app.example.com ACapture the default A answer and responding resolver from each client network.
2. Query a chosen resolver
dig @192.0.2.53 app.example.com AQuery the intended internal resolver explicitly and record the answer and TTL.
3. Query the IPv6 host record
dig app.example.com AAAACheck whether an IPv6 answer changes the application path.
4. Repeat the query over TCP
dig +tcp @192.0.2.53 app.example.com ACompare TCP DNS behavior if normal queries time out or are truncated.
Example findings
Illustrative findings: one resolver returns the intended internal address while another returns a public address for the same name.
Interpret the findings
Different answers support investigating resolver selection or split-horizon DNS. They do not by themselves establish which answer is incorrect or whether a cache is stale.
Verify the outcome
After the DNS owner applies the approved correction, repeat queries from the affected client and verify the application by its normal hostname.
Escalation handoff
Provide query time, client network, resolver addresses, response codes and TTLs to the DNS owner.