DNS faults are solved by identifying which layer is wrong: registration, delegation, authoritative records, caching or the destination service. Randomly editing records usually makes the evidence harder to read.
Start with the symptom
| Symptom | First checks |
|---|---|
| Entire domain fails | Registration status, nameservers and authoritative answers |
| Website fails but email works | A/AAAA/CNAME, CDN and web host |
| Email fails but website works | MX, SPF/DKIM/DMARC and mailbox provider |
| Only some users fail | Resolver cache, IPv6, geography or split configuration |
| Certificate warning | Hostname coverage, certificate state and web-server binding |
Use the chain of evidence
- Confirm the domain is registered and not suspended.
- Identify the delegated nameservers.
- Query those authoritative nameservers for the affected record.
- Compare the answer with the intended configuration.
- Check cached public resolvers only after the authoritative answer is correct.
- Test the destination server or provider independently.
Common causes
- Nameservers were changed but the new provider did not contain the full zone.
- A root-domain record and www record point to different services.
- An obsolete AAAA record sends IPv6 users to an old server.
- MX priorities or hostnames were copied incorrectly.
- A CNAME was added where the control panel or DNS standard does not permit it.
- DNSSEC remains enabled with mismatched delegation after a provider move.
Do not hide the failure
Temporary hosts-file edits and browser cache clearing can help diagnosis, but they do not repair public DNS. Record the authoritative answer, exact time and affected networks before changing anything else.
Close the incident
After recovery, update the DNS register, remove abandoned records only after confirming they are unused, and document the root cause. If the outage followed a nameserver move, compare the complete old and new zones.
Information to collect before escalation
- The exact hostname and record type.
- The expected and actual authoritative answers.
- The nameservers currently delegated by the registry.
- The time the last change was made and the previous value.
- Whether IPv4, IPv6, website and email are affected separately.
- Examples from affected and unaffected networks.
This evidence allows the registrar, DNS host or service provider to investigate the correct layer instead of asking the business to repeat disruptive changes.
Final publication check
- The failure is described by hostname and record type.
- Authoritative answers are checked before cached resolvers.
- IPv4, IPv6, website and email are tested independently.
- The final root cause and corrective action are documented.
Sources and date checked
Technical and policy information was checked on 21 July 2026. Recheck provider-specific procedures before making a live change.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.