CNAME chaining disallowed in ADN selection

70 views
Skip to first unread message

Jacob Hoffman-Andrews

unread,
Nov 13, 2025, 1:02:37 PMNov 13
to valid...@groups.cabforum.org
From today's call, I'd like to split out a topic that deserves its own discussion.

In 2024, on a GitHub issue (https://github.com/cabforum/definitions/issues/5), Clint Wilson pointed out:
  • It could also, possibly, be argued that this phrasing means that CNAME chaining is disallowed for the purposes of identifying an Authorization Domain Name.
  • The RDATA of the CNAME query must, by definition, return an FQDN, but nothing here seems to imply that it's acceptable to then perform a second DNS query for that returned FQDN, following the theoretical alias set in that CNAME record to a secondary returned FQDN.

This surprised me, until I checked RFC 1034 (https://www.rfc-editor.org/rfc/rfc1034.html#page-24), and indeed, chains of CNAMEs are followed for every type of DNS lookup _except_ a DNS CNAME lookup:

            If the data at the node is a CNAME, and QTYPE doesn't
            match CNAME, copy the CNAME RR into the answer section
            of the response, change QNAME to the canonical name in
            the CNAME RR, and go back to step 1.

            Otherwise, copy all RRs which match QTYPE into the
            answer section and go to step 6. 

The simplest way to demonstrate this is with a pair of dig invocations:

$ dig A www.walmart.com @1.1.1.1
...
;; ANSWER SECTION:
www.walmart.com. 274 IN CNAME www.walmart.com.ultradns-wal.co.
www.walmart.com.ultradns-wal.co. 34 IN CNAME www.walmart.com.edgekey.net.
www.walmart.com.edgekey.net. 21574 IN CNAME e4373.x.akamaiedge.net.
e4373.x.akamaiedge.net. 11 IN A 23.75.208.191 

$ dig CNAME www.walmart.com @1.1.1.1
...
;; ANSWER SECTION:
www.walmart.com. 300 IN CNAME www.walmart.com.ultradns-wal.co.

I include @1.1.1.1 to make it clear this is behavior of the recursive resolver, not dig. All recursive resolvers will behave the same because this is how DNS is specified.

Here's the current language in the Authorization Domain Name definition:

> The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation.

To me, that's pretty clear: www.walmart.com.ultradns-wal.co can be an ADN for www.walmart.com. But www.walmart.com.edgekey.net cannot, and neither can e4373.x.akamaiedge.net.

Dimitris Zacharopoulos (HARICA)

unread,
Nov 20, 2025, 10:54:40 AM (10 days ago) Nov 20
to valid...@groups.cabforum.org
On a somewhat different topic (CAA), this is something that was brought up during F2F#66 during the CNAME chasing discussion. 

In the example above, if we assume that "walmart.com" has a CAA record with an "issue" tag with value "greatCA1", and "ultradns-wal.co" has CAA issue with value "greatCA2", and akamaiedge.net has CAA issue with value "greatCA3", which CAA record is the CA supposed to check and confirm it is authorized to issue?
  1. Only the CAA of the requested Domain Name "walmart.com";
  2. All CAA records of CNAME targets and make sure it is included in the authorization values; or
  3. Only the last hop "akamaiedge.net" because this is the final link to the IP address browsers will connect to.

My understanding of the protocol is that the correct answer is 1 because CAA is supposed to be a method for the domain owner applying for a certificate, to indicate their CA(s) of preference. Perhaps people have different views?


Thank you,

Dimitris.



Here's the current language in the Authorization Domain Name definition:

> The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation.

To me, that's pretty clear: www.walmart.com.ultradns-wal.co can be an ADN for www.walmart.com. But www.walmart.com.edgekey.net cannot, and neither can e4373.x.akamaiedge.net.
--
You received this message because you are subscribed to the Google Groups "Validation Subcommittee (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to validation+...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/CAN3x4QncbaPBeh7rNpGFiK6ckAzN7Vb%3DTARbBAvOrjBnSBjVKw%40mail.gmail.com.

Martijn Katerbarg

unread,
Nov 20, 2025, 11:23:15 AM (10 days ago) Nov 20
to valid...@groups.cabforum.org
Based on https://www.rfc-editor.org/rfc/rfc8659.html#section-7, CNAMEs do need to be followed, but CNAME targets shouldn’t be tree-walked.  (i.e. if www.walmart.com.edgekey.net is a CAA record, walking stops there, but we don’t go look for walmart.com.edgekey.net)

So based on the example, unless www.walmart.com is a CNAME to a place that does have a CAA record, yes. 

Technically I think that means 2 is correct, followed by 1 if no records are encountered before that stage. 

Regards,

Martijn

From: 'Dimitris Zacharopoulos (HARICA)' via Validation Subcommittee (CA/B Forum) <valid...@groups.cabforum.org>
Date: Thursday, 20 November 2025 at 16:54
To: valid...@groups.cabforum.org <valid...@groups.cabforum.org>
Subject: Re: [cabf_validation] CNAME chaining disallowed in ADN selection

This Message Is From an External Sender
This message came from outside your organization.
 

Aaron Gable

unread,
Nov 20, 2025, 11:50:27 AM (10 days ago) Nov 20
to valid...@groups.cabforum.org
Given this setup:
Then the CAA records that matter are:
- Any CAA records at e4373.x.akamaiedge.net (because a CNAME record cannot coexist with any other records, so we're guaranteed that there are not any CAA records at www.walmart.com or any of the intermediate hops)
- Any CAA records at walmart.com (or where its CNAME chain ends), if the point above did not return any CAA records
- Any CAA records at com (or where its CNAME chain ends), if the two points above did not return any CAA records

Aaron

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/SA1PR17MB6503F259A927B7D2E47F4910E3D4A%40SA1PR17MB6503.namprd17.prod.outlook.com.

Dimitris Zacharopoulos (HARICA)

unread,
Nov 20, 2025, 1:19:04 PM (10 days ago) Nov 20
to valid...@groups.cabforum.org


On 11/20/2025 6:50 PM, 'Aaron Gable' via Validation Subcommittee (CA/B Forum) wrote:
Given this setup:


Then the CAA records that matter are:
- Any CAA records at e4373.x.akamaiedge.net (because a CNAME record cannot coexist with any other records, so we're guaranteed that there are not any CAA records at www.walmart.com or any of the intermediate hops)

Thanks Aaron, I forgot that a CNAME is not allowed to have other records. So a Domain Owner would need to add a CAA record at the higher level (walmart.com) which happens to be the Base Domain Name in this example.


- Any CAA records at walmart.com (or where its CNAME chain ends), if the point above did not return any CAA records
- Any CAA records at com (or where its CNAME chain ends), if the two points above did not return any CAA records

So in your interpretation the end of the CNAME chase also needs to be checked for CAA despite being owned by a separate entity that has not applied for that FQDN to be included in a certificate? I'm not sure this is the intent of CAA but I'd appreciate some input by others.

Imagine multiple Domain Owners using a CDN provider. They would constantly need to notify that CDN provider to add CAA records allowing new CAs to issue. It doesn't sound right.


Thank you,
Dimitris.


Aaron Gable

unread,
Nov 20, 2025, 1:33:41 PM (10 days ago) Nov 20
to valid...@groups.cabforum.org
This is simply how DNS works. If you query for the CAA records for www.walmart.com, and that name is CNAMEd elsewhere, the recursive resolver will return the CAA records found wherever the chain of CNAME delegations terminates.

The old version of CAA (https://datatracker.ietf.org/doc/html/rfc6844) said that you had to follow CNAMEs, and do tree-climbing from those CNAMEs. This was a bad idea, because it doesn't actually match the semantics of DNS. The updated version of CAA (https://datatracker.ietf.org/doc/html/rfc8659) clarifies that yes, you must follow CNAMEs (because that's simply how DNS works), but that you don't tree-climb from them.

Aaron

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/6db4442d-5aad-4147-99b4-a02aa017cd2e%40harica.gr.

Dimitris Zacharopoulos (HARICA)

unread,
Nov 20, 2025, 1:35:07 PM (10 days ago) Nov 20
to valid...@groups.cabforum.org


On 11/20/2025 8:33 PM, 'Aaron Gable' via Validation Subcommittee (CA/B Forum) wrote:
This is simply how DNS works. If you query for the CAA records for www.walmart.com, and that name is CNAMEd elsewhere, the recursive resolver will return the CAA records found wherever the chain of CNAME delegations terminates.

The old version of CAA (https://datatracker.ietf.org/doc/html/rfc6844) said that you had to follow CNAMEs, and do tree-climbing from those CNAMEs. This was a bad idea, because it doesn't actually match the semantics of DNS. The updated version of CAA (https://datatracker.ietf.org/doc/html/rfc8659) clarifies that yes, you must follow CNAMEs (because that's simply how DNS works), but that you don't tree-climb from them.

Great, thanks for the clarification. It's clear to me now.

Dimitris.

Reply all
Reply to author
Forward
0 new messages