skip to content

What does a DNS CAA record at example.com actually enforce when a certificate authority is asked to issue for shop.example.com, and what does it not protect against?

level: seniorimportance: nice to knowfreq 18%

answer

  1. checked before issuance, not after
  2. climb the name tree
  3. closest set wins outright
  4. wildcards have their own tag
  5. browsers must ignore it

basics

~20 s

A compliant CA must look up CAA before issuing, climbing from shop.example.com toward the root to the first CAA set, and refuse if that set excludes it. Browsers must not check CAA, so rogue CAs are not stopped.

solid answer

~50 s

CAA (RFC 8659, which obsoletes RFC 6844) is an authorization check performed by the CA before issuance. The CA looks for CAA records at the requested name; if none exist it moves to the parent, and so on up to but not including the root, and the first non-empty set it finds is the relevant one. So `shop.example.com` inherits the apex policy unless it publishes its own, and its own set replaces the apex set rather than merging with it. `issue` names the allowed CAs, `issue ";"` allows none, `issuewild` governs wildcard requests and overrides `issue` for them, and `iodef` gives a reporting address. A property marked critical with a tag the CA does not understand blocks issuance. What it does not do: browsers MUST NOT use it to validate certificates, so it cannot stop a CA that ignores it, an attacker controlling your DNS, or certificates issued earlier.

code

dns · 4 lines
dns
example.com.        3600 IN CAA 0 issue "ca1.example.net"
example.com.        3600 IN CAA 0 issuewild ";"
example.com.        3600 IN CAA 0 iodef "mailto:[email protected]"
legacy.example.com. 3600 IN CAA 0 issue "ca2.example.org"

go deeper

for a junior

Recall that a CAA record lists which certificate authorities may issue certificates for a domain, and that the CA checks it.

for a middle

Explain the tree climb to the closest CAA set, what issue, issuewild and iodef mean, and why an empty issue value forbids issuance.

for a senior

Deploy CAA without breaking renewals: inventory every CA and automation that issues for your names, handle subdomain sets that replace the apex policy, and pair CAA with issuance monitoring.

for a principal

Position CAA within certificate governance: a cheap narrowing of who should issue, bounded by CA compliance, DNS account security and detection of what was actually issued.

## What CAA is for A **CAA** (Certification Authority Authorization) record lets a domain owner state which certificate authorities may issue certificates for a name. RFC 8659, which obsoletes RFC 6844, defines it as an **authorization control performed by a CA before issuing**, in contrast to controls a relying party applies after issuance. RFC 8659 also says conformance with CAA is "a necessary, but not sufficient, condition" for issuance: the CA still has to validate the requester. ## Finding the relevant record set Before issuing, a compliant CA **MUST** check for a **Relevant RRset** (RFC 8659 §3). The search climbs the name tree: 1. Query `CAA` for the requested name, following aliases as a normal lookup does. 2. If the answer is empty, remove the leftmost label and query the parent. 3. Repeat up to, but not including, the root `.`. 4. The first non-empty CAA RRset is the relevant one. If none is found, CAA does not restrict issuance. For `shop.example.com` with CAA only at `example.com`, the apex set applies. If `shop.example.com` publishes its own CAA records, that set is found first and the apex set is **never consulted**: sets replace, they do not merge. ## The properties | Tag | Meaning | |---|---| | `issue` | an issuer domain name allowed to issue; `issue ";"` names no issuer and forbids issuance | | `issuewild` | the same, but only for wildcard requests; when present it overrides `issue` for them | | `iodef` | a `mailto:`, `http:` or `https:` URL where a CA may report a request that violated the policy | Each record also carries a one-octet **flags** field. Bit 0, the most significant bit (flag value 128), is the **Issuer Critical** flag: if the relevant set holds a critical property with a tag the CA does not recognize, the CA MUST NOT issue. A set that holds only `iodef` or unrecognized non-critical tags does not restrict issuance at all. A malformed `issue` value is treated like an empty issuer name, which forbids issuance. ## Worked reading - `example.com` publishes `issue "ca1.example.net"`, `issuewild ";"` and an `iodef` address. - A request for `example.com` or `www.example.com`: only ca1.example.net may issue. - A request for `*.example.com`: the `issuewild` property overrides `issue`, and `";"` forbids every CA. - `legacy.example.com` publishes only `issue "ca2.example.org"`: its set replaces the apex set, so only ca2 may issue there, and with no `issuewild` in that set the `issue` property also governs `*.legacy.example.com`. ## What CAA does not protect against - **Browsers ignore it.** RFC 8659: "Relying Parties MUST NOT use CAA records as part of certificate validation." A certificate issued against the policy still validates in clients. - **Non-compliant or compromised CAs.** CAA binds only CAs that follow it; enforcement depends on the CA's own compliance. - **Certificates issued earlier.** CAA describes current grants only; a certificate issued before the record changed stays valid for its lifetime. - **An attacker who controls your DNS** can change the CAA records along with everything else. - **Forged answers.** RFC 8659 strongly recommends DNSSEC for CAA but does not require it; an issuer must still refuse when the unsigned answer forbids issuance. ## Deploying CAA without breaking issuance 1. **Inventory every issuer** that currently obtains certificates for your names, including automated renewals run by platforms and managed services. 2. **Publish `issue` for each of them at the apex**, plus an `iodef` address so compliant CAs can report refused requests. 3. **Decide wildcard policy explicitly** with `issuewild`; without it, `issue` governs wildcard requests too. 4. **Audit subdomain CAA sets**, because each one replaces the apex policy for its own subtree and can silently re-open or block issuance. 5. **Remember aliases**: the CA follows a `CNAME` during the lookup, so a name aliased into another organisation's zone can pick up that zone's CAA records. ## What interviewers probe The key points are that CAA is checked by the CA at issuance time, never by browsers; that the closest non-empty set wins outright; that `issuewild` and `issue` interact only for wildcard requests; and what `issue ";"` means. Good answers pair CAA with monitoring of issued certificates, because CAA narrows who should issue while only detection shows what was actually issued.

  • What does the critical flag change about a CAA property?
    Bit 0 of the flags octet (value 128) marks a property as critical. If the relevant set contains a critical property whose tag the CA does not recognize, RFC 8659 says the CA MUST NOT issue. It lets a domain add future policy tags that fail closed at CAs that do not yet understand them.
  • Why does RFC 8659 forbid browsers from using CAA to validate certificates?
    CAA records describe current grants only, and certificates live for months. A certificate that matched the records when issued may not match today's records, so rejecting it would break valid sites. CAA is defined as a pre-issuance check for CAs; detecting mis-issuance afterwards is a separate monitoring job.

saying these in an interview costs you the question

  • Browsers reject certificates from CAs not listed in the domain's CAA records.
  • A CAA record at a subdomain adds to the apex policy rather than replacing it.
  • No CAA records at all means no CA may issue for the domain.
  • issue with an empty value lets any CA issue.
  • CAA stops an attacker who has taken over the domain's DNS hosting.