Taking Back Control: CAA Records, CNAMEs, and Who Actually Decides

Revised July 9, 2026. The original version of this article described CAA lookups the way RFC 6844 defined them back in 2013 — the lookup "restarting" at your CNAME's target and your own records dropping out of the picture. RFC 8659 replaced that algorithm in 2019, and I had it wrong here for more than a year. I don't know that a revised history is an accurate history — mostly it just tells you who survived long enough to do the rewriting. Either way: this version is correct, it's sourced, and it matters more now than when I first wrote it, because the CA rules changed hard through 2025 and 2026.

You point custom hostnames at other people's platforms all day. app.esoup.net CNAMEs to cool-app.example-platform.net, cdn.esoup.net CNAMEs to some CDN endpoint, and everything just works. Then certificates enter the picture, and with them CAA records — the DNS record that says which Certificate Authorities are allowed to issue for your names. It's your guardrail against mis-issuance, and it's checked on every single issuance, every renewal, forever.

So here's the question that started this article: when app.esoup.net is a CNAME pointing into someone else's zone, whose CAA policy decides which CAs can issue for your hostname?

The first version of this article got the answer wrong. Let's do it right.

How the lookup actually works

When a CA checks CAA for app.esoup.net, it queries CAA at that exact name. And DNS being DNS, if that name is a CNAME, the query chases the alias — whatever CAA records live at the target name come back as the answer. So far, no surprises.

The part I had backwards is what happens when that answer is empty. Under the old RFC 6844 reading, the search jumped ship — it restarted at the target and climbed the target's tree, and your own zone stopped mattering. Under RFC 8659, the one that's actually been in force since 2019, the climb continues on your original name. Empty answer at app.esoup.net (via its CNAME)? The CA checks esoup.net next. Your apex. Your policy.

Two consequences, and they're both worth saying flat:

If your provider publishes CAA at the exact target name, their policy governs your hostname. Not their apex, not their parent domain — the exact name your CNAME points at, alias-chased the way any DNS query would be. That's real delegation, and some platforms do it deliberately so their preferred CA can auto-issue for your custom domain without you lifting a finger.

If they don't publish CAA there — and most don't — your apex CAA governs after all. The empty answer sends the CA climbing your own tree, and the policy you set at esoup.net is the one that counts. The original article told you your apex was ignored the moment a CNAME entered the picture. It isn't. You may have had more control this whole time than I gave you credit for.

Want to know which case you're in? Don't guess — ask:

dig CAA cool-app.example-platform.net +short

Empty means your zone is still in charge. Records mean you've inherited someone else's policy, and you should know whose.

Or skip the guessing and watch the whole lookup run. Every CAA checker I could find just prints an answer, so I built one into DNSlurp that shows its work — the actual RFC 8659 walk, CNAMEs followed, every step explained with the rule that drove it: run it against this very site. You'll watch the query come up empty at workshop.esoup.net, climb to esoup.net, and stop on my apex policy — the exact algorithm this article describes, drawn out step by step. Put your own CNAME'd hostnames in it and you'll know which case you're in.

The ALIAS trick — still real, narrower purpose

The original article pitched ALIAS records (ANAME, flattened CNAME — every provider names it differently) as the way to take CAA control back. That's still true, it's just needed less often than I claimed.

An ALIAS record resolves the target at your authoritative server and answers with plain A/AAAA records. No CNAME in the response means no alias for the CA's CAA query to chase — the lookup never leaves your zone. Use it when your provider does publish CAA at the target name and you refuse to inherit their policy. (It's also the only way to get CNAME-like behavior at a zone apex, but that's a different article.)

The trade-off hasn't changed, so I'll keep the warning: if the provider was relying on their own CAA records to let their CA auto-issue certificates for your hostname, cutting them out will break that automation. Take back the policy, and you take back the responsibility — either add their CA to a hostname-specific CAA record in your own zone, or be ready to manage the certificate yourself. Check your provider's docs for which CA they use before you flip anything.

;; Your zone, your policy — granular beats broad
esoup.net.       IN CAA 0 issue "ca-you-trust.com"
app.esoup.net.   IN CAA 0 issue "provider-ca.example.com"  ;; just this host
app.esoup.net.   IN CAA 0 issuewild ";"                    ;; and no wildcards

The part that pages you at 2 a.m.

Everything above is about policy — whose rules apply. The 2025–2026 rule changes added a second question that's now just as important: does the lookup succeed?

To check CAA at all, the CA has to walk your DNS. That walk follows every CNAME you've published — straight into zones you don't run, on infrastructure you've never seen, operated by whoever your vendor outsourced DNS to. And the rules governing that walk got strict:

• Since March 15, 2026, CAs must validate DNSSEC on these lookups. Not optionally. (Ballot SC-085 made it mandatory.)
• The Baseline Requirements have long said a CA may treat a failed lookup as "no policy, go ahead" only if your zone has no DNSSEC chain to the root. If your zone is signed — and mine are — a failed lookup means no certificate. Full stop.
• And since September 2025, the CA isn't looking from one place anymore. MPIC has them checking from multiple network vantage points, so one flaky secondary or one stale answer in the wrong geography can sink the whole check.

Put it together: your signed zone, a CNAME into a vendor zone with broken signatures or wobbly nameservers, and a CA that's now required to notice — that's a certificate that doesn't issue, and it fails on the vendor's schedule, not yours. I won't pretend the CA is wrong to refuse. It's doing exactly what the rules demand. The gap is that most teams don't know the rules changed.

The full story — all four rule changes, the dates, and the reading list — is in Nobody Tells You When the CA Rules Change. If you only follow one link out of this article, make it that one. (Let's Encrypt's CAA page is the runner-up — two screens, plain English, and it names the debugging tool you want: dnsviz.)

Where that leaves you

The CNAME question turns out to have a clean answer once you read the right RFC: your apex governs unless the vendor publishes CAA at the exact target name, and an ALIAS record can slam even that door if you need it shut. Know which case each of your hostnames is in — it's one dig per name, or one CAA Walk if you want the climb drawn out for you.

But policy was the easy half. The lookups themselves now run through DNSSEC validation, from multiple vantage points, with failure treated as refusal for signed zones. Every CNAME you publish on a certificate-bearing name is a dependency you've taken on — someone else's DNS hygiene, on your critical path.

That's the takeaway: a CNAME is a trust decision now, and the CA checks your homework on every renewal.