DNS Checker · one finding
Authoritative DNS lookup fails
Recommended action: Repair delegation, DNSSEC, or authoritative nameserver failures until recursive resolvers return a valid answer.
Fix principle: Resolve availability failures from the outside in: registry status and expiry, authoritative delegation, DNS answers, network/TLS reachability, and finally the HTTP application. Change only the first confirmed failing owner, and treat SPF/DMARC hygiene as mail-domain policy rather than a web-availability fix.
Implementation for your setup
Confirm first: The domain has a registry hold, redemption, pending-delete, or near-expiry state requiring registrar action. Authoritative DNS returns SERVFAIL, inconsistent answers, or lacks a record required for the intended service. DNS resolves but the origin cannot connect, returns persistent server errors/maintenance, or enters a broken redirect path. A domain that sends mail lacks the intended SPF or DMARC policy.
Do not apply when: The failure occurs only at one recursive resolver while authoritative DNS and multiple independent resolvers agree. The queried record is intentionally absent because the domain does not provide that service. A temporary application maintenance response is approved, bounded, and not a domain/DNS failure.
Likely control points: server · edge-cdn · content-data · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Steps
- Check the registry status and expiration first. Resolve holds, redemption, payment, verification, or nameserver problems with the registrar before changing application configuration.
- Query the authoritative nameservers directly and compare multiple recursive resolvers. Correct delegation, DNSSEC, missing/incorrect A/AAAA/CNAME records, or provider outages at the authoritative owner.
- Once DNS is stable, test TCP/TLS and the origin/edge response. Correct connection failures, persistent 5xx/maintenance states, or redirect loops at the layer emitting them.
- For a domain that sends mail, inventory every legitimate sender before publishing or tightening one SPF record and a DMARC record at `_dmarc`; begin DMARC enforcement only after reports show legitimate sources align.
Verify on this platform
- Confirm the registry status is active and the intended nameservers are delegated.
- Confirm authoritative and independent recursive answers converge after the relevant TTL.
- Request the site through the public hostname and confirm a successful, stable response without a redirect loop.
- Validate SPF and DMARC syntax and test legitimate mail flows before increasing enforcement.
Rollback
- Restore the prior DNS record set from an export if a change removes a working service; remember that cached answers persist until TTL expiry.
- Relax a newly tightened SPF/DMARC policy if verified legitimate senders fail, then inventory and align those senders before retrying.
Caveats
- DNS changes are not instant; cached records can make resolvers disagree until TTLs expire.
- SPF permits one policy record and has processing limits; blindly combining vendor snippets can create a permanent error.
- DMARC enforcement can reject legitimate mail when SPF/DKIM alignment is not ready. Start with reporting and measured rollout.
Official sources
Platform-managed / ask the vendor
Implementation is controlled by the platform or vendor.
Verify on this platform
- Ask the vendor to identify the authoritative layer, exact failing status, active configuration, propagation TTL, and rollback path.
- Verify registry, authoritative DNS, public HTTP, and mail policy independently after the vendor change.
Caveats
- Escalate immediately for redemption/pending-delete status or when no one controls the registrar account.
Official sources
How to verify
- Verify registry, delegation, authoritative DNS, recursive DNS, connection/TLS, and HTTP in that order.
- Wait through documented TTLs before treating recursive disagreement as a persistent failure.
- Test legitimate mail senders before tightening SPF or DMARC.
- Rerun DNS Checker and Website Down Checker after public propagation.
Escalate when
Escalate immediately for registry redemption or pending delete, lost registrar/DNS access, DNSSEC failures without a key owner, persistent multi-resolver SERVFAIL, or a mail-policy change whose legitimate sender inventory is unknown.