What is the purpose of CAA records? A security configuration to prevent SSL certificates from being incorrectly issued.

　　A CAA record is a DNS record with a single purpose: to inform Certificate Authorities (CAs) worldwide who is qualified to issue SSL certificates for your domain. By default, hundreds of CAs globally can issue certificates for your domain as long as it passes domain verification (e.g., verifying your control over the domain). This means that if any of these hundreds of CAs has a flaw in its verification process, your domain could potentially be incorrectly issued a certificate. A CAA is essentially a "whitelist" posted at your door; CAs not on the list are not allowed in.

　　Since September 8, 2017, all CAs have been required to check CAA records before issuing certificates. This is a mandatory industry requirement, not an option.

　　What does a CAA record look like?

　　The CAA record has a three-part format: [flag] [tag] [value].

　　In simpler terms:

　　How to use the three tags:

　　1. Issue – Most commonly used

　　Specifies which CA can issue the document. Enter the CA's domain name.

0 issue "letsencrypt.org"

　　The above record means: Only Let's Encrypt is allowed to issue certificates for this domain; no other CAs are permitted.

　　If you need to authorize multiple CAs, add multiple records:

0 issue "letsencrypt.org"
0 issue "sectigo.com"

　　2. issuewild – Specifically for wildcard certificates

　　Wildcard certificates (*.yourdomain.com) have significant authority; one certificate can cover all subdomains. Use this tag if you want to impose specific restrictions on wildcard certificates.

0 issuewild "sectigo.com"

　　This means: Only Sectigo can issue wildcard certificates for me.

　　Note: If `issuewild` is not configured, the CA will use the authorization rules of `issue`. You only need to configure it separately if you need to set different CAs for wildcard and non-wildcard certificates.

　　3. `iodef` – Violation Notification

　　If someone attempts to apply for a certificate for your domain without authorization, the CA can send you an alert to this address.

0 iodef "mailto:admin@Your domain.com"

　　Supports email addresses and HTTP/HTTPS URL endpoints. This configuration is typically used in conjunction with whitelist records.

　　CAA Record Placement: Inheritance Logic of Parent and Child Domains

　　CAA records are "recently found." When checking, the CA starts from the domain where you are applying for a certificate and searches upwards level by level, stopping when it finds the first CAA record.

　　For example:

　　You have configured a CAA on example.com, allowing only Let's Encrypt.

　　Then someone wants to apply for a Sectigo certificate for api.example.com.

　　The CA's check path is: api.example.com → Not found → example.com → Found, allows Let's Encrypt, denies Sectigo.

　　If you want to authorize api.example.com with a different CA, simply add a CAA record to the subdomain. The subdomain record will overwrite the parent domain record.

　　Pay special attention to CNAME records: If api.example.com has a CNAME record pointing to api.cdn.com, the CA will directly look up the CAA record of api.cdn.com, and will not look up api.example.com itself. This is because CNAME records have the highest priority; once a domain has a CNAME record set, other records cannot coexist.

　　How to Add a CAA Record?

　　The actual operation is not complicated, but there are a few details to note.

　　Step 1: Confirm your DNS provider supports CAA.

　　Most mainstream DNS providers support it. If your provider does not, you may need to consider switching to a different DNS provider.

　　Step 2: Log in to the DNS console and add a record.

1. Locate the domain's DNS settings page.
2. Click "Add Record".
3. Select CAA as the record type.
4. Host Record: @ represents the main domain; if you want to set a separate record for a subdomain, enter the subdomain prefix (e.g., api).
5. Record Value: Enter the value in the format of flag tag value.
6. TTL is 600 seconds by default.

　　Step 3: Wait for it to take effect and verify.

　　After adding the record, wait a few minutes to tens of minutes and verify it using the `dig` command.

dig Your domain CAA

　　Example of returned results:

;; ANSWER SECTION:
example.com.  600  IN  CAA  0 issue "letsencrypt.org"
example.com.  600  IN  CAA  0 iodef "mailto:security@example.com"

　　If an empty result is returned without errors, it means the current domain does not have a CAA record configured (i.e., "allow all CAs").

　　Regarding "CAA Unauthorized" Errors

　　If you encounter errors like "CAA unauthorized" when applying for an SSL certificate, the reason is simple: your domain's current CAA whitelist does not include the CA you are applying to.

　　There are two solutions:

　　Add an authorization record for that CA in your DNS.

　　Switch to a CA that is already on the whitelist and reapply.

　　Resubmit your order after the DNS changes take effect.

　　Regarding CAA Query Failures

　　What happens if a CA cannot find a CAA record? The answer might surprise you: not finding a CAA record is equivalent to "allowing all CAs." The design logic of CAA is "default allow, explicit denial"—if you don't actively set restrictions, the CA assumes you have authorization.

　　However, if a DNS error such as SERVFAIL occurs during the query process, the CA cannot determine whether there is no record or it cannot be found, and will usually refuse to issue a certificate as a conservative security strategy.

　　Common Misconceptions

　　Misconception 1: CAA is mandatory, so I don't need to worry about anything.

　　CAA is a mandatory verification obligation of CA organizations. However, if the domain owner doesn't actively set up a CAA record, it's equivalent to "authorizing all CAs," and it won't automatically protect you.

　　Misconception 2: CAA can prevent my private key from being leaked or brute-forced.

　　No. CAA only cares about "who is qualified to issue certificates," not "whether your private key is secure." It solves the problem of external CAs issuing certificates incorrectly, not the server's own security.

　　Misconception 3: Having a CAA certificate guarantees absolute security.

　　CAA simply adds a layer of protection, reducing the risk of the "CA being compromised" chain. If the CA itself is compromised or the process malfunctions, CAA cannot completely prevent it. But it can at least ensure that even if a CA has issues, as long as I haven't authorized it, it can't touch my domain.

　　One-sentence advice: If you're using HTTPS, take two minutes to add a CAA record to your main domain—only allowing the CA you're actually using. This is a layer of security with an extremely high return on investment, and the key is that it costs almost nothing.