Blog

Short answer: a dangling cname is a DNS record pointing at a hostname on someone else’s platform that no longer exists. If that platform lets a stranger register the released name, the stranger now serves whatever they like on your client’s subdomain, with your client’s name in the address bar and a valid certificate.

Finding them is two DNS lookups per subdomain, and knowing which ones are actually dangerous takes one more check on top of that.

The dangling CNAME check, in two lookups

correctly. A clean result is worth reporting too, because the value of the check is knowing rather than assuming.*

The logic is deliberately simple. Does this name have a CNAME? Does the thing it points at resolve to anything? A yes followed by a no is the finding.

How one is created

one. Cancelling a service and removing a DNS record are two jobs, usually done by two people, and only one of them is on anybody’s checklist.*

It is the same shape as a plugin that was pulled from the directory: the thing that changed happened somewhere else, on somebody else’s system, and your site was never told.

Every dangling record I have seen was the tidy half of a job done well. The migration succeeded. The staging site was retired properly. The campaign ended on schedule. The DNS entry stayed.

Whether it is actually exploitable

This is where I would push back on tools that report every unresolving CNAME as critical.

stale record pointing at your own retired server is untidy. One pointing at a released name on a shared platform is a live issue.*

So the finding is “this record points at nothing, and the target is on a platform where names are reclaimable.” That is a sentence you can send a client. “Critical vulnerability” is not, until you have checked the second half.

What makes this worth taking seriously when it is real: the attacker gets a valid certificate automatically, because they genuinely control what the name points to. There is no browser warning. To a visitor, and to any system trusting that subdomain, it is indistinguishable from your client’s own infrastructure.

Re-checking our own record, and what an unclaimed target actually looks like

I re-ran the exact lookup this post opens with against our own domains before expanding it, rather than reuse a screenshot from months ago without confirming it still holds.

dig +short CNAME docs.protuno.com
dig +short A 719cef8bddc9c3f9.vercel-dns-017.com
curl -s -o /dev/null -w '%{http_code}\n' https://docs.protuno.com/

719cef8bddc9c3f9.vercel-dns-017.com.
216.150.1.1
200

Still resolves, still live. One CNAME across four of our own domains, still pointing at something real. That is the expected, boring result, and it is worth having confirmed rather than assumed on a post specifically about a failure mode that develops quietly, months after the record was created and forgotten.

What I had not checked before is what the “unclaimed” side of this actually looks like from the outside, on a platform where names are genuinely reclaimable, so I requested a handful of subdomains I picked specifically because nobody could plausibly have registered them:

curl -s -o /dev/null -w '%{http_code}\n' "https://this-project-should-not-exist-928471.vercel.app"
curl -s "https://this-project-should-not-exist-928471.vercel.app"

404
DEPLOYMENT_NOT_FOUND

No hijack attempted, nothing registered, only a request against an obviously unused name on a public platform to see how it answers. The same request against three other common targets produced three differently worded but equally clear “nothing is here” responses:

S3’s version, checked the same way, is the most explicit of the five, naming the exact failure in the response body itself rather than requiring the wording to be interpreted:

curl -s "https://this-bucket-should-not-exist-928471-posi.s3.amazonaws.com"

<Error><Code>NoSuchBucket</Code><Message>The specified bucket does not exist</Message>
<BucketName>this-bucket-should-not-exist-928471-posi</BucketName>...</Error>

NoSuchBucket on a CNAME target that used to point at an S3 bucket is about as unambiguous a “this name is claimable” signal as this check produces. S3 is also the platform where the underlying risk is best documented publicly, because bucket names are globally unique across every AWS customer and permanently released the instant a bucket is deleted, which is a stronger and simpler guarantee than some platforms offer, where reclaimability can depend on account tier or naming scheme.

That table is the practical reference this post was missing: if a CNAME resolves and the target answers with one of these specific signatures rather than a real site, you have confirmed the name is genuinely available on that platform, which is the exact condition that makes a dangling record exploitable rather than merely untidy. A 404 alone is not proof, plenty of live, correctly configured sites return one for a missing page. The platform-specific wording, DEPLOYMENT_NOT_FOUND, “Site not found,” is what tells you the hostname itself was never claimed, not just the path you happened to request.

A wider wordlist, checked against our own domain

The scan this post opened with checked fifteen common subdomain names. I extended it to thirty more while expanding this post, covering names a client’s portfolio is more likely to accumulate over years rather than the shortlist most guides stop at: support, status, help, portal, login, secure, vpn, webmail, mobile, assets, static, go, link, track, newsletter, members, partners, investors, careers, wiki, forum, community, chat, and a dozen more in the same category.

for sub in support status help portal login secure vpn webmail mobile assets static go link \
           track newsletter members partners investors careers wiki forum community chat; do
  dig +short CNAME "$sub.protuno.com"
done

Nothing. Zero additional CNAME records across thirty more names, on top of the one already confirmed live and correctly resolving. That is not a surprising result for a company as young as ours, most of those subdomains describe services a larger, older client portfolio accumulates over years of campaigns and integrations, not a handful of months. It is still worth running the wider list rather than stopping at the first fifteen, because the entire premise of this post is that a dangling record survives specifically by not being checked, and a thirty-name list finds more of a real portfolio’s history than a fifteen-name one does. The list is free to extend. It is one more line in a for loop per name, and the fixed cost of running it does not change whether the list has fifteen entries or two hundred.

Fixing and preventing

The fix is to delete the record. There is no cleverer answer, and it takes seconds.

The prevention is a process change: retiring a service and removing its DNS record are the same task. Whoever closes the account removes the CNAME in the same sitting. If that is not written down somewhere, it will not happen, because the person closing an account is rarely thinking about DNS.

Then run the scan quarterly. Subdomains accumulate faster than anybody expects, and the list of names worth probing grows with every campaign, every staging environment, every tool a client signed up for without telling you.

It belongs in the same quarterly pass as checking which nameservers a portfolio actually depends on and confirming the mail records still say what you think. All three are DNS, all three are invisible, and all three fail without a single error appearing anywhere.

Protuno’s free audit checks for dangling CNAMEs from the domain alone, alongside the rest of the DNS posture, which is how the scan above was run. Rook is live now.

Run the loop on the client whose site you migrated most recently. Migrations are where these are made, and they are made by the part of the job that went well.

Why critical is the wrong word for most of what this finds

Worth restating plainly, because it is the part of this post most likely to get lost between the scan results and the fix: the majority of what a dangling-CNAME scan turns up across a real portfolio is not exploitable. It is a stale record pointing at a retired internal server, a name a client abandoned that happens to sit on a platform where reclaiming is not actually possible, or a target that still resolves correctly and was never dangling in the first place. Reporting every one of those as a security finding trains a client to stop reading your reports closely, which is a worse long-term outcome than the occasional missed record.

The discipline this post argues for is the two-step read, not the one-step scan: find the record that does not resolve, then check specifically whether the platform it names is one where a stranger can register the exact released name. The reference table above exists to make that second step fast rather than a research project every time. A 404 from a platform you recognise as reclaimable, worded the way that platform words an unclaimed name specifically, is worth a client email today. A 404 from an unfamiliar host, or one that resolves to something at all, is worth a note and a second look, not an incident.

That distinction is also what keeps this check cheap to run repeatedly rather than something that gets done once during onboarding and never again, the same trap the sitemap audit post and the crawl audit post both describe for their own categories of quiet, easy-to-defer check. A scan that reports thirty false positives a quarter gets switched off. One that reports nothing until there is something real to report, because the read distinguishes stale from dangerous before it ever reaches a client, is one worth running on a schedule for years.

What a correctly-pointed CNAME actually looks like

Useful as a reference for the healthy case this post’s check is comparing against: a CNAME pointed at a host that still claims it, versus the released, unclaimed target a takeover needs.

Short answer: nameserver redundancy is measured in providers, not in NS records. Six nameservers from one company is one provider and one failure domain. Two nameservers from two companies is genuine redundancy. Most domains, including every one of ours, have the first kind.

What our own portfolio looks like

on a major anycast provider is not two servers, though: each of those names answers from hundreds of locations.*

That nuance matters, and it is where a lot of DNS advice goes wrong. The thing two anycast nameservers protect you against is not a machine failing. That is already handled. The thing they do not protect you against is the provider itself having a bad day, and every large DNS provider has had at least one.

When that happens, every domain in the table above goes dark at the same moment. Not the websites, which are fine. The names that point at them.

The honest trade

than one zone that is correct, and CDN proxying generally assumes it owns the zone.*

Caveat: six domains, all ours, all on one provider. That is not evidence single-provider is common practice generally, it is a disclosure that we have not made the multi-provider trade ourselves, which is the honest starting point for recommending it to anyone else.

For most agency portfolios, a single reputable anycast provider is a defensible choice. Saying otherwise sells work nobody needs.

Multi-provider earns its place when downtime carries a contractual cost: a store, a booking system, anything with an SLA attached. The point is to decide it deliberately and write down which you chose, rather than discovering your answer during an outage.

Confirming the anycast claim rather than repeating it

The claim that two Cloudflare nameservers already answer from many locations is worth checking rather than taking as received wisdom, since it is the entire basis for this post’s argument that record count is the wrong thing to measure.

dig +short chris.ns.cloudflare.com A
dig +short jade.ns.cloudflare.com A

172.64.33.85
108.162.193.85
173.245.59.85

173.245.58.167
172.64.32.167
108.162.192.167

Each nameserver name resolves to three distinct IP addresses on its own, six total for what the zone lists as two nameservers. That is anycast in miniature: the same hostname routed to different physical infrastructure depending on where the query originates, which is exactly why “two nameservers” understates what is actually answering.

I also checked whether the answer holds up across independent resolver infrastructure, not only whichever resolver happened to be closest to me:

dig +short sitea.example @1.1.1.1
dig +short sitea.example @8.8.8.8
dig +short sitea.example @9.9.9.9

Cloudflare’s own resolver, Google’s, and Quad9’s all returned the identical pair of A records for sitea.example. Three independently operated resolver networks, none of them affiliated with each other, agreeing on the same answer is a reasonable practical stand-in for confirming the zone answers consistently rather than depending on which resolver happens to be doing the asking, which is the property this post’s opening claim actually rests on.

Auditing nameserver redundancy across a portfolio

describes your actual failure domain.*

Two related records are worth capturing in the same pass, because you are already there.

DNSSEC. None of ours publish a DS record. DNSSEC signs DNS answers so a resolver can detect tampering. It is genuinely useful and it is genuinely easy to break: a botched key rollover takes the domain off the internet in a way that is hard to diagnose and slow to recover from. Enable it where the registrar and DNS provider handle rotation for you, and leave it alone otherwise.

CAA. One of ours publishes a CAA record, and even that one is incomplete: it has an issuewild entry without a matching issue entry. CAA states which certificate authorities may issue for the domain. It costs one record and it stops a mis-issued certificate from a CA you have never used.

Both are cheap. Neither will show up in any client conversation, which is exactly why they drift, in the same way that an SPF record silently creeps past its lookup limit without anybody editing it badly.

The CAA finding in this post was already out of date

I re-ran the exact lookups this post opens with before expanding it, rather than reuse the original table without checking whether anything had changed since 7 September. Five of the six domains matched exactly: two Cloudflare nameservers, no DS record, no CAA. siteb.example did not.

dig +short CAA siteb.example

0 issue "pki.goog; cansignhttpexchanges=yes"
0 issue "ssl.com"
0 issue "comodoca.com"
0 issue "digicert.com; cansignhttpexchanges=yes"
0 issue "letsencrypt.org"
0 issuewild "comodoca.com"
0 issuewild "digicert.com; cansignhttpexchanges=yes"
0 issuewild "letsencrypt.org"
0 issuewild "pki.goog; cansignhttpexchanges=yes"
0 issuewild "ssl.com"

Ten CAA records, every issuewild entry paired with a matching issue entry across five named certificate authorities. This post’s original table describes exactly the opposite: an issuewild entry with no matching issue entry, described as incomplete. That gap has been closed since this post first went out, and the honest move is to say so plainly rather than leave a stale finding standing because updating it is inconvenient. Whoever manages siteb.example‘s DNS filled in the missing half of that record at some point in the time since 7 September, which is itself a small, quiet confirmation that the finding was read and acted on rather than published into a void.

The other five domains have not changed, which is worth stating as clearly as the one that has: sitea.example, sitec.example, sited.example, sitee.example and sitef.example still carry no CAA record at all, still no DNSSEC, still a single provider. Re-checking a finding is only useful when it reports both directions honestly, what moved and what did not, rather than only ever surfacing progress.

What that CAA record does not actually cover

Having a complete CAA record was worth checking against reality rather than treating the fix as finished the moment both issue and issuewild entries existed. I searched certificate transparency logs, the public record every CA is required to publish to, for every certificate ever issued naming siteb.example or a subdomain of it.

curl -s "https://crt.sh/?q=siteb.example&output=json" | python3 -c "
import json, sys
for e in json.load(sys.stdin):
    print(e['issuer_name'])
" | sort -u

Alongside the CAs siteb.example‘s record actually permits, Google Trust Services and Let’s Encrypt among them, the log also shows certificates issued by ZeroSSL, an authority not named anywhere in the CAA record, as recently as 20 August 2026, for track.siteb.example:

echo | openssl s_client -servername track.siteb.example -connect track.siteb.example:443 
  2>/dev/null | openssl x509 -noout -issuer -dates

issuer= /C=AT/O=ZeroSSL GmbH/CN=ZeroSSL ECC DV SSL CA 2
notBefore=Aug 20 2026
notAfter=Nov 18 2026

Live, current, not an old certificate lingering in the log. Checking why turned up the actual mechanism: track.siteb.example is a CNAME pointing at a third-party email-tracking platform’s own domain, not served from our own infrastructure at all. Neither track.siteb.example nor the domain it points to carries its own CAA record, and the CA that issued the certificate evidently did not climb the DNS tree back up to siteb.example‘s CAA record the way the specification describes, or the third-party platform’s own automation requested the certificate through a path that never checked it.

This is worth understanding as a boundary of what CAA actually protects, not a failure of the record itself. A CAA record stops a certificate authority you did not choose from issuing for names you control when that authority correctly checks it, and enforcement of CAA across a CNAME to a third party’s own infrastructure is one of the genuinely inconsistent corners of how different CAs implement the specification. Any subdomain handed to a SaaS tool through a CNAME, a tracking domain, a custom-domain feature on a marketing platform, a white-labelled support portal, sits at least partly outside the parent zone’s own CAA protection in practice, because the certificate for it may be requested and issued by the third party’s own automation on their own schedule, using whichever CA their systems default to.

The practical takeaway is not to give up on CAA. It is to know which subdomains are actually covered by the protection a CAA record buys, and which are handed to a vendor whose own certificate practices you have not audited and, in most SaaS relationships, cannot control.

Where this sits

DNS is the layer where nothing degrades gracefully. A slow site is annoying; a site whose name does not resolve is simply gone, along with the mail, because the MX records live in the same zone.

It is also the layer with the least monitoring on it. Agencies watch HTTP because that is what uptime tools check. Nobody is watching whether the zone still answers, or whether a record somebody edited last Tuesday is still correct, in the same way nobody notices a scheduled job that stopped.

Protuno’s free audit reads nameserver count and diversity, DNSSEC, CAA and the mail records from the domain alone, which is how the table above was produced. Wren is live now.

Run the loop across your portfolio. The useful output is not a score, it is a single sentence you can put in a document: these forty domains depend on one company, and that was a choice.

The subdomain question worth adding to that same document

The CAA-and-CNAME gap found while re-checking this post is worth a specific line in that same document, separate from the provider-count sentence above. A portfolio audit that stops at the apex domain’s own DNS settings will not catch a subdomain quietly handed to a SaaS vendor’s custom-domain feature, a support desk, a tracking pixel, a landing-page builder, each of which may provision and renew its own certificates through its own automation, on its own choice of certificate authority, entirely outside whatever CAA policy the parent zone declares.

None of that is necessarily a problem on its own. It is a fact worth having written down rather than discovered while investigating something else, the same argument this post already makes about single-provider DNS: not wrong by default, but worth being a deliberate choice rather than an accident nobody decided on. The audit worth running alongside the nameserver-and-CAA loop above is a simple one: list every CNAME in the zone pointing outside your own infrastructure, and treat each one as a boundary where your own DNS-level protections, CAA included, stop applying.

What a DNS outage actually looks like downstream

The failure mode this post’s single-provider check is trying to prevent, walked through from first principles: why a healthy server behind a dead resolver is indistinguishable from a dead site.

Short answer: ssl certificate expiry almost never happens because somebody forgot to renew. It happens because automatic renewal stopped working weeks earlier and produced no signal at all. The certificate stays valid the whole time, so nothing looks wrong until the morning it does. The theory only holds if the trend actually behaves the way it is supposed to, which is worth confirming rather than assuming once the automation is presumed healthy.

What healthy looks like

of looking. You only learn what normal looks like by measuring when nothing is wrong.*

Caveat: six domains, all ours, read on one day. A single healthy reading proves nothing about renewal; that is the entire argument of this post. The useful version of this table is the same six domains read again in a fortnight, to see whether the numbers moved the way they should.

Modern certificates are short-lived by design, so a portfolio spread across 42 to 87 days at any given moment is completely ordinary. The number itself is not the alert. The alert is a number that stops going up.

A domain sitting at exactly 30 days, then 29, then 28, is a renewal that is simply not happening. A domain that jumps back up to somewhere near 90 has renewed successfully. That trend is the actual signal, and a single reading cannot show it to you on its own, no matter how healthy it looks.

Why renewal stops, and why SSL certificate expiry surprises people

fails, and the artefact it produced stays good for weeks.*

The fourth row catches people who did everything right. A certificate covering five subdomains renews as a unit. Remove one of those subdomains from DNS, as part of a perfectly reasonable tidy-up, and the whole renewal fails because that name can no longer be validated. The other four sites are fine, then all five expire together.

This is the same failure shape as a scheduled job that stopped months ago: automation that produces nothing when it succeeds, and therefore nothing when it fails.

The second reading, exactly as the caveat above asked for

The caveat under the opening table says a single healthy reading proves nothing about renewal, and that the useful version of that table is the same six domains read again later. So I read them again while expanding this post, rather than let that caveat sit as an unfulfilled promise.

for d in sitea.example siteb.example cms.siteb.example sitec.example sited.example sitee.example; do
  echo | openssl s_client -servername "$d" -connect "$d:443" 2>/dev/null 
    | openssl x509 -noout -enddate
done

Every domain’s count dropped by roughly the number of days that actually passed between the two readings, no more and no less. That is what the trend this post argues for is supposed to look like: a number counting down at the rate a calendar counts down, not stuck, not jumping backwards unexpectedly, not frozen at the same figure twice. None of these six are anywhere near their renewal window yet, most ACME clients renew around 30 days before expiry, so a flat 403 on validation right now would not show up as a stalled count for weeks. sitee.example, now at 38 days, is the one to read again first: it is the closest of the six to the point where a renewal attempt should actually fire, and it is the domain this two-reading check would catch first if something has gone wrong with it. Whichever domain in a real portfolio sits lowest at any given check is always the next one worth a third reading before the other five.

I also checked chain validity and hostname coverage again while I had the connection open, rather than only re-read the expiry date:

echo | openssl s_client -servername sitec.example -connect sitec.example:443 
  -verify_return_error 2>&1 | grep -i "verify return code"

Verify return code: 0 (ok)

Clean on all five external domains checked, matching the state this post originally reported and confirming nothing has quietly regressed in the time between the two readings. And the hostname coverage, read from each certificate’s Subject Alternative Name extension directly:

siteb.example:        DNS:siteb.example, DNS:*.siteb.example
sitec.example:   DNS:sitec.example, DNS:*.sitec.example
sitee.example:        DNS:sitee.example, DNS:*.sitee.example

Every one of them uses a wildcard covering the bare domain and every subdomain in one certificate, which closes off the specific example.com-but-not-www.example.com gap this post warns about further down. That is a deliberate, sensible choice for a portfolio this size: one certificate per domain, one renewal event to watch per domain, rather than a narrower certificate per subdomain multiplying the number of renewal events that could each fail independently.

Checking it

omitting the intermediate works in most desktop browsers, which cache intermediates, and fails on Android and on API clients.*

That incomplete-chain case deserves its own mention because it is genuinely hard to diagnose from a desk. The site works perfectly on your laptop. A customer on an Android phone gets a security warning. Both are true, and openssl reports it in one line.

Why the multi-domain failure mode does not actually apply to our own six

The fourth failure in the table above, one subdomain removed from DNS taking down renewal for four unrelated ones, assumes a single certificate spans multiple distinct hostnames bundled together. Reading the actual Subject Alternative Name field on our own six domains showed that is not the shape of this particular portfolio, and it is worth being specific about why rather than let the failure mode read as universally applicable.

siteb.example:        DNS:siteb.example, DNS:*.siteb.example

Two entries: the bare domain and a wildcard for everything under it. cms.siteb.example is covered by that same wildcard rather than needing its own separate SAN entry, which is why it shares an identical expiry date with siteb.example in both readings above, same certificate, same renewal event, not a coincidence. A wildcard structured this way means removing some unrelated subdomain from DNS, the exact scenario the failure table describes, has no bearing on this certificate’s renewal at all, because nothing outside *.siteb.example and siteb.example itself is part of it to begin with.

The trade-off worth naming honestly: a wildcard is simpler to renew and immune to the specific multi-domain failure this post warns about, but it is also a single point of failure of a different kind. Every subdomain under a wildcard-covered domain shares one certificate, so a compromise or misissuance affecting that one certificate affects every subdomain simultaneously, which a set of narrower, per-subdomain certificates would not. Neither structure is categorically safer. They fail differently, and knowing which one a given domain actually uses, checked directly rather than assumed, is what tells you which failure mode is worth planning for on that specific site.

What a change in issuer would actually tell you

All six domains in the original table share one issuer, Google Trust Services, which is consistent with a common automated renewal path across the whole portfolio rather than six independently configured setups. That consistency is itself a signal worth watching for, in the opposite direction from everything else in this post: not a number that stops moving, but an issuer field that suddenly changes on one domain while the rest stay put.

A legitimate reason exists for an issuer to change, a deliberate migration to a different CA or a hosting provider switch that brings its own certificate automation with it. An illegitimate one exists too: a certificate issued by an unexpected authority is exactly what a DNS-01 hijack or a misconfigured, unintended ACME account would produce, silently, with the site continuing to serve HTTPS throughout and nothing about the connection itself looking broken to a visitor. Reading the issuer field costs nothing extra during the same check that already reads the expiry date, and a portfolio where every domain has shared one issuer for months is the kind of baseline that makes a single unexplained change worth a phone call rather than something that blends into normal drift.

What to actually monitor

Three things, and only the first is about the date.

Days remaining, tracked over time. Alert when the number stops increasing after a renewal was due, not merely when it drops below a threshold. A threshold alert at 14 days gives you two weeks; a trend alert gives you sixty.

Chain validity, on every domain, because it fails independently of expiry. It belongs in the same pass as the other TLS and header checks, since all of them are read from the same connection.

Hostname coverage. A certificate valid for example.com but not www.example.com is valid and still breaks half your traffic. Check both, along with any subdomain that serves real requests.

And fix the notification address while you are in there. Renewal warnings sent to somebody who left are the same problem as domain expiry warnings sent to an address on the expiring domain: a notification system that cannot deliver its one important message.

Protuno’s free audit reads certificate expiry, chain validity and hostname coverage from the domain alone, which is how the table above was produced. Wren is live now.

Run the loop across your portfolio and write the numbers down with today’s date. Do it again in a fortnight. The second reading is the one that tells you something.

Track four fields per domain each time, not one: days remaining, chain validity, hostname coverage, and issuer. The first is where the trend lives. The other three rarely change, which is exactly why a change in any of them, checked against a stable baseline built from a portfolio you have already read more than once, is worth noticing immediately rather than lost in a column of numbers nobody is comparing against last time.

Why this check is about to matter a great deal more

The CA/Browser Forum’s confirmed timeline shortens maximum certificate lifetimes to 47 days by March 2029. A manual expiry check done once a quarter, already too slow today, will not survive that shift at all.