How to test if a negetive CAA entry works?

Hey everybody

I did build a DNS debugger that sometime responds with an IP that I don't control so I would like to be sure that nobody can use these responses.
I set the CAA records to ;

My domain with the manual is on this domain: dynamic.estada.ch

One of the "risky" domains is resolver-ip.dynamic.estada.ch

My hosting provider, if applicable, is: myself

I can login to a root shell on my machine yes

Cheers

1 Like

You can also use any ACME client of your choice and try issuing a certificate for the domains in question.

Note that many CA's, including Let's Encrypt, do not support CAA iodef, so you won't see any mails regarding (failing) CAA.

Also, some remarks regarding your CAA record:

;; ANSWER SECTION:
dynamic.estada.ch.      60      IN      CAA     128 issue ";"
dynamic.estada.ch.      60      IN      CAA     128 issuewild ";"
dynamic.estada.ch.      60      IN      CAA     128 iodef "mailto:abuse@estada.ch"

You have set the critical flag (bit 7) of all your CAA records. As per RFC 8659, this is not currently allowed. As per the current specification, the flag should be 0. The critical bit is meant for future extensions, not the current spec.

Additonally, having both issue and issuewild set to the same value is redundant. issue controls all issuance, if issuewild is not present. So you do not actually require the issuewild directive in your case.

5 Likes

So if I want a TLS Cert for dynamic.estada.ch but not for anything under that tree:
Do I have to respond with something else below the dynamic part and allow it on dynamic.estada.ch?
Or can I confirm a cert since I allow it on estada.ch?

1 Like

CAA records are searched bottom to top*. The first result found is used. So for an example domain foo.dynamic.estada.ch the CA first looks up CAA for foo.dynamic.estada.ch, then dynamic.estada.ch, then estada.ch and finally ch.

Given that you currently seem to have a wildcard CAA record for *.dynamic.estada.ch you could use that for a denying CAA and set a permissive CAA on dynamic.estada.ch only to achieve what you want. Another option would be to remove the CAA records on dynamic.estada.ch entirely, which would cause the CAA record on estada.ch to take precedence.

*Assuming no CNAMEs are in the tree. With CNAME the query gets a bit complicated.

2 Likes

I have wildcard denied and issue allowed on estada.ch. However, I can still request certificates for singles hosts below estada.ch. I still need to deny both one level below dynamic.estada.ch.

The CNAME complications start when I point outside the dynamic.estada.ch tree, yes?
So, someone pointing into that tree can apply their rules, but it won't appear as "my" certificate, yes?

1 Like

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