CAA 403 issue, with multiple CNAME configuration

Help
1

Hi,

Not a DNS expert, confused, so I figure I’ll ask for some assistance. We have the following DNS configuration to allow for ‘vanity’ URLs:

CNAME: sample1.<clientA>.com     -->    clientA.<our-domain>.com
CNAME: clientA.<our-domain>.com  -->    <nlb-address>.amazonaws.com
A: <nlb-address>.amazonaws.com   -->    <some-ips>

Other factors:

  • Constraint; our ‘clientA’, has 2 CAA records in place for their domain “clientA.com”, one for wildcard and one for top domain.
  • We use Let’s Encrypt to provide a cert for the domain “sample1.clientA.com”.
  • We currently have no CAA records in place.

Problem: Let’s Encrypt cannot issue a cert for “sample1.clientA.com”. It returns a 403 error “CAA record for sample1.clientA.com prevents issuance”.

According to Let’s Encrypt (and RFC6844) docs it follows the CNAME when trying to issue a cert.

Therefor should we be configuring a CAA record on “our-domain.com” or should we be asking the client to configure an additional CAA record on their “clientA.com” domain, or maybe even “amazonaws.com” given the multiple CNAMEs?

2

I wrote a different response but had to backspace it, because I suddenly saw what your problem is. You need to, but are not able to put a CAA record on clientA.our-domain.com because it’s a CNAME to the NLB.

Assuming you use Route53, is there any chance you can use ALIAS rather than CNAME for pointing clientA.our-domain.com to the NLB?

Something like:

clientA.our-domain.com.    0    ALIAS    nlb-address.amazonaws.com.
clientA.our-domain.com.    0    CAA      0    issue "letsencrypt.org"

IDK if Route53 allows that (I checked, this works fine - and it makes your DNS speedier since it avoids one CNAME indirection).

If not, your only other choice might be to add a permissive CAA record on clientA.com.

1 Like
3

Thanks @_az,

We don’t use Route53 (yet), we currently use cloudflare. We will however added the same records as you suggested. I.e. ALIAS instead of CNAME and then the CAA record.

Last resort would be to ask our client to add the permissive CAA record.

Will let you know what works. Thanks heaps…

4

I don’t think that Cloudflare supports ALIAS records - only “CNAME flattening” at the zone apex. That solution would be a Route53-specific one.

So it looks like relaxing the client domain’s existing CAA record is your only choice for now.

5

If you're on one of Cloudflare's paid plans, you can enable CNAME flattening on all subdomains.

6

IIRC doesn’t cloudflare put own CAA record autometically with their universal cert’s CA in it?

7

@_az, I have successfully tested the following setup. I’ve added the relevant CAA records to our top level domain i.e. our-domain.com, like so:

our-domain.com.     IN	CAA	0 issue "letsencrypt.org"
our-domain.com.     IN	CAA	0 issue "sectigo.com"
our-domain.com.     IN	CAA	0 issuewild "letsencrypt.org"
our-domain.com.     IN	CAA	0 issuewild "sectigo.com"
our-domain.com.     IN	CAA	0 iodef "mailto:monitor@our-domain.com"

According to RFC 6844 the client’s CNAME will be followed back to our domain, hence I tried this solution, which seem to work. Or am I missing something here?

8

Good point. Reading the RFC, it looks like the CNAME target takes priority over the parent domain. Sorry for my earlier misleading response!

Actually, I’m still not sure whether it works that way. Wouldn’t the CAA lookup end up at amazonaws.com because of the further CNAME?

9

Yeah it confuses me too. Is it maybe because it only checks a single CNAME reference and not climbs the DNS tree? This would also explain that it doesn’t work (without our CAA records) as the next record it would check (according to the RFC) would be the client’s parent domain, with in our case the restrictive records.

10

Somehow my testing was flawed :frowning: Adding CAA records to our top-level domain didn’t work after all. So back to the drawing board. I wonder if I can use Route53 just to introduce an ALIAS record without moving the whole DNS to it, as per @_az earlier comment.

11

Just to clarify CAA CNAME behavior: CAA only climbs the DNS tree for the original domain, CNAMEs do not alter subsequent steps in the tree. For example given a domain name x.y.z where x.y.z CNAME a.b.c CAA records will be checked for the domain names (after following CNAMEs) a.b.c, y.z, z, the records for b.c etc will not be checked.

3 Likes
12

Thanks @roland. That makes much more sense now and would explain the bevaviour in our setup: x.y.z CNAME a.b.c CNAME d.e.f.

Based on your comments this setup would follow a.b.c, d.e.f, y.z, z, I think :slight_smile: Thereby preventing the issuance, because of the following constraints:

  1. restrictive CAA on y.z

  2. no control over 3rd party domains x.y.z and d.e.f

  3. cannot apply CAA records on a.b.c because of CNAME to d.e.f.

Would I be correct to say that a solution could be:

  • ALIAS a.b.c to d.e.f and add CAA for a.b.c, or

  • ALIAS x.y.z to a.b.c and add CAA for x.y.z, to be done by the 3rd party.

13

Yes.

Yes. Of course, your customer's DNS service would have to support it, you would have to get them to add the CAA records, and it would make it more difficult for you to change the CAA records in the future.

3 Likes
14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.