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 +answerFind the Authoritative Nameservers for a Domain
Start by asking DNS which nameservers are authoritative for the zone:
dig +short NS bitbook.ioExpected 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 +answerExample output:
bitbook.io. 300 IN A 172.67.161.127
bitbook.io. 300 IN A 104.21.66.155The 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.comqueries that specific DNS server instead of your default resolver.Aasks for IPv4 address records. UseAAAA,CNAME,MX,TXT, orNSfor other record types.+noall +answerhides the noisy parts ofdigoutput 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 +answerExample output:
bitbook.io. 300 IN A 104.21.66.155
bitbook.io. 300 IN A 172.67.161.127If 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.ioExample output:
eric.ns.cloudflare.com. dns.cloudflare.com. 2404990237 10000 2400 604800 1800The 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 +authorityNo 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 +answerCheck mail records:
dig @olga.ns.cloudflare.com bitbook.io MX +noall +answerCheck a TXT record, including SPF or verification records:
dig @olga.ns.cloudflare.com bitbook.io TXT +noall +answerCheck reverse DNS for an IP address:
dig -x 104.21.66.155 +noall +answerSafety 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.
