DNS is not a phone book in the sky. It is a chain of caches asking authoritative servers for typed records. Once you see that chain, “the domain is broken” becomes a short list of testable failures.
🎙️ Published & recorded:
Your browser does not normally ask the owner of a domain. It asks the operating system, which asks a recursive resolver. On a cache miss, that resolver walks from the root to the top-level domain and then to the domain's authoritative nameserver. The authoritative answer is the source of truth; everything before it is a cache or a signpost.
browser → OS cache → recursive resolver
↓ cache miss
root → .com → authoritative nameserver
↓
api.example.com. 300 IN A 203.0.113.10A points a name at an IPv4 address. AAAA points it at IPv6. Browsers may prefer IPv6, so a stale AAAA record can break only some users while every IPv4 test looks healthy. Do not publish AAAA because the control panel offered a box; publish it only when that address serves the site.
example.com. 300 IN A 203.0.113.10
example.com. 300 IN AAAA 2001:db8::10
api.example.com. 300 IN A 203.0.113.40
# inspect each family separately
dig example.com A +short
dig example.com AAAA +shortdig AAAA, then test over IPv6. Changing the A record again is busywork.A CNAME says one name is another name. It does not copy an IP; resolvers continue and look up the target. That is excellent for www and service subdomains. It is awkward at the zone apex, the bare example.com, because the apex must also carry SOA and NS records, while a standards-compliant CNAME cannot coexist with other data.
www.example.com. 300 IN CNAME sites.host.example.
Error: CNAME record is not allowed at the zone apex
# Fix: use the provider's ALIAS/ANAME or CNAME flattening feature,
# or use A/AAAA values supplied by the host. Do not delete apex NS/SOA.ALIAS, ANAME and “flattening” are provider features, not ordinary DNS record types. They synthesize address answers at the apex. That distinction matters when moving DNS providers: the feature may not move with the zone file.
TXT records are strings attached to names. Email systems use them for SPF, DKIM and DMARC; services use them to prove domain ownership. The hostname matters as much as the value. A verification token placed at the apex will not satisfy a checker asking for _acme-challenge.example.com.
example.com. IN TXT "v=spf1 include:_spf.mail.example ~all"
_acme-challenge.example.com. IN TXT "R4nd0m-proof-token"
selector1._domainkey.example.com. IN TXT "v=DKIM1; p=MIIB..."
# Query the exact owner name the service requested
dig TXT _acme-challenge.example.com +shortdig TXT. DNS dashboards often append the zone automatically, so entering the full name can create _acme-challenge.example.com.example.com. Correct the owner field; do not keep regenerating tokens.TTL is how many seconds a resolver may reuse an answer. A 3600 TTL means “cache this for up to an hour.” It does not promise that a new record appears in one hour. If you plan a migration, lower the TTL before the change and wait out the old TTL. Lowering it after the change cannot recall answers already cached.
# Answer includes TTL in the second column
$ dig example.com A +noall +answer
example.com. 2874 IN A 203.0.113.10
# 2874 seconds remain in this resolver's cached copyDNS does not spread outward like wet paint. Authoritative servers publish data; recursive resolvers cache answers until TTL expiry. When somebody says “wait 48 hours,” ask which resolver has which answer and how long its TTL has left. Very often, waiting for propagation is the wrong diagnosis: the record is in the wrong zone, the delegation points elsewhere, or the authoritative answer is already wrong.
# Ask public recursive resolvers
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
# Ask an authoritative server directly
dig @ns1.dns-host.example example.com A +noall +answer
# Trace delegation from the root
dig +trace example.comdig NS example.com and edit the provider they actually name.NXDOMAIN is stronger than “there is no A record.” It says the queried name does not exist in DNS. An existing name with no record of the requested type is a different response: NOERROR with an empty answer. That distinction catches typos, accidental double suffixes and missing subdomains.
$ dig api.example.com A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41822
# Diagnose
dig example.com NS +short # correct delegation?
dig @ns1.dns-host.example api.example.com A # source of truth?
dig api.example.com A +trace # where does it fail?SERVFAIL is not “server returned no website.” A resolver or authoritative server failed to produce a usable DNS answer. Common causes are broken DNSSEC after a provider move, unreachable authoritative nameservers, timeouts, a lame delegation, or a CNAME loop. DNSSEC is the first place I look after nameservers changed, but it is not the only meaning of SERVFAIL.
$ dig example.com A
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9351
# If normal validation fails but this returns an answer, suspect DNSSEC
dig +cdflag example.com A
# Inspect delegation and authoritative reachability
dig +trace example.com
dig @ns1.dns-host.example example.com SOAdig exposes status, flags, TTL, answer, authority and responding server. nslookup is installed on most Windows machines and is fine for direct record checks. Always name the record type and, when comparing behavior, name the resolver.
# dig
dig example.com A
dig example.com MX +short
dig @1.1.1.1 example.com AAAA
dig +trace example.com
# Windows-friendly nslookup
nslookup -type=TXT example.com 1.1.1.1
;; communications error to 10.0.0.53#53: timed out
;; no servers could be reached
# This is not NXDOMAIN. The configured resolver is unreachable.
# Check VPN/firewall/network DNS, then compare: dig @1.1.1.1 example.com.nslookup may say *** UnKnown can't find api.example.com: Non-existent domain. “UnKnown” often means the resolver's IP lacks reverse DNS; it is not the failure. “Non-existent domain” is NXDOMAIN. Test the authoritative server to decide whether the name is missing or merely negatively cached.Start at the source of truth, then move toward the user. This order prevents cache folklore from wasting an afternoon.
1. dig NS example.com # who is authoritative?
2. dig @authoritative name TYPE # what is the source saying?
3. dig @1.1.1.1 name TYPE # what is a recursive cache saying?
4. compare status, answer and TTL # NXDOMAIN? SERVFAIL? stale value?
5. dig +trace name # only when delegation is suspicious
Authoritative wrong → edit the actual authoritative zone.
Authoritative right, recursive old → wait only for the shown TTL.
SERVFAIL → inspect DNSSEC, delegation, reachability, loops.
Timeout → resolver/network path, not “propagation.”My blunt rule: never change a DNS record until you can state which server gave the bad answer. DNS is observable. Guessing is optional.