Taking Back Control: CAA Records, CNAMEs, and the ALIAS Record Trick

Revised Feb 26, 2026 to improve clarity.

Many of us rely on third-party platforms – CDNs, PaaS providers, SaaS applications – to host parts of our online presence. A common way to point our custom domain names to these services is using a CNAME record. For instance, you might point app.esoup.net to a service hosted at cool-app.google.example.net or cdn.esoup.net to endpoint.cf.example.net. Simple, right?

But when it comes to securing these endpoints with TLS/SSL certificates, things get a bit more interesting, especially regarding CAA (Certification Authority Authorization) records. CAA records are your way of telling the world which Certificate Authorities (CAs) are allowed to issue certificates for your domain, acting as a vital safeguard against mis-issuance.

So, here's the question: When you use a CNAME like app.esoup.net pointing to cool-app.google.example.net, who actually controls the CAA policy – and thus which CAs can issue certs – for your app.esoup.net hostname? The answer might surprise you, and understanding it is key to maintaining the level of control you desire.

How CAA Record Checks Work with CNAMEs (The Standard)

The behavior of CAA lookups is defined by RFC 8659, which simplified how CNAMEs interact with CAA compared to its predecessor (RFC 6844). Importantly, the CAA algorithm itself no longer contains any CNAME-specific logic — it simply walks up the parent domain tree. CNAME following is handled transparently by the DNS resolver during each CAA query, per the standard DNS resolution algorithm (RFC 1034, Section 4.3.2).

;; Standard CNAME setup
app.esoup.net.   300 IN CNAME cool-app.google.example.net.

When a CA queries for CAA records at app.esoup.net, the DNS resolver transparently follows the CNAME to cool-app.google.example.net and checks for CAA records there. If CAA records exist at the CNAME target, those are the records the CA sees for the original name — your own zone's CAA records are not consulted. However, if no CAA records exist anywhere on the CNAME target side, the lookup returns empty for that name and the CA's algorithm continues climbing the original domain tree (e.g., checking esoup.net).

Effectively, the CNAME gives the owner of cool-app.google.example.net the opportunity to control CAA policy for app.esoup.net — but only if they publish CAA records. If the CNAME target side has no CAA records, the CA's lookup continues up your own domain tree and your zone's CAA policy applies.

Seeing It in Action: Two Scenarios

Scenario 1 — Provider publishes CAA records:

;; Your zone: esoup.net
app.esoup.net.                    300 IN CNAME  cool-app.google.example.net.
esoup.net.                        300 IN CAA    0 issue "ca-you-trust.com"

;; Provider zone: google.example.net
cool-app.google.example.net.      300 IN CAA    0 issue "pki.goog"

CA wants to issue a certificate for app.esoup.net:

Step 1: CAA("app.esoup.net")
  → Resolver follows CNAME to cool-app.google.example.net
  → Finds: CAA 0 issue "pki.goog"
  → Returns to algorithm → NOT EMPTY → STOP

Result: Only "pki.goog" can issue. Your "ca-you-trust.com" at esoup.net
        is never consulted.

Scenario 2 — Provider publishes NO CAA records:

;; Your zone: esoup.net
app.esoup.net.                    300 IN CNAME  cool-app.google.example.net.
esoup.net.                        300 IN CAA    0 issue "ca-you-trust.com"

;; Provider zone: google.example.net
;; (no CAA records published anywhere)

CA wants to issue a certificate for app.esoup.net:

Step 1: CAA("app.esoup.net")
  → Resolver follows CNAME to cool-app.google.example.net
  → No CAA records found → Returns EMPTY

Step 2: CAA("esoup.net")
  → Finds: CAA 0 issue "ca-you-trust.com"
  → NOT EMPTY → STOP

Result: Your zone's "ca-you-trust.com" governs. The CNAME target had
        no CAA records, so the algorithm kept climbing your domain tree.

The outcome depends entirely on whether the CNAME target publishes CAA records. This is why we call it a conditional delegation — the provider has the opportunity to control CAA policy, but only if they choose to publish CAA records on their side.

Why Providers Often Rely On This:

Most providers intentionally publish CAA records on their CNAME target domains, permitting their preferred CAs (e.g., Let's Encrypt, Google Trust Services, DigiCert). Because the resolver follows your CNAME and finds those records, the provider's CA is authorized to automatically provision and renew TLS certificates for your custom domain (app.esoup.net) seamlessly in the background. It's frictionless for you, the end-user, because you don't need to take any action regarding CAA records or certificate management for that specific service.

Why You Might Want Control Back

While convenient, this implicit delegation might not align with everyone's requirements:

Strict Corporate Policies: Your organization might mandate that only a specific, pre-approved set of CAs can issue certificates for any hostname under the company domain (esoup.net).
Desire for Universal Policy: You might want your apex esoup.net CAA record to be the single source of truth, applying uniformly unless explicitly overridden for a specific subdomain.
Trust Boundaries: You might simply prefer not to implicitly inherit the CAA policy choices made by the third-party provider.

If you want to ensure that the CAA check for app.esoup.net respects the policies set within your own esoup.net zone, the standard CNAME method prevents this.

The ALIAS/ANAME Record "Trick"

Enter the ALIAS record (sometimes called ANAME or similar, depending on the DNS provider). This is a non-standard, proprietary record type offered by many modern authoritative DNS providers. It's designed to overcome the limitation that you can't place a CNAME at the zone apex (e.g., for esoup.net itself), but it has a useful side effect for our CAA scenario.

Unlike a CNAME, which returns the target hostname to the resolver, an ALIAS record works differently:

When a query for app.esoup.net arrives at your authoritative nameserver (configured with an ALIAS record), the nameserver itself resolves the target (cool-app.google.example.net) to its underlying IP address(es).
The authoritative nameserver then responds to the original query with those IP addresses (as A or AAAA records), making it look like app.esoup.net pointed directly to those IPs.

Here's how you might configure it (syntax varies by provider):

;; Example ALIAS setup (syntax is illustrative)
app.esoup.net.   300 IN ALIAS cool-app.google.example.net.
cdn.esoup.net.   300 IN ALIAS endpoint.cf.example.net.
email.esoup.net. 300 IN ALIAS region.azure.example.net.

The Key Difference for CAA: Because the resolver querying for app.esoup.net receives an A/AAAA record answer, not a CNAME, there is no alias for the resolver to follow. The CAA check proceeds using the standard parent-climbing algorithm starting from app.esoup.net, guaranteeing that your zone's CAA policy governs — regardless of what the service provider publishes on their side.

Result: Using an ALIAS record instead of a CNAME keeps the CAA policy check firmly within the authority of your esoup.net zone.

(Aside: Why use a dedicated DNS provider for this? While major cloud platforms like Google Cloud, Azure, or Cloudflare often offer their own DNS services, you might choose a specialized authoritative DNS provider for features like advanced ALIAS record handling, superior performance, different geographical distribution, specific GSLB capabilities, or simply to maintain separation of concerns and avoid vendor lock-in. It's a valid choice to select the best-of-breed provider for each part of your infrastructure, including DNS.)

Consequences and Considerations: The Trade-offs

Regaining control sounds great, but this approach comes with significant consequences you must understand and manage:

Benefit: You achieve explicit control. The CAA records published within your esoup.net zone now govern certificate issuance for app.esoup.net, cdn.esoup.net, etc., even when they point to external services via ALIAS records.
Major Consequence / Hazard: Breaking Frictionless Certificate Issuance: This is the big one. If your third-party provider (Google, Cloudflare, Azure, etc.) was relying on the CNAME behavior to automatically issue/renew certificates using their chosen CA (authorized via their target domain's CAA record), that automation will likely break when you switch to an ALIAS record. Why? Because the CAA check now looks at your zone. If the CA the provider uses isn't authorized by the effective CAA policy within esoup.net for that specific hostname, the CA will refuse to issue the certificate. Your service might lose its TLS certificate and become inaccessible over HTTPS.

Necessary Actions (If Using ALIAS to Point to Third Parties):

If you use the ALIAS trick, you must ensure the provider's required CA is permitted by your effective CAA policy for that hostname. You have a few options:

Modify Apex CAA (Simplest, Broadest): Add the necessary provider CA(s) to the CAA record at the apex (esoup.net). dns ;; Potentially too broad esoup.net. IN CAA 0 issue "ca-you-trust.com" esoup.net. IN CAA 0 issue "provider-ca-for-google.com" ;; Allows for entire domain esoup.net. IN CAA 0 issue "provider-ca-for-cf.com" ;; Allows for entire domain
- Drawback: This might allow these provider CAs for your entire domain, potentially conflicting with your goal of tighter control.
Add Specific Hostname CAA (More Granular, Preferred): Create specific CAA records for each hostname using an ALIAS record, authorizing only the CA needed for that specific service. This is generally the best approach. ```dns ;; Specific CAA records in esoup.net zone esoup.net. IN CAA 0 issue "ca-you-trust.com" ;; Base policy for non-wildcards

app.esoup.net. IN CAA 0 issue "provider-ca-for-google.com" ;; Only for app. (non-wildcard) cdn.esoup.net. IN CAA 0 issue "provider-ca-for-cf.com" ;; Only for cdn. (non-wildcard) email.esoup.net. IN CAA 0 issue "provider-ca-for-azure.com" ;; Only for email.* (non-wildcard)

;; To explicitly block wildcard certificates (like .app.esoup.net) at this level, ;; overriding any permissive 'issuewild' records inherited from esoup.net, add: ;; (Note: The presence of an 'issue' tag alone does NOT block wildcards) app.esoup.net. IN CAA 0 issuewild ";" ``` * Benefit:* Keeps permissions localized. Requires knowing which CA(s) each provider uses (check their documentation).
Manage Certificates Manually (Most Control, Most Work): If the provider platform allows you to upload your own custom certificate, you could potentially:
- Keep your apex esoup.net CAA policy strict.
- Use an ACME client (like Certbot) with DNS validation against your authoritative provider to obtain a certificate for app.esoup.net from a CA permitted by your policy.
- Upload this certificate and its private key to the provider's platform.
- Drawback: This adds significant operational overhead for managing issuance, renewal, and uploading. Only feasible if the provider supports custom cert uploads.

Other Considerations:

ALIAS is Non-Standard: Implementations vary. Check your DNS provider's documentation on how their ALIAS records handle TTLs and target resolution frequency.
Potential CDN Edge Cases: While less common now, some older CDN setups relied heavily on CNAMEs for optimal geographical request routing; ALIAS might behave differently, though often providers optimize this.

Conclusion: Informed Choices

The standard CNAME record provides convenience and enables frictionless certificate management by implicitly delegating CAA authority to the service provider. While often desirable, this might not meet everyone's control requirements.

Using a non-standard ALIAS record offers a way to regain that control, ensuring CAA checks remain within your domain's authority. However, this "trick" comes at the cost of potentially breaking the provider's automated certificate issuance processes. If you choose the ALIAS path, you must be prepared to take deliberate action – either by carefully crafting specific CAA records for each ALIASed hostname or by taking on manual certificate management.

Understanding this interplay between CNAMEs, ALIAS records, and CAA lookups empowers you to make an informed decision. Weigh the benefits of explicit control against the operational requirements, consider your security policies and your provider's capabilities, and choose the approach that best suits your needs for each specific service integrated with your domain.