DNS Records Changed Unexpectedly

Two different failures land on this page, and the first thing to do is work out which one you have. Both are DNS, but the questions they ask are opposite: one is “who changed this?” and the other is “why is there no answer at all?” The fix steps are split into a branch for each — read the symptoms below, then follow only the branch that matches.

Symptom

Records changed. A DNS monitor compared the live answer against the records you told it to expect and found a difference — a record missing, an unexpected one present, or a value that no longer matches. The incident names each one.

Nothing resolved. A monitor failed with the error category dns. The hostname did not resolve from our checker, so no request was ever made. Your browser may still load the site perfectly from a cached answer.

Likely causes

If records changed:

Somebody made a legitimate change and nobody updated the monitor. A deploy, a CDN cutover, a new mail provider. This is by far the most common cause, and it is worth ruling out first.
You changed it minutes ago and resolvers still disagree with each other.
Your DNS host moved you between nameserver sets, or migrated your zone.
A registrar transfer or an expiry reset the zone, often to a parking page.
Someone with registrar access repointed the domain. Rare, but this is the case the monitor exists for. A hijack that changes MX and TXT and leaves A alone is quieter than one that takes the website, and does more damage.

If nothing resolved:

The record or the whole zone was deleted.
Your DNS provider is having an outage, or your nameservers are refusing queries.
The domain expired and the registry pulled the delegation. Check Domain Registration Expiring before you debug anything else — an expired domain looks exactly like this.
DNSSEC is broken. A stale DS record at the registrar makes validating resolvers refuse to answer while non-validating ones keep working. This is the classic “it works from my laptop” split.
A typo in the monitored hostname. Check it before you check anything else.

Fix steps

If your records changed

Your DNS monitor found a difference between the records it expects and the records that are live.

Ask whether it was you. Check the incident’s expected-versus-actual list against your recent changes and your team’s. If the new values are the ones you intended, this is a monitor that needs updating, not an incident.
Query the authoritative nameserver directly, bypassing every cache:
Terminal window
```
dig +short NS example.com
dig +short A example.com @$(dig +short NS example.com | head -1)
```
That is the truth. Everything else is a cache of it.
Compare two public resolvers:
Terminal window
```
dig @1.1.1.1 +short A example.com
dig @8.8.8.8 +short A example.com
```
Disagreement means propagation is still in progress and time will fix it. Agreement means the change is real and already global.
If the change was intentional, update the monitor’s expected records. Do not mute the monitor — a muted DNS monitor will not tell you about the next change either.
If the change was not intentional, treat it as a compromise. Change the passwords on both the registrar and the DNS host, turn on two-factor authentication at both, enable the registrar’s transfer lock, and check MX, TXT, and NS before you assume only the A record was touched.

If nothing resolves at all

A check failed with the error category dns and there are no expected records to compare against — the hostname simply has no answer from our checker. Work downwards from the delegation.

Start at the delegation. dig NS example.com with no answer means the problem is above your DNS host — at the registrar or the registry. Check the domain’s registration status first, then the nameservers recorded at the registrar.
If the delegation is fine, ask those nameservers for the record itself:
Terminal window
```
dig +short A example.com @$(dig +short NS example.com | head -1)
```
Empty output from the authoritative server means the record does not exist at the source, and no amount of waiting will produce one.
Test for a DNSSEC failure:
Terminal window
```
dig +dnssec example.com
dig +cd example.com
```
A SERVFAIL from the first and a clean answer from the second (checking disabled) means DNSSEC validation is failing. Fix the DS record at your registrar to match the key your DNS host is publishing, or remove the DS record entirely if you are no longer signing the zone.

Prevention

Turn on registrar lock and two-factor authentication at both the registrar and the DNS host. They are frequently different accounts, and the weaker one decides your security.
Update the monitor’s expectations in the same sitting as the DNS change. Ten minutes later you will not remember; a week later you will assume the alert is noise.
Lower TTLs before a planned change and put them back afterwards. A permanently low TTL makes every resolver outage yours.
Monitor MX, TXT, NS, and CAA, not just A. Mail hijacks and certificate-issuance hijacks both happen in records nobody watches.
If a URL monitor keeps failing with dns but the site is fine for you, see False Positives for how to tell a resolver problem from a network-path problem.