DNS Deep Dive
Nothing propagates
"Wait 24-48 hours for DNS to propagate" describes something that never happens. No server pushes your change anywhere. When you edit a record, the authoritative server is correct immediately — every other resolver in the world is simply still holding an answer it cached earlier, and it will keep serving that answer until its TTL expires.
This makes migrations predictable if you plan them. Lower the TTL to 60 seconds at least one full old-TTL period before the cutover, do the switch, confirm, then raise it again. Skipping the first step is what turns a two-minute change into a two-day one.
Record types worth knowing
| Type | Answers with | Gotcha |
|---|---|---|
| A / AAAA | IPv4 / IPv6 address | Multiple A records give round-robin, not health checks |
| CNAME | Another name | Not allowed at the zone apex — use ALIAS/ANAME instead |
| NS | Delegation to nameservers | Must match at both parent and child, or resolution breaks |
| SOA | Zone metadata | Its minimum field sets the negative cache lifetime |
| TXT | Free-form text | SPF, DKIM and domain verification all live here |
Negative caching bites during launches
If someone queries a name before you create it, the NXDOMAIN answer gets cached for the SOA minimum — commonly 900 seconds, sometimes a full day. Create the record a minute later and it can still look missing to anyone whose resolver holds that negative entry. This is why testing a hostname "to see if it is ready yet" during a launch can work against you: you are populating negative caches. Create the record first, test after.
Debugging commands
# What does my resolver say, and how long is the TTL?
dig api.example.com
# Ask the authoritative server directly — bypasses every cache
dig @nina.ns.cloudflare.com api.example.com
# Watch the whole delegation chain, level by level
dig +trace api.example.com
# Just the answer, for scripts
dig +short api.example.com
# Is the negative answer cached? Repeat and watch the TTL count down
dig missing.example.com | grep -A2 AUTHORITY
# Which nameservers does the parent zone advertise?
dig NS example.comThe one to reach for first is dig +trace: it shows exactly which level of the tree returns something unexpected, which is usually a parent and child NS mismatch after a registrar change.
