Troubleshooting DNS: a systematic checklist, not random guessing
Every lesson so far in this domain has named its own specific failure mode in passing — wrong nameservers, a missing TXT record, an apex CNAME that was never valid to begin with. This lesson collects them into one actual, ordered checklist, the thing you reach for at 11pm when something that was working isn't anymore.
Intermediate
3 min read
The checklist, in the order that actually finds the problem fastest
Step 1: confirm which nameservers are actually authoritative, right now
dig example.com NS +short
This answers lesson 2's exact confusion directly — if the returned nameservers aren't the ones you expect (your DNS provider's, not your registrar's defaults, or vice versa), every other step below is irrelevant until this is fixed, since you've been editing records in a place nothing is actually asking.
Step 2: confirm the specific record exists, at the provider the nameservers actually point to
dig example.com A +shortdig www.example.com CNAME +short
Run this directly against the DNS provider nameservers returned in step 1 actually point to — not against your own ISP's resolver, which might have a stale cached answer that has nothing to do with whether the record is configured correctly right now.
Step 3: check propagation globally, not just from your own network
whatsmydns.net — checks the SAME query from dozens of
geographically distributed resolvers at once
Networking Fundamentals' own TTL lesson already explained why a change doesn't propagate instantly — different resolvers around the world cache independently, and your own ISP's resolver having the new answer doesn't mean every resolver does yet. A tool checking from many locations simultaneously distinguishes "genuinely not propagated everywhere yet, just wait" from "configured wrong, and no amount of waiting will fix it."
Step 4: for a platform-specific domain (Vercel/Railway/Render), check THAT platform's own verification state
A DNS record being technically correct doesn't always mean the platform has re-checked and re-verified it yet — most platforms cache their own "is this domain's DNS correct" check rather than re-verifying on every single request, so a genuinely fixed DNS record can take a few minutes to be reflected in the platform's own dashboard status, separate from DNS propagation itself.
Step 5: for HTTPS specifically, confirm DNS first, then check certificate status separately
Lesson 4 and lesson 5 already established this ordering explicitly: HTTPS activation is downstream of DNS verification, so jumping straight to "why won't the certificate issue" before confirming steps 1-4 are genuinely settled is the single most common wasted-effort path — the certificate usually isn't broken; the DNS underneath it hasn't actually resolved correctly yet.
Why this order, specifically, finds real problems faster than random guessing
Each step rules out an entire category of cause before moving to the next, genuinely narrower one — checking certificate-issuance logs before confirming nameservers are even correct means potentially debugging a system that was never going to work regardless of what it reports, because the actual problem was one layer earlier. This ordered approach is the same systematic-diagnosis discipline this curriculum's other domains have applied to debugging generally, applied here specifically to DNS's own particular failure shapes.