Stale Trust in DNS: The Records Attackers Hunt For

← Back to Blog

Verisign recently put a name to a problem security teams have quietly lived with for years: stale trust. In their framing, it is the gap between the credentials your systems trust and the credentials that are actually still trustworthy. Their focus is certificate revocation. When a certificate is revoked but a client checks its status against cached data, the client keeps trusting it. Verisign notes that depending on how a service is implemented, that validation data can be as much as 10 days old.

It is a useful idea, and it applies well beyond certificates. The same pattern, trust granted once and never re-checked, is one of the most common and most exploited weaknesses in DNS. The difference is that in DNS, the stale data is not cached for 10 days. It often sits in your zone for years.

What stale trust looks like in DNS

Every DNS record is a statement of trust. A CNAME says "this subdomain is whatever that provider says it is." An NS record says "that name server speaks for this zone." An SPF include says "that vendor may send email as us." Each of those statements was true on the day someone created it.

The trouble starts when the underlying relationship ends but the record stays. A team retires a marketing microsite, cancels a help desk subscription, or moves DNS hosting to a new provider. The service goes away. The DNS record that trusted it does not.

That leftover record is stale trust, and attackers actively hunt for it.

Five places stale trust hides in your zone

1. Dangling CNAME records

This is the classic case. A subdomain such as support.example.com points to a cloud or SaaS resource that has since been deleted. If an attacker can register that same resource name at the provider, they control what your subdomain serves, under your brand and your domain's reputation. We cover the mechanics in detail in our guide to dangling DNS and subdomain takeover.

This is not theoretical. In February 2025, Infoblox traced pornographic and scam URLs on a CDC subdomain back to a CNAME still pointing at an Azure website the agency had abandoned. The actor behind it, which Infoblox named Hazy Hawk, had been hijacking subdomains of government agencies, universities, and large corporations since December 2023.

The scale is larger than any single incident. A peer-reviewed study presented at USENIX NSDI 2024 tracked dangling resource abuse from 2020 to 2023 and found 20,904 hijacks hosting malicious content across 12 cloud platforms, with the number of concurrently hijacked domains rising throughout the study period. SentinelOne reports that over a single year it alerted its clients to more than 1,250 subdomain takeover risks caused by deprovisioned cloud resources.

2. Lame and dangling NS delegations

An NS delegation hands authority for a domain or subdomain to a specific DNS provider. If your account at that provider has lapsed, or the zone was never created there, the delegation is "lame." At some providers, anyone can then create an account, claim your zone, and publish whatever records they like.

Infoblox and Eclypsium named this the Sitting Ducks attack. Their research found that more than 35,000 domains have been hijacked this way since 2018, and more than a million domains are exploitable on any given day. A dangling NS record is arguably worse than a dangling CNAME, because the attacker does not control one hostname. They control the entire zone beneath it, including its mail records. We looked at a large real-world case of this in 163 brands hijacked through abandoned DNS delegations.

3. SPF includes for vendors you no longer use

Your SPF record is a list of everyone you trust to send email as your domain. Organizations add includes as they adopt new marketing platforms, CRMs, and ticketing tools, and rarely remove them when they switch. Every stale include is a third party that can still pass SPF on your behalf. It also counts toward SPF's limit of 10 DNS lookups, so stale entries can eventually break SPF evaluation for the senders you actually use. Our SPF, DKIM, and DMARC setup guide covers how to audit and trim the record.

4. DKIM selectors and DMARC policies nobody revisits

DKIM selectors published for a retired email service keep that service's signing keys trusted for your domain. DMARC policies drift too. A domain left at p=none after a "temporary" rollout years ago is a domain where spoofed mail is reported but never blocked.

5. Certificates and CAA records that outlived their purpose

This is where DNS meets the certificate world Verisign describes. CAA records tell certificate authorities which of them may issue for your domain. A CAA record that still lists a CA you stopped using years ago extends trust you no longer intend. Certificates issued for your names that you did not request, visible in public Certificate Transparency logs, are often the first sign that a subdomain has been taken over or that someone is preparing to impersonate you.

Why stale trust keeps happening

Stale trust is rarely the result of carelessness. It comes from a structural gap: trust is granted in one place and revoked in another.

A developer deletes a cloud resource in the provider's console. A marketing manager cancels a SaaS subscription in a billing portal. An IT lead migrates DNS hosting during a busy quarter. None of those actions touches the DNS zone, and the person taking them is usually not the person who manages DNS. According to reporting on the Hazy Hawk research, Infoblox believes this is what happened at the CDC: the Azure resource was abandoned, but nobody told the person managing DNS.

Periodic audits help, but they share the weakness Verisign identifies in certificate validation: they evaluate trust at a point in time and assume it holds until the next review. In the gap between audits, exposure grows. Attackers, meanwhile, scan continuously using passive DNS data and Certificate Transparency logs to find exactly these records.

Closing the gap: treat DNS trust as something to re-validate

The answer to stale trust, in certificates or in DNS, is the same principle: validate trust continuously, against current reality, not against what was true when the record was created. In practice, that means a few habits.

Make DNS cleanup part of decommissioning. Any checklist for retiring a cloud resource, cancelling a SaaS tool, or migrating a provider should include removing or repointing the DNS records that referenced it. Microsoft's own guidance is to remove CNAME records for deprovisioned resources and to fix the process that let them linger.

Know every subdomain you own. You cannot clean up records you do not know exist. Certificate Transparency logs and subdomain discovery reveal hostnames that never made it into an inventory spreadsheet. See building a DNS inventory that stays current.

Review email authentication on a schedule. Walk your SPF includes, DKIM selectors, and DMARC policy at least quarterly, and remove anything tied to a vendor you no longer use.

Confirm every delegation is still live. For every NS delegation, confirm that the provider actually serves the zone and that the account behind it is active.

Watch for change, not just state. A record that was safe last month can become dangerous today if the resource behind it was deleted yesterday. Monitoring has to be continuous to keep up.

How DNS Assistant helps

DNS Assistant was built around this idea, which is the core of DNS posture management. Instead of a one-time audit, it continuously re-validates the trust your DNS records express and alerts you when reality changes underneath them.

Subdomain takeover and dangling CNAME detection. DNS Assistant checks whether the resources your CNAME records point to still exist and flags records that have become dangling.
NS delegation monitoring. Lame and dangling delegations, the root cause of Sitting Ducks style hijacks, are surfaced before an attacker finds them.
SPF, DKIM, and DMARC drift. Changes to your email authentication records, and policies that have stalled in a weak state, are tracked over time so drift does not go unnoticed.
Certificate Transparency monitoring. New certificates issued for your domains are detected from public CT logs, along with subdomains you may not have known about. Certificates issued by a CA your CAA records do not authorize are flagged.
DNSSEC and TLS posture. Broken DNSSEC chains and weakened TLS configurations are caught as they happen, not at the next quarterly review.

For MSPs, stale trust multiplies across every client. Each client has years of vendor changes, migrations, and retired projects, and each one left records behind. Continuous monitoring turns that hidden exposure into a clear, reportable list of findings and a recurring service you can offer every client.

It is also worth being clear about what DNS monitoring is not. Checking certificate revocation status at the moment a certificate is used, the problem Verisign is focused on, is a separate control that lives in your clients, gateways, and identity infrastructure. The two complement each other. Revocation checking makes sure you stop trusting a bad certificate quickly. DNS posture monitoring makes sure the names those certificates protect have not quietly been handed to someone else.

Start with what is already stale

Most organizations do not need to imagine where stale trust might be. It is already in their zone, waiting to be found. The question is whether you find it first.

Run a free DNS check at DNS Assistant to see how your domain looks today, or start monitoring with DNS Assistant to keep your DNS trust current every day after that.