Check Authoritative DNS vs Resolver Cache with dig

mike

6 hours ago

Search-intent target: how to check whether DNS has changed at the authoritative nameserver or if a public resolver is still serving cached DNS.

If you just changed a DNS record, check the authoritative nameserver first, then compare it with one or two public resolvers. The authoritative answer tells you what is actually configured at the DNS host. Public resolvers like Cloudflare or Google can still return an older answer until the previous record's TTL expires.

dig +short NS bitbook.io
dig @olga.ns.cloudflare.com bitbook.io A +noall +answer
dig @1.1.1.1 bitbook.io A +noall +answer
dig @8.8.8.8 bitbook.io A +noall +answer

Find the Authoritative Nameservers for a Domain

Start by asking DNS which nameservers are authoritative for the zone:

dig +short NS bitbook.io

Expected output looks like this:

olga.ns.cloudflare.com.
eric.ns.cloudflare.com.

Those are the servers you should query directly when you want the source-of-truth answer. If the domain uses Route 53, DigitalOcean, NS1, Cloudflare, or another DNS provider, this command should show that provider's nameservers.

Query the Authoritative Nameserver Directly

Now ask one authoritative server for the record you care about:

dig @olga.ns.cloudflare.com bitbook.io A +noall +answer

Example output:

bitbook.io.        300    IN    A    172.67.161.127
bitbook.io.        300    IN    A    104.21.66.155

The number after the hostname is the TTL in seconds. In this example, resolvers may cache the answer for up to 300 seconds. If you changed this record one minute ago, some users may still see the old answer for a few more minutes.

The useful flags:

@olga.ns.cloudflare.com queries that specific DNS server instead of your default resolver.
A asks for IPv4 address records. Use AAAA, CNAME, MX, TXT, or NS for other record types.
+noall +answer hides the noisy parts of dig output and prints the answer section only.

Compare Public Resolver Cache

After checking the authoritative answer, compare public resolvers:

dig @1.1.1.1 bitbook.io A +noall +answer
dig @8.8.8.8 bitbook.io A +noall +answer

Example output:

bitbook.io.        300    IN    A    104.21.66.155
bitbook.io.        300    IN    A    172.67.161.127

If the authoritative nameserver shows the new IP but 1.1.1.1 or 8.8.8.8 shows the old IP, the change is probably made correctly and you are waiting on resolver cache. If the authoritative nameserver still shows the old IP, the DNS change did not land where the domain is actually delegated.

Check the SOA Serial and Negative Cache TTL

For debugging stale or missing records, check the SOA record:

dig +short SOA bitbook.io

Example output:

eric.ns.cloudflare.com. dns.cloudflare.com. 2404990237 10000 2400 604800 1800

The last number is commonly used as the negative cache TTL. In the example above, a resolver may cache a "record does not exist" answer for 1800 seconds. That matters when you create a brand-new subdomain and some resolvers still say NXDOMAIN.

Debug a Subdomain That Does Not Resolve

If a new subdomain is failing, query the exact record against an authoritative nameserver:

dig @olga.ns.cloudflare.com api.bitbook.io A +noall +answer +authority

No output in the answer section usually means the authoritative DNS provider does not have that record. Add +authority so dig can show which zone answered the request:

bitbook.io.        1800    IN    SOA    eric.ns.cloudflare.com. dns.cloudflare.com. ...

That tells you the request reached the right zone, but the requested record is not present.

Use dig +trace When Delegation Is Suspect

When the domain appears pointed at the wrong DNS provider, trace delegation from the root:

dig +trace bitbook.io A

+trace walks from the root DNS servers to the TLD servers and then to the domain's authoritative nameservers. This is useful when the registrar shows one nameserver set, the DNS host shows another, or a recent nameserver change is only partly visible.

Some office networks and VPN resolvers interfere with full trace output. If +trace returns very little, repeat the direct checks above from another network or a server with normal outbound DNS access.

Troubleshooting Variants

Check a CNAME:

dig @olga.ns.cloudflare.com www.bitbook.io CNAME +noall +answer

Check mail records:

dig @olga.ns.cloudflare.com bitbook.io MX +noall +answer

Check a TXT record, including SPF or verification records:

dig @olga.ns.cloudflare.com bitbook.io TXT +noall +answer

Check reverse DNS for an IP address:

dig -x 104.21.66.155 +noall +answer

Safety Notes

These dig commands are read-only. They do not change DNS records.

The risky part is reacting too quickly. Before deleting or replacing records in Cloudflare, Route 53, registrar DNS, or another provider, verify the domain's current authoritative nameservers with dig +short NS example.com. Editing records at a DNS provider that is not authoritative for the domain will not affect live traffic, and deleting the wrong live record can break mail, web traffic, or certificate validation.

Quick Decision Table

What you see	Likely meaning	Next check
Authoritative server has new value, public resolver has old value	Resolver cache	Wait for old TTL, then retest
Authoritative server has old value	Change was not applied at live DNS host	Check DNS provider and zone
Public resolvers disagree	Cache is expiring unevenly	Compare TTLs and retest
Authoritative query returns no answer	Record missing or wrong type	Query `A`, `AAAA`, `CNAME`, `TXT`, or `MX` explicitly
`+trace` stops early	Network resolver interference or blocked DNS path	Retry from another network/server

Uniqueness Check

This draft was checked against the current BitBook WordPress post titles on pages 1 and 2 of the public REST API. Existing nearby posts cover curl headers, mtr, netstat, nmap, SSH, and logrotate, but there is no current BitBook title focused on using dig to compare authoritative DNS with resolver cache.