What to Do When DNS Monitoring Alerts You

You get an alert at 11pm: an A record on your domain changed. You didn't touch anything. Nobody on your team mentioned a deployment. Now what?

Some DNS changes are routine — a CDN update, a mail provider migration, a verification record added by a SaaS tool. Others are serious: a misconfiguration that's silently breaking something, or a sign that someone accessed an account they shouldn't have. Here's how to tell the difference.

Determine if you made this change

Before investigating the DNS itself, check with your team. Was there a deployment? A migration to a new server or CDN? A support ticket that involved a DNS change? Most alerts have a mundane explanation — someone made a change and didn't tell anyone, or a tool updated a record automatically.

If you use a DNS provider with an audit log, check it now. Cloudflare, Route 53, and most other providers record who changed what and when. If the change is in the log and the account and timing are recognizable, you have your answer. If the change isn't in the log — or the log shows it came from an unrecognized IP or account — treat it as unauthorized and skip to When to escalate immediately.

How to check the current record value

To see what a specific public resolver currently returns — this bypasses your local resolver's cache, though the remote resolver may itself return a cached answer:

dig @8.8.8.8 example.com A
dig @8.8.8.8 example.com MX
dig @1.1.1.1 example.com NS

To query your authoritative nameserver directly — authoritative nameservers don't cache, so this gives you the current record without any caching layer in between:

dig @ns1.example.com example.com A

To check what multiple resolvers around the world currently see, dnschecker.org gives you a geographic spread without installing anything.

What different record types signal

Not all DNS changes carry the same risk. Here's what to look for based on which records changed.

A and AAAA records

An A or AAAA record maps a hostname to an IP address. If this changes:

• Expected cause: server migration, new load balancer, or CDN onboarding.
• Unexpected cause: an attacker with access to your DNS provider has redirected traffic to a server they control. Visitors to your site would reach a different server without knowing.

If you don't recognize the new IP, do a reverse lookup (dig -x <ip>) and run a quick whois on it. Be cautious about concluding the IP is legitimate just because it falls in a CDN or cloud provider's range — those ranges are shared across millions of customers. The real test is whether the endpoint actually serves your content correctly.

NS records

NS records are the highest-severity DNS change. They tell the entire internet which servers are authoritative for your domain — every other record flows through them.

NS records exist in two places. Your DNS provider holds NS records as part of your zone file — these are what OneDollarDNS observes changing. A separate copy lives in the TLD registry, controlled via your registrar — this is the delegation that tells resolvers which nameservers to query in the first place. A change to your zone's NS records might reflect a planned nameserver rename or secondary NS addition at your provider. A change to your delegation NS records at the registrar is the more dangerous scenario: it means someone may have pointed the world at nameservers they control.

If NS records change without a planned provider migration, act immediately: check both your DNS provider and your registrar account for unauthorized access, rotate your credentials, and review whether any certificates were issued for your domain during the window (check crt.sh). See What NS Records Are for the full picture on what an unauthorized NS change can enable.

MX records

MX records control where email for your domain is delivered. A change here means either a mail provider migration or — if unexpected — a deliberate attempt to intercept your email.

If someone has access to your DNS provider, redirecting your mail is straightforward. Check your email provider's dashboard to confirm which mail servers should be listed for your domain, and compare that against what the alert shows.

TXT records

TXT records carry a lot of different information: SPF authorization, DKIM signing keys, DMARC policy, domain verification tokens for SaaS tools, and more.

An unexpected TXT change is often benign — a teammate connected a new tool and added a verification token. But it can also mean someone removed your SPF record (making your domain vulnerable to spoofing), weakened your DMARC policy, or changed a DKIM public key. If a DKIM record changes, DKIM verification will start failing for recipients receiving your mail — not something you want to discover from a bounce report. Check what specifically changed and whether it affects email delivery or domain security.

CNAME records

A CNAME record is an alias — it points a hostname to another hostname rather than directly to an IP. A change here typically means a service migration: a new CDN, a different subdomain routing to a different backend.

If the CNAME changed to point to an external hostname you don't recognize, someone may have redirected your subdomain to a host they control. Verify the new target is a service you own or have intentionally delegated to.

There's a second CNAME risk that won't trigger a change alert: subdomain takeover. This happens when a CNAME hasn't changed but its target has become unclaimed — a deleted Heroku app, an abandoned S3 bucket, a cancelled third-party service. An attacker can claim that service in their own account and start serving content from your subdomain without changing any of your DNS records. It's worth periodically auditing your CNAME targets for services that are no longer active.

Record disappearances

A record that disappears is often more urgent than a record that changes, because the consequence is immediate breakage: a site that stops loading, email that starts bouncing, a service that loses its verification and deactivates.

Common causes: an accidental deletion, a zone import that overwrote your records, or a bulk edit gone wrong. Less common: an attacker removing records to cause disruption. Either way, if a critical record disappears, restore it — OneDollarDNS keeps a history of every value it's observed for each record, so you can look up exactly what the record contained before it disappeared. Once restored, investigate how it was removed.

When to escalate immediately

Some changes can wait until morning. Others can't.

Escalate immediately if:

• NS records changed and you didn't migrate DNS providers
• An A record changed to an IP you don't recognize
• An MX record changed and you didn't migrate email providers
• You can't find any record of the change in your provider's audit log
• The change correlates with other suspicious activity (unexpected logins, password reset emails you didn't request)

These scenarios share a common thread: they suggest that someone may be in a position to intercept traffic, intercept email, or issue fraudulent certificates on your behalf. Time matters because attackers who have already changed your records can act quickly — and the longer the change sits, the wider the window.

Can wait until business hours if:

• The change matches what a teammate or tool was known to be working on
• The audit log shows a change from a known account at a reasonable time
• It's a TXT addition whose value matches a recognizable service pattern — many tools add a token like google-site-verification=… or atlassian-domain-verification=… when you first connect a domain
• An MX or A record changed to values that match what your current provider documents as their standard records

After you've investigated

Once you know what changed and why, log it — in your team's runbook, incident tracker, or wherever you document infrastructure changes. This takes two minutes and saves future you from reinvestigating the same alert. If you've connected a tool that automatically modifies DNS records, note which records it manages.

If the change was unauthorized, the investigation doesn't end at reverting the record. Rotate credentials, audit account access, check for issued certificates, and review what the records pointed to during the window. The record history in OneDollarDNS gives you the exact timeline of what changed and when.