How to compare DNS answers across resolvers with dig

Recursive DNS resolvers can return different views of the same name while caches, validation policy, filtering, or split DNS rules are still in play. Comparing resolver answers with dig keeps the question identical and changes only the server that receives it, which makes stale answers and resolver-specific differences easier to see.

The resolver is selected with the @server argument. Keeping the name, record type, and display options unchanged across every run lets the status line, ANSWER SECTION, TTL values, and SERVER line carry the comparison instead of mixing resolver behavior with a different query shape.

Use documentation-safe names for shared examples and incident notes unless the real hostname must be tested. Public resolvers are useful for a quick external view, but private enterprise resolvers, ISP forwarders, and split-horizon DNS can still return answers that public resolvers never see.

1. Choose one DNS question and a resolver list before running dig.

   name: example.com
   type: A
   resolvers: 1.1.1.1, 8.8.8.8

   Keep the name and record type unchanged for every resolver. Change only the @server value so answer differences belong to the resolver path.

2. Query the first resolver with answer, comments, TTL, and server statistics enabled.

   $ dig @1.1.1.1 example.com A +noall +comments +answer +stats +ttlid
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
   
   ;; ANSWER SECTION:
   example.com.        65  IN  A   172.66.147.243
   example.com.        65  IN  A   104.20.23.154
   
   ;; SERVER: 1.1.1.1#53(1.1.1.1)

   +noall hides unrelated sections first, while +comments, +answer, +stats, and +ttlid restore the fields needed for comparison.

3. Query the second resolver with the same name, record type, and display options.

   $ dig @8.8.8.8 example.com A +noall +comments +answer +stats +ttlid
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR
   ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
   
   ;; ANSWER SECTION:
   example.com.        300 IN  A   172.66.147.243
   example.com.        300 IN  A   104.20.23.154
   
   ;; SERVER: 8.8.8.8#53(8.8.8.8)

4. Compare the response status and answer set before reading the TTL.

   1.1.1.1: status NOERROR, A records 172.66.147.243 and 104.20.23.154
   8.8.8.8: status NOERROR, A records 172.66.147.243 and 104.20.23.154

   For multi-value records, compare the set of answer values rather than the printed order. A different order for the same values is not a resolver disagreement.

5. Read TTL differences as cache-age evidence after the answer set matches.

   1.1.1.1 TTL: 65 seconds
   8.8.8.8 TTL: 300 seconds

   Different TTL values are common when recursive resolvers cached the same answer at different times. A different status, missing answer, or changed record value matters more than TTL drift by itself.

6. Record the resolver comparison result.

   Compared name: example.com
   Record type: A
   Resolver result: same answer set, different remaining TTL
   Next action: wait and repeat only if a resolver returns a different status or answer value

   If one resolver returns NXDOMAIN, SERVFAIL, REFUSED, or a different address set, repeat the exact query against a third resolver before changing DNS records. A single resolver difference can come from cache timing, filtering policy, validation failure, or a local split-DNS rule.