A CAA allows specifying which Certificate Authorities are authorized to issue a certificate for my domain. For example

example.com. CAA 0 issue "symantec.com"

will only allow Symantec to issue certificates for example.com.
However as explained in Why don't browsers check CAA records to help ensure a certificate is valid? this is not verified or enforced by browsers. There is no reason to set it to the CA that issued the current certificate.

With that in mind: would it not be more secure to set the CAA-record to an invalid CA like this:

example.com. CAA 0 issue "doesnotexist.com"

That way nobody can issue a certificate.

My certificate is still valid for several years from now and I will not need any CA to issue a certificate right now. When time comes I will temporarily change the CAA record to the specific CA to allow it.

  • There is no point to set CAA entry to fake name. And you will have to change the CAA entry to correct name in advance when you are going to renew public certificate.
    – Crypt32
    Commented Dec 6, 2018 at 5:49
  • @Crypt32 can you explain why there is no point to a fake name? Would it not help prevent any malicious user from getting a certificate? I am aware I need the change the entry when i want to renew the certificate but that is only once every 3 years.
    – Jeff
    Commented Dec 7, 2018 at 12:34
  • I don’t see any security threat here. By defining a CAA record you automatically exclude all CAs which are not listed in CAA record. So only your defined CA is eligible to issue certificates to your domain. And it is very unlikely that your CA will permit two unrelated accounts (which are not part of the same organization) to own the same domain. Also, CAs may check for CAA record after issuance and raise questions to you.
    – Crypt32
    Commented Dec 7, 2018 at 14:04

1 Answer 1


In short, no.

And here it is why.

1. Do not use made up names

Whatever you do on the Internet, when you really need fake/obfuscated name, do not just invent some and hope that it will be fine in the future for everyone. By that reasoning, .MAIL has become a TLD that will never exist because it has been abused by so many documentations.

RFC 2606 provides you with a set of correct values for such a case, basically, example.com, example.net and .example TLD.

2. Empty CAA records

But using "fake" names is not even necessary for CAA records. The RFC 6844 gives this example:

For example, the following CAA record set requests that no
certificates be issued for the domain 'nocerts.example.com' by any
certificate issuer.

nocerts.example.com       CAA 0 issue ";"

So just do that, do not invent a fake name.


Is your domain DNSSEC-enabled?

If not, CAA records can be spoofed or dropped

4. Use of CAA records: issuance time vs use time

"this is not verified or enforced by browsers."

They do not need to. Per CAB Forum requirements (section of https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.2.pdf), nowadays all CAs are required to check for CAA records at certificate issuance time.

This is when it matters because the certificate will be valid for let us say 1 year; and during this timeframe the DNS CAA record can be changed to many things, so at use (connect) time the browser may get a completely different answer than the one at certificate issuance time.

And Crypt32 said it in the comment, as written in the requirements: "This stipulation does not prevent the CA from checking CAA records at any other time."

But feature wise, you are probably more thinking about DANE and its TLSA records, see RFC 6698 and 7671.

They would provide to clients the insurance, at connect time, for any given service, that the server indeed should be using either the certificate or public key exposed in the TLSA records or a certificate signed by a specific authority whose certificate is in a TLSA record.

Of course:

  1. you need a DNSSEC enabled zone for them to be useful, otherwise trivial downgrade attacks are possible, and
  2. clients need to use these records, otherwise they can not enforce the rules you put in place; unfortunately for now for browsers it is at most an add-on and certainly not a base feature.
  • You can use .invalid to guarantee it will never be used.
    – forest
    Commented Jan 3, 2019 at 3:54
  • @forest yes it is listed in RFC 2606, as well as .example I cited, and .test and .localhost Commented Jan 3, 2019 at 4:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .