Stage 1 — Confirm the symptom
Start by reproducing the failure from a clean network and a fresh resolver. If the failure disappears on a different network, the problem is local resolver state, not the authoritative record. This single check eliminates roughly half of false DNS incidents.
Stage 2 — Compare resolver answers
- Recursive resolvers. Query at least two (1.1.1.1, 8.8.8.8) and confirm they agree.
- Authoritative answer. Compare to the record at the registrar / DNS provider — the canonical source of truth.
- TTL inspection. Know your cache horizon before declaring anything propagated.
Stage 3 — Validate record correctness
Look at the record type that matches the symptom: A/AAAA for web, MX for mail, CNAME for vendor-hosted endpoints, TXT for verification and SPF/DKIM. Many incidents are not "DNS down" but the wrong record class for the use case.
Stage 4 — Promote to monitoring
The moment an issue is resolved, the hostname should join a continuous monitor. Repeated DNS incidents on the same hostname are a workflow problem, not bad luck — monitoring closes that loop.