A critical DNS alert lands in the inbox at 2am, and the difference between a five-minute fix and a full-blown incident often comes down to what happens in the first ten minutes after it arrives. This guide walks through exactly how to respond when DNSVigil flags a critical alert, what the different alert types actually mean, and how to build a response process that doesn’t rely on panic and guesswork.
Why critical DNS alerts demand a different response than routine ones
Not every DNS alert deserves the same urgency. A TTL that’s slightly out of policy or a minor SPF syntax warning can usually wait until business hours. A critical alert – typically a dangling CNAME pointing to an unclaimed cloud resource, an unexpected nameserver change, or a subdomain suddenly resolving to an IP outside your known infrastructure – is different. These are the conditions attackers actively scan for, and the window between “misconfigured” and “exploited” can be measured in hours, not weeks.
The core issue is that DNS misconfigurations don’t announce themselves the way a server crash does. Nothing looks broken from the outside. The subdomain still resolves, the page might even load something, and unless someone is actively watching DNS health, the problem sits there quietly until a bot or a researcher finds it first.
Step one: confirm the alert before touching anything
Before making any changes, verify what triggered the alert. Pull the specific record, check the current resolution, and compare it against your DNS documentation or asset inventory. This takes two minutes and prevents a common mistake: reacting to an alert that’s actually a false positive from a recent, legitimate infrastructure change (a CDN migration, a new load balancer, a provider swap).
If you don’t have documentation to check against, that’s a gap worth closing separately – having a clear record of what should be pointing where makes every future alert faster to triage. Documenting DNS infrastructure properly turns a ten-minute investigation into a thirty-second lookup.
Step two: classify what kind of critical alert it is
Critical alerts generally fall into a few buckets, and each needs a different playbook:
Dangling record pointing to a deprovisioned service – a CNAME or A record still pointing at a cloud resource (S3 bucket, Heroku app, Azure endpoint) that’s been deleted. This is the classic subdomain takeover setup. Priority: immediate.
Unauthorized nameserver or zone change – something modified the zone itself, not just a record. This could indicate compromised registrar or DNS provider credentials. Priority: immediate, and treat it as a possible account compromise, not just a DNS issue.
Missing or broken email authentication – SPF, DKIM, or DMARC suddenly failing validation. This opens the door to spoofed email from your domain. Priority: high, same-day.
Unexpected new subdomain appearing – something resolving that wasn’t there before, often from shadow IT or an unmanaged marketing tool. Priority: investigate before assuming malicious intent, but don’t ignore it.
Step three: contain before you investigate root cause
For dangling records and takeover risk specifically, the fastest safe move is usually to remove or repoint the record immediately, then investigate afterward why it was left behind. Don’t wait to fully understand the history of a stale CNAME before pulling it – every hour it stays live is an hour someone else could claim the underlying resource. Understanding how a subdomain takeover actually unfolds makes it obvious why speed matters more than a perfect audit trail at this stage.
If the alert indicates the resource has already been claimed by someone else – meaning the takeover already happened rather than being merely possible – the response changes. At that point it’s an incident, not a misconfiguration, and needs to go through formal incident response rather than a quick record edit.
Step four: escalate correctly for zone-level or credential incidents
Unauthorized nameserver changes or zone edits you didn’t make should never be handled as a routine DNS fix. Lock down registrar and DNS provider accounts, rotate API keys and credentials, enable or verify two-factor authentication, and check provider audit logs for the source of the change. This is a security incident that happens to manifest through DNS, and it should be treated with the same seriousness as a compromised admin account anywhere else in the stack.
Step five: document the resolution and close the loop
Once the immediate risk is handled, write down what happened, what triggered it, and what was changed to fix it. This step gets skipped constantly under time pressure, and it’s exactly why the same category of alert tends to recur at the same organization every few months. A short incident note – even five sentences – is enough to spot patterns later, like a particular team consistently spinning up subdomains without decommissioning them. For a structured approach to this, the incident response steps for a subdomain takeover apply well beyond the takeover scenario itself.
The myth worth retiring: “if the site still loads, it’s not urgent”
A surprisingly common assumption is that a DNS issue can’t be serious if the site or subdomain in question still appears to work. In practice, the most dangerous dangling records often resolve just fine – to a generic “not found” page hosted by whatever cloud provider now controls that address, or worse, to a page an attacker has already stood up to look legitimate. A record resolving without error tells you nothing about who actually controls the endpoint it’s pointing to. Urgency should be based on ownership verification, not on whether a browser renders something.
Frequently asked questions
How fast should a critical DNS alert be acted on?
Dangling records and unauthorized zone changes should be addressed within the same business day, ideally within hours. These represent active exploitation windows, not cosmetic issues, and delay directly increases risk.
What if a critical alert turns out to be a false positive?
Note it as such, but still check why it triggered – a false positive from a legitimate infrastructure change often means documentation is out of date, which is worth fixing so the next real alert isn’t second-guessed.
Should every critical alert be treated as a security incident?
Not automatically, but any alert involving zone-level changes, credential access, or evidence that an external party already controls a resource should move into formal incident response rather than being handled as routine maintenance.
Responding well to a critical DNS alert isn’t about having the fastest reflexes – it’s about having a clear, pre-agreed process so the response doesn’t depend on who happens to be on call that night. Building that process before the next alert arrives, rather than during it, is what actually keeps a misconfiguration from turning into a breach.