Ask five people who can edit your DNS and you will usually get four different answers, all of them incomplete. The zone is edited by whoever set up the website, whoever moved the mail, the agency that ran a campaign three years ago, the developer who needed a subdomain for a demo, and the registrar's own interface when somebody clicks the wrong button during a transfer.
Most of those edits are fine. One of them, one day, is not — and the difference between a routine change and a hijack is not visible in the record itself. It is visible only against what the zone looked like yesterday.
Why zones drift
DNS is the one part of the stack with no pull requests, no diff, no review and, in most companies, no log that anyone reads. A few specific sources of drift show up again and again:
- Vendor onboarding. Every SaaS tool wants a CNAME or a TXT verification record. They are added quickly, under time pressure, by whoever has the login.
- Vendor offboarding. Almost nobody removes those records when the contract ends. The zone accumulates.
- Mail migrations. MX, SPF and DKIM records get rewritten during a move to a new provider — often by a consultant working from a template.
- Registrar and DNS host migrations. Zone imports are approximate. Records with unusual TTLs, wildcards or underscores are the ones that get dropped.
- "Just testing." A developer points a subdomain at a temporary host and moves on.
The changes that actually matter
Name servers
An NS change is a transfer of total control. Whoever the new name servers belong to decides where your website, your mail and your certificate validation go. There are exactly two explanations: a migration you planned, or an intrusion into the registrar account. There is no benign third option, which is why NS changes deserve to wake someone up.
MX records
A changed MX record reroutes inbound mail. An attacker who adds a low-priority MX of their own receives a copy of anything that fails over to it; an attacker who replaces the set receives everything. A vendor who changes it without telling you produces the same symptom as an attack — mail arriving somewhere you did not expect — which is why the alert should fire either way and be resolved by a human.
SPF, DKIM and DMARC
These records decide whether your mail is trusted. Somebody adding an include: for a new marketing tool can push you over the SPF lookup limit and break authentication for all of your mail — the failure mode described in the silent PermError. A DMARC policy quietly dropped from p=reject to p=none removes your protection against spoofing without breaking anything visible.
CAA
CAA records say which certificate authorities may issue for your domain. Adding one is a control; having one removed, or a new CA appended, is how someone quietly clears the way to obtain a valid certificate for a name they do not own.
Dangling CNAMEs
This is the one that turns housekeeping into a security problem. A subdomain points at a SaaS host — a storage bucket, an app platform, a help-desk — and the resource behind it is deleted while the CNAME stays. Anyone who can claim that resource name at the provider now controls content served from your subdomain, with your brand and, depending on how cookies are scoped, your users' trust. Phishing hosted on your own domain is very hard to explain to customers.
What breaks without it
- You find out from a customer. "Your site redirects somewhere strange" is the most expensive monitoring system ever invented.
- Mail is silently rerouted for as long as nobody compares the MX set to what it should be.
- Authentication decays. SPF, DKIM and DMARC records drift record by record until delivery gets worse for reasons nobody can reconstruct.
- Incidents have no timeline. Without a baseline you cannot answer the only two questions that matter afterwards: what changed, and when.
- Abandoned subdomains become someone else's publishing platform.
How to check it in 30 seconds
Run the DNS check. It queries the authoritative name servers directly — not a cache — and reports the delegation, whether every name server agrees, the SOA serial, and the records that matter for mail and web. For a quick manual look:
dig +short NS example.com dig +short MX example.com dig +short TXT example.com dig +short CAA example.com
Compare that against what you believe is deployed. If you have never written down what you believe is deployed, today's output is your baseline — save it.
Fix it
- Inventory the zone once, properly: every record, and who or what it is for. Delete anything nobody can justify.
- Hunt for dangling CNAMEs: for each CNAME pointing at a third party, confirm the resource still exists and is still yours.
- Restrict who can edit DNS, and use provider accounts with individual logins rather than a shared password.
- Enable two-factor authentication and the registrar transfer lock on the account that controls NS records.
- Publish CAA so only your CA can issue certificates.
- Keep a written baseline of NS, MX, SPF, DKIM selectors, DMARC and CAA — the set you expect to see.
- Re-check after every vendor onboarding and every offboarding.
Then keep it that way
A baseline in a document is only as fresh as the last person who updated it. Add the domain to StatusDNS and we take the snapshot for you: NS, MX, A, AAAA, SPF, DMARC and CAA records are read from the authoritative name servers on a schedule and compared with the previous run. When a set changes you get a diff showing exactly which values were added and removed, by email, Slack or webhook — NS and MX changes raised as critical, the rest as warnings, so the page at 3am is the one that deserves it.
We do not edit your DNS and we do not need credentials for your provider; everything here comes from public, authoritative queries. What the monitoring adds is simply memory — so a change made by a vendor on a Friday is something you read about on Friday, not something you reconstruct after the fact. If the change turns out to be a registrar problem rather than a vendor one, expiry and lock status is the next thing to check.