CAA and CNAME records

cname

#1

How do CAA records work with CNAME records?
I read online that CAA records are supposed to follow CNAMEs so it resolves like this:

;QUESTION
status.sixcorners.app. IN CAA
;ANSWER
status.sixcorners.app. 215 IN CNAME stats.uptimerobot.com.
stats.uptimerobot.com. 270 IN CAA 0 issue "letsencrypt.org"

but it seems like most of the time, or if I just query matt.ns.cloudflare.com directly, I get this:

;QUESTION
status.sixcorners.app. IN CAA
;ANSWER
status.sixcorners.app. 285 IN CAA 0 issue "letsencrypt.org"
status.sixcorners.app. 285 IN CAA 0 iodef "mailto:[email protected]"

I can get the former response to come back if I ask 1.1.1.1 for something that includes the CNAME like an A record then ask it for the CAA record. I can get the latter to come back if I don’t let the CNAME get cached in the resolver and just ask for the CAA record first.
Also cloudflare lets me add CAA records to hosts that have CNAMEs.

I think this is a bug.


#2

Where did you see that CAA and CNAME were related?

CAA is just a listing for which certificate authorities are allowed to issue certificates for your domain. You have CAA records for your subdomain, which isn’t going to do much.


#3



Also these dns resolvers are following the CNAME to get to the CAA if they have the CNAME cached.


#4

Where did you see that CAA and CNAME were related?

A basic understanding of how DNS works? status.sixcorners.app is a CNAME to stats.uptimerobot.com, therefore in most cases this is the only response that would be valid for an authoritative server to return in most cases.

There is nothing special about CAA here, if one does a A, AAAA or CAA query for status.sixcorners.app then you’ll get a CNAME which means you try the same query again against the target of the CNAME (stats.uptimerobot.com). This is pretty straightforward.

Where it gets more interesting is that uptimerobot.com itself is hosted by Cloudflare, although a different set of Cloudflare nameservers. The traditional expected result is that matt.ns.cloudflare.com. and roxy.ns.cloudflare.com. would return a CNAME, while darwin.ns.cloudflare.com. and cruz.ns.cloudflare.com. would not know anything about sixcorners.app but would be able to answer for stats.cloudflare.com.

However, Cloudflare plays fast and loose with the DNS specs, essentially “flattening” the request for status.sixcorners.app and returning the results of the CNAME. If uptimerobot.com's zone were hosted elsewhere then I would argue this is a bug which should be resolved but since it happens to be hosted at Cloudflare as well, this is a usually-safe, if not pedantically accurate optimization.

It is going to limit issuance of certificates for this subdomain, which is the intended result.


#5

Does CAA even care of you have a CNAME? I’ve read through this a couple of times and am seeing how the CAA query is following the CNAME trail. I’m not quite making the connection…yet.

CAA records are inherited by subdomains. I guess you could set CAA for a subdomain, but it’s not a use case I’ve seen. Though it could come in handy in special circumstances.


#6

Thanks for the citation. I’m reading through it now…


#7
;; QUESTION SECTION:
;status.sixcorners.app.		IN	A

;; ANSWER SECTION:
status.sixcorners.app.	300	IN	CNAME	stats.uptimerobot.com.
stats.uptimerobot.com.	300	IN	A	69.162.67.138

It’s not flattening anything. The CAA records in the bottom example are ones that I added to get the status page working. I can set both CAA and CNAME records on this subdomain and as long as the CNAME isn’t cached then my CAA records come back.


#8

That inheritance thing is called “tree-climbing” I think and according to the let’s encrypt link I linked earlier that behavior is removed by an erratum and isn’t implemented by let’s encrypt.
I remember setting a CAA on an “aws” subdomain so I could make use of the free certs they allow you to use with their load balancers but I didn’t keep that configuration for long. At the time I didn’t want to let them create certs for my whole domain.


#9

So…(still learning here)…if CAA follows the CNAME, does this mean your CAA record actually does anything?


#10

I think in the case of the first example in the original post it would mean that lets encrypt would be able to make a cert on my status.sixcorners.app domain.
I CNAMEd the status subdomain to uptimerobot so whatever records they have there are semi transparently also on my subdomain.


#11

Let’s Encrypt, to be specific, uses a typical DNS resolver. The effects of an invalid CNAME + other record configuration like this will vary depending on what was queried first and what’s in the cache (and the resolver configuration).

Since both status.sixcorners.app's invalid CAA records and stats.uptimerobot.com's CAA record allow Let’s Encrypt, it will work either way.

I don’t know how exactly any other CAs implement it.

You should delete the CAA records (or the CNAME).

Cloudflare shouldn’t have allowed you to create them both.


#12

Just deleted the CAA records now I get this:

;; QUESTION SECTION:
;status.sixcorners.app.		IN	CAA

;; AUTHORITY SECTION:
sixcorners.app.		3600	IN	SOA	matt.ns.cloudflare.com. dns.cloudflare.com. 2028528732 10000 2400 604800 3600

If I query for an A record then the CNAME gets cached and when I query for CAA again I get this:

;; QUESTION SECTION:
;status.sixcorners.app.		IN	CAA

;; ANSWER SECTION:
status.sixcorners.app.	293	IN	CNAME	stats.uptimerobot.com.
stats.uptimerobot.com.	299	IN	CAA	0 issue "letsencrypt.org"

#13

:open_mouth: That’s just buggy. Yikes. I can reproduce it with one of my domains.

Under the circumstances, maybe you should add the CAA records back until Cloudflare fixes the bug.

Are they reading this thread?

Edit: I have no tact and I filed ticket #1559781 with a link to this topic. It only occurred to me to mention the second issue though.


#14

Hi there folks - DNS Product Manager here. We are aware of this issue and are working to resolve.


#15

Wouldn’t want to be the one that has to solve this… How do you handle the people who currently have CAA records on subdomains that also have CNAMEs? I bet it’s not a big pool of customers.
Thanks for looking into this.


#16

In short, you don’t. A CNAME cannot coexist with a CAA or nearly any
other type of record, instead the correct place to create the record is
at the destination.

Cloudflare does a sloppy job of pretending what a CNAME is and how it
works, which creates some odd side effects.


#17

Right, so if customers already have this configuration are they just going to delete the CAA records?


#18

The named behaviour (and in my opinion, the correct behaviour) would be
to refuse to load the zone until the invalid records are fixed. A better
approach (combined with the above) would be to develop a UI that
prevents misconfigurations.

I’m unclear how Cloudflare will approach this as their DNS
implementation is not particularly standards compliant which allows
customers to shoot themselves in the proverbial foot like this.

At the end of the day, serving both a CAA and CNAME will result in
undefined behaviour because there is no particular order in which any
particular client will query for one vs the other and the RFCs are
silent on how this should work since the configuration is a MUST NOT. A
client might check the CAA record first (in which case it may get used)
or a A/AAAA record first (in which case the CNAME is cached and will be
returned by their resolver for all queries including CAA queries).


#19

As a bikeshed painter and representative of the peanut gallery, I think I’d vote for disabling the CAA record set without deleting it, and showing a warning in the dashboard. And maybe emailing people who never log in.