What are CAA records, CAA strategies, and CAA detection?

　　Those working in cybersecurity, or those responsible for managing company domains, have likely encountered this situation: a certificate suddenly appears under a domain name even though you haven't used one from a particular Certificate Authority (CA); or when applying for a certificate, the CA tells you "CAA check failed," leaving you inexplicably stuck for several days. The root of these problems is inextricably linked to three core concepts of CAA: CAA records, CAA policies, and CAA checks. Many people use these terms interchangeably, but they are actually different things.

　　I. CAA Records: A "Whitelist" Written in DNS

　　CAA records stand for Certificate Authority Authorization records. It's a text record in the DNS with a very simple function: informing CAs worldwide who is qualified to issue SSL certificates for your domain and who is not.

　　By default, hundreds of CAs worldwide 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 have a certificate incorrectly issued. A CA (Certificate Authority) is like a "whitelist" posted on 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? It has a three-part format: [flag] [tag] [value].

　　The three fields mean the following:

　　flag (flag bit): Controls how the CA handles unrecognized commands. A value of 0 means the CA will ignore the command; a value of 128 means the CA must understand the command, otherwise it will refuse to issue the certificate.

　　tag (command type): Tells the CA what this record is authorizing. Common tags include issue (authorizing a regular certificate), issuewild (authorizing a wildcard certificate), and iodef (setting a violation notification address).

　　value (authorized object): Specifies which CA is authorized to. The format is either the CA's domain name (e.g., "sectigo.com") or the email address to receive violation notifications.

　　The most common configuration examples include:

　　0 issue "sectigo.com": Only allows Sectigo to issue regular certificates.

　　0 issuewild "digicert.com": Only allows DigiCert to issue wildcard certificates.

　　0 iodef "mailto:admin@yourdomain.com": Sends you an email notification when a violation attempt is made.

　　Where are CAA records located? CAA records follow a "nearest to furthest" principle—the CA will start from the domain you are applying for a certificate on and search upwards, stopping at the first CAA record found. CAA records for subdomains will overwrite those for the parent domain. If the domain has a CNAME record set, the CA will directly look for the CAA record of the CNAME target domain because CNAME has the highest priority and cannot coexist with other records.

　　What if no CAA record is set? Any CA can issue a certificate for this domain—it's like not having a whitelist posted on your door; locksmiths all over the city can make your keys.

　　II. CAA Strategy: Your "Access Control Rules"

　　A CAA strategy addresses the question of "how should I write this whitelist?"

　　A CAA record itself is just a piece of data, but around this data, you need to make a series of decisions. These decisions together constitute your CAA strategy. Simply put, the strategy is your "access control rules":

　　1. Which CAs to authorize?

　　Authorize only one (e.g., only use Let's Encrypt free certificates)

　　Authorize multiple CAs (e.g., Sectigo + DigiCert + GlobalSign)

　　Authorize wildcard certificates and non-wildcard certificates to different CAs respectively.

　　2. Should you distinguish between regular certificates and wildcard certificates?

　　If you only configure an issue without configuring issuewild, the CA will use the issue's authorization rules. You only need to configure issuewild separately when you need to authorize them separately.

　　3. How to notify users of violations?

　　Should we configure iodef to receive alerts? Should we configure email or an HTTP endpoint?

　　4. How to manage subdomains?

　　Configure a unified whitelist on the root domain; all subdomains share the same whitelist.

　　Configure separate whitelists on critical subdomains, overriding the rules on the root domain.

　　Practical factors to consider when formulating strategies:

　　Business needs: If your company uses certificates from multiple CAs (e.g., Tencent Cloud certificate for the main site, Let's Encrypt for the test environment), all of them must be authorized in the CAA record.

　　CA change risks: If you decide to switch from Sectigo to DigiCert, you need to add the new CAA record first, and then apply for a new certificate after it takes effect—if the order is reversed, the certificate will not be issued.

　　Rollback contingency plan: Before configuring the CAA record, make a complete backup of the existing DNS configuration. In case of incorrect configuration leading to certificate renewal failure, a quick rollback is possible.

　　III. CAA Detection: The "Passport" Checked by Both CAs and Domain Owners

　　CAA detection refers to two aspects: the mandatory checks performed by CAs before issuing certificates, and the verification checks performed by the domain owner.

　　Mandatory Checks by CAs

　　This is the core execution step of the CAA mechanism. In March 2017, the CA/Browser Forum passed Proposal 187, requiring all CAs to implement mandatory CAA checks starting September 8, 2017.

　　The specific process is as follows: When you apply for an SSL certificate from a CA, the CA, upon receiving the request, will first query your domain's DNS to see if there is a CAA record:

　　If there is no CAA record, the CA assumes there are no restrictions and can issue the certificate normally.

　　If there is a CAA record and the CA is authorized, the certificate will be issued normally.

　　If there is a CAA record but the CA is not authorized, the certificate will be refused.

　　If the CAA check fails, the certificate application will be stalled, and you may receive an error message like "CAA validation failed."

　　Domain Owner's Self-Verification

　　As the domain owner, you also need to know how to perform CAA checks—verifying whether the CAA record is effective and correctly configured.

　　The method is simple: use the `dig` command. If it returns the content of your configured record, it's effective. If it returns nothing, the record might not be configured correctly, the TTL might not have expired, or your DNS provider might not support CAA.

　　There are also online tools for CAA queries; simply enter the domain name to see the results.

　　Additionally, to troubleshoot "why the certificate application was rejected," it's recommended to query the parent domain's CAA record—CA checks are performed hierarchically, and sometimes the problem lies with the parent domain, not the subdomain you applied for.

　　The Relationship and Collaboration Process of the Three

　　Connecting these three concepts makes it easier to understand:

　　The essence of a CAA record is text data in DNS, clearly stating the list, which is added by the domain owner during the DNS configuration phase.

　　The essence of a CAA policy revolves around management decisions regarding CAA records (such as who to authorize and how to notify). This is also the responsibility of the domain owner, and must be clearly defined before configuring records.

　　CAA verification is essentially a combination of mandatory checks by the CA and self-verification by the domain owner. It is jointly executed by the CA and the domain owner, occurring during each certificate application and the verification process after record configuration.

　　The collaborative process is: You first formulate a CAA policy (clarifying which CAs to authorize) → Add CAA records to the DNS according to the policy → Use `dig` to perform a CAA verification to confirm its effectiveness → The next time you apply for a certificate, the CA will perform a mandatory CAA verification; only if it passes will the certificate be issued.

　　Common Problems Quick Troubleshooting

　　1. Certificate application rejected, indicating CAA-related issues

　　Use `dig yourdomain CAA` to check existing CAA records and see if the CA you applied to is on the whitelist. Also check if the parent domain has set stricter CAA restrictions—CAs are checked hierarchically upwards; subdomain records override parent domain records, but parent domain restrictions can also affect subdomains. 1. If you recently modified the CAA record, you need to wait for the TTL to expire (DNS cache refresh) before trying again.

　　2. How does the CA handle multiple CAA records configured for the same domain?

　　Multiple issue records are in a "union" relationship—as long as the CA requesting the certificate matches any one of them, the request is approved. Issue records are independent notification configurations and do not interfere with the authorization logic.

　　3. My service provider says "CAA records are not supported."

　　According to RFC 1035, DNS should return NOERROR instead of NOTIMAP for unrecognized query types (including CAA). If your DNS service provider returns NOTIMAP or SERVFAIL for CAA queries, it indicates a flaw in their implementation; consider switching DNS hosting providers.

　　4. A subdomain has a separate CAA configured, but the CA doesn't seem to be following its instructions?

　　Check if the subdomain has a CNAME record set. If the subdomain has a CNAME record pointing to another domain, the CA will directly query the CAA record of the CNAME target, without querying the subdomain itself.

　　In summary: CAA records are "whitelist" data written in DNS; CAA policies are the decision-making and management rules surrounding this data; and CAA verification is the mandatory action taken by the CA when issuing certificates and your own verification methods. Understanding these three concepts will greatly clarify your troubleshooting approach when encountering CAA-related issues in the future.