Check DNS With dig Before Changing It

Photo: Unsplash.

When a DNS change appears inconsistent, changing the record again usually adds another variable. A few targeted dig queries can show which layer still has the old answer.

Begin with the resolver currently configured on the machine:

dig example.com A
dig example.com AAAA

The ANSWER SECTION shows the returned records and remaining TTL. The SERVER line shows which resolver answered. For compact output during repeated checks:

dig +noall +answer example.com A

Then ask a known public recursive resolver to separate local caching from the wider DNS view:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Do not treat agreement between public resolvers as proof that the authoritative zone is correct. Find the nameservers delegated for the domain:

dig +short example.com NS

Query one of them directly:

dig @ns1.example-dns.net example.com A

An authoritative answer should include the aa flag in the header. If the authoritative server has the new value while recursive resolvers return the old value, waiting for cached TTLs is usually the correct action.

Follow the delegation

+trace walks from the DNS root toward the authoritative servers:

dig +trace example.com A

This is useful for delegation mistakes, but the output is longer and network policies may block the direct queries it performs. For a suspected DNSSEC issue, add +dnssec and inspect the status rather than disabling validation as a first response.

Record the query name, record type, server queried, answer, and time. DNS incidents become confusing when screenshots omit the resolver or when commands alternate between A, AAAA, and CNAME without saying so.

The important habit is to ask one layer at a time: local resolver, another recursive resolver, delegated nameserver, then the delegation path. Only edit the zone after the incorrect layer is identified.

Reference

• BIND 9 Administrator Reference Manual