DNS debugging with dig: authoritative DNS vs resolver cache, TTL, and NXDOMAIN

By the time a DNS failure shows up as a browser error, the cause is already scattered.
The A record might just be wrong. Or the authoritative DNS holds the correct value while only the recursive resolver’s cache is stale.
With a CDN in front, the name resolves fine but you get stuck at the proxy config or the certificate.

Gbemisola Esho’s “Understanding DNS” compares DNS to a phone book and stretches the picture out to its role as a security entry point, DNS tunneling, cache poisoning, performance, and redundancy.
What actually bites in operations, though, isn’t “what DNS is.” It’s figuring out which stage is returning a different answer.

The answer changes several times before it reaches the browser

Name resolution doesn’t fly straight from the browser to the authoritative DNS.
The OS cache, the router, the recursive resolver at your ISP or a public DNS, the TLD, and the authoritative DNS all get involved in order.

flowchart TD
  A[Browser] --> B[OS / router cache]
  B --> C[Recursive resolver]
  C --> D[Root DNS]
  D --> E[TLD DNS]
  E --> F[Authoritative DNS]
  F --> C
  C --> B
  B --> A

Right after you change the A record for www.example.com on Cloudflare, Cloudflare’s authoritative DNS may already return the new IP while your local machine still holds the old answer.
Looking only at the browser in this state, you can’t tell whether the change hasn’t propagated, the cache is still around, or the CDN is returning a different response.

Split where you look with dig.

# the answer through the resolver you're currently using
dig www.example.com A

# the answer through Cloudflare Public DNS
dig @1.1.1.1 www.example.com A

# the answer through Google Public DNS
dig @8.8.8.8 www.example.com A

# follow the delegation down to the authoritative DNS
dig +trace www.example.com A

As the BIND manual describes, dig +trace follows the delegation path from the root to the TLD to the authoritative DNS.
If you get the correct answer here, the domain-side configuration is mostly going through.
On the other hand, if @1.1.1.1 or @8.8.8.8 returns an old answer, you’re waiting on the recursive resolver’s cache.

TTL is not the same as the time you wait for propagation

TTL is the upper bound for “how many seconds may this answer be cached.”
Setting the TTL to 300 seconds in your DNS control panel doesn’t mean the whole world gets the same answer in 5 minutes.

In RFC 1034, every resource record has a TTL, treated as the time it can be held in cache.
The TTL the authoritative DNS returns is the original value, but the TTL you see through a recursive resolver counts down as the remaining time.
Run dig @1.1.1.1 www.example.com A against the same resolver a few dozen seconds apart, and if only the TTL drops, what you’re looking at is the cache, not the authoritative DNS.

If you were handing out an old record with a long TTL, any recursive resolver that received that answer holds it until expiry.
Shortening the TTL after the change doesn’t rewind the lifetime of an old answer that was already handed out.
Shorten the TTL before the switch, wait for the old TTL to drain, then change the A record or CNAME — that makes rollbacks easier to handle too.

Names that don’t exist get cached as well.
If you queried new.example.com before creating the new subdomain and got back NXDOMAIN, that “does not exist” answer also lingers for a while.
RFC 2308 organizes this as negative caching; in practice you read the SOA and TTL in the AUTHORITY SECTION of the NXDOMAIN response.

dig @1.1.1.1 new.example.com A
dig @1.1.1.1 example.com SOA

When “I created the A record but it still doesn’t resolve,” hitting the authoritative DNS directly may return the new A while going through a recursive resolver returns NXDOMAIN.
This isn’t a misconfiguration. It’s just the negative answer from before creation still lingering, and that’s how you split the cause.

In the V2Ray (WebSocket+TLS) server build notes, the flow was to create a subdomain on Cloudflare, wait for DNS to propagate, then run the installer.
When that step stalls, it’s faster to look at the authoritative DNS, the public resolver, and your local OS cache separately than to stare only at the installer failure.

Looking at the A record alone tells you nothing about mail or the CDN

For checking a website’s reachability, your eyes go to A and AAAA.
But once the same domain runs mail, a CDN, certificates, and external SaaS, a different record becomes the cause.

Record	When you touch it	Symptom on failure
A / AAAA	point a root domain or subdomain at an IP	site won’t connect, lands on an old server
CNAME	alias a CDN or hosting target	CDN validation never finishes, cert issuance stalls
MX	decide where mail is delivered	external mail won’t arrive, only same-domain mail fails
TXT	SPF, DKIM, DMARC, ownership verification	mail flagged as spam, SaaS domain verification won’t pass
CAA	restrict which CA may issue certificates	Let’s Encrypt or CDN cert issuance fails
HTTPS / SVCB	advertise connection parameters like HTTP target and ALPN	only the browser picks a different path, HTTP/3 or ECH behavior drifts
NS	decide the authoritative DNS for the zone	changing values in the control panel doesn’t reflect externally

In the WordPress same-domain mail delivery failure, even though MX pointed at Google Workspace, delivery stalled on the sending server’s own routing config.
Pointing MX at Google Workspace doesn’t help if the web server still has local delivery configured — only same-domain mail fails to go out.
After confirming the delivery target in DNS, you have to look at which SMTP path the app actually uses.

dig example.com MX
dig example.com TXT
dig _dmarc.example.com TXT
dig example.com CAA
dig example.com HTTPS

Mail in particular hits “the DNS records are correct but the app’s sending path is different.”
DNS triage isn’t the endpoint. It’s the material for deciding where to look next.

CAA is the record where the domain side declares “which CA may issue certificates” in DNS.
RFC 8659 defines CAA as a mechanism the CA checks before issuing a certificate.
When the site resolves but only the certificate won’t issue, look at CAA in addition to A and CNAME.

DNS as a security boundary is coarse but fast

The original article treats DNS as a choke point for stopping an attack at its early stage.
If the recursive resolver refuses to resolve a name before the device connects to a malicious domain, it never gets as far as the HTTP request or the TLS handshake.

That said, what DNS tells you is basically “which name was being looked up.”
If a malicious path lives inside the same legitimate domain, DNS alone can’t distinguish it.
Conversely, when an attacker uses throwaway domains, they get through before the blocklist updates.

DNS tunneling reads the same way.
It’s a technique where a device queries a flood of long subdomains like abcd1234.attacker.example and packs data into the query name.
Watching only the destination IP, it looks like ordinary DNS queries — but the length of the query names, their randomness, the ratio of NXDOMAIN, and the run of queries to the same parent domain make it easier to catch as an anomaly.

DNS is tied to the permission boundary in browser-driving MCPs too.
The DNS rebinding covered in the Playwright MCP article was an attack that changes the name resolution result of an external domain to a local IP after the fact, letting the browser touch internal services.
In this type, the URL string is an external domain, but the destination IP switches to a local address later.
You constrain the post-resolution IP range, the Host header, the Origin, and reachability to local addresses together.

DNSSEC detects tampering; it doesn’t guarantee reachability

DNSSEC comes up as a countermeasure against cache poisoning.
DNSSEC signs the records the authoritative DNS returns so the recursive resolver can verify those signatures.
Even if a fake IP is mixed in along the way, signature verification rejects it.

These commands are enough to look at it.

dig example.com A +dnssec
dig example.com DS
dig example.com DNSKEY

What DNSSEC protects is that the name resolution response hasn’t been tampered with.
Server compromise, CDN misconfiguration, expired certificates, and app vulnerabilities all remain in other layers.
RFC 4033 also describes DNSSEC’s scope as data origin authentication and data integrity.
Confidentiality of traffic, server safety, and the availability of the name resolution service itself are not DNSSEC’s job.

Get signing-key rotation or DS record updates wrong, and name resolution fails only from the resolvers that validate.
In that case, look separately at a validating resolver, a query with validation suppressed, the parent zone’s DS, and the child zone’s DNSKEY.

dig @1.1.1.1 example.com A +dnssec
dig @1.1.1.1 example.com A +dnssec +cd
dig example.com DS
dig example.com DNSKEY

In the article on standing up VLESS + REALITY with Xray-core alone, I confirmed whether REALITY returns the certificate of the disguise target with openssl s_client.
That check is a TLS-layer matter, not DNS.
Even if the correct name resolves in DNS, if the SNI, the certificate, and the proxy’s termination point are misaligned, the externally visible behavior breaks.

Triage works backward from the authoritative DNS

When you’re stuck on DNS, working backward from the authoritative DNS is less confusing than digging forward from the browser.

# list of authoritative DNS
dig example.com NS

# point at the authoritative DNS directly and look at the A record
dig @ns1.example-dns.com www.example.com A

# look at the answer and TTL through a recursive resolver
dig @1.1.1.1 www.example.com A

# look at the answer your local OS sees
dig www.example.com A

If the authoritative DNS returns a different answer, look at the zone config.
If the authoritative DNS is correct but the recursive resolver is stale, it’s a TTL wait or the resolver’s own cache.
If the recursive resolver is also correct but only the browser fails, suspect the OS cache, the browser’s DNS cache, the HTTPS record, the proxy, the certificate, and the app’s own destination.

“DNS is a phone book” is easy to grasp as an entry point, but what works during change windows and incident response isn’t the phone book’s contents. It’s checking, from the authoritative DNS side, which stage still holds an old page.