skip to content

What does a CAA record in a domain's zone control, and when in the issuance flow is it consulted?

level: seniorimportance: nice to knowfreq 30%

answer

  1. the domain holder constrains the issuer
  2. checked before signing, never at connection time
  3. climb to the parent until a set is found
  4. issue, issuewild and iodef
  5. nearest record set wins outright

basics

~20 s

A CAA record lets the domain holder publish which certificate authorities may issue for a name. The issuing authority looks it up before signing, climbing to parent domains if the exact name has none; relying parties never check it.

solid answer

~50 s

`CAA` (RFC 8659) is a DNS record type through which the holder of a name states **which authorities are permitted to issue certificates for it**. Three property tags matter: `issue` names an authority permitted to issue for the name, `issuewild` governs wildcard issuance and takes precedence over `issue` for a wildcard request when present, and `iodef` gives an address where a refused or violating request should be reported. An authority performs the lookup at **issuance time**, climbing from the requested name up through its parent domains until it finds a record set; if none exists anywhere, any authority may issue. Empty issuance permission — a record whose value permits nobody — forbids issuance outright. It is a control on the issuing side only: a client validating a connection never consults it, and a certificate issued in violation still verifies normally.

code

pseudocode · 17 lines
pseudocode
before issuing for the requested name:
    set <- look up CAA record set at the requested name
    while set is empty and a parent domain remains:
        set <- look up CAA record set at the parent domain

    if set is empty:
        any authority may issue, proceed

    if the request is for a wildcard and set has an issuewild property:
        permitted <- values of issuewild
    else:
        permitted <- values of issue

    if this authority's identifier is not in permitted:
        refuse to issue
        if set has an iodef property:
            report the refused request to that address

go deeper

for a junior

The idea to hold on to is that by default any public authority can issue for your name, and a CAA record in your zone is how you narrow that list. It is read by the authority, not by the client.

for a middle

Be able to name the three property tags and their roles, and describe the tree-climbing lookup where the first record set found governs outright rather than merging with a parent's.

for a senior

Show the operational edges: a restrictive set at the apex blocking subdomains, wildcard requests governed by issuewild, and the fact that a failure appears at the next renewal rather than when the record changed.

for a principal

The judgement is how far to narrow issuance across an estate and who owns the zone change when that decision moves. Combined with a reporting address, it turns an unbounded trust set into one you chose and can watch.

## What a CAA record says By default, the issuance model has an uncomfortable property: **any** publicly trusted authority can issue a certificate for **any** name, and a client will accept it. `CAA` is the domain holder's answer to that. It is a DNS record type, specified in RFC 8659, that lets the holder of a name publish a list of the authorities permitted to issue for it, so that an authority not on the list refuses the request before doing any validation work. It is worth being precise about what kind of control this is: it binds the authorities that read it, because the rules public authorities are audited against require the check. It is not cryptography and it is not enforced by anyone validating a connection. ## The property tags A CAA record carries a flags byte, a property tag and a value. Three tags are in ordinary use: - **`issue`** — names an authority permitted to issue certificates for this name. Several records may appear, each naming one authority, and together they form the permitted set. - **`issuewild`** — governs issuance of wildcard certificates. When present, it takes precedence over `issue` for a wildcard request; when absent, `issue` governs wildcard requests too. - **`iodef`** — gives a reporting address, as a mail or web address, where an authority should report a request it refused or that violated the published policy. It permits nothing on its own. A record set that exists but permits nobody — an `issue` property whose value names no authority — is a deliberate statement that **no** certificate is to be issued for the name, and an authority honouring the check will refuse every request for it. ## How the lookup runs 1. The authority takes the name being requested and looks for a CAA record set at exactly that name. 2. If there is none, it moves to the parent domain and looks again, continuing up the tree. 3. The **first** record set it finds is the one that governs. A record set at a parent does not merge with one at a child; the nearest one wins outright. 4. If it reaches the top without finding a record set, the name is unconstrained and any authority may issue. 5. If the governing set exists and the authority's own identifier is not in the permitted set for the kind of certificate requested, it refuses to issue, and reports the attempt if an `iodef` address is published. ## What it does and does not do | Property | CAA gives you | CAA does not give you | |---|---|---| | Timing | a check before issuance | any check at connection time | | Enforcement | policy binding on authorities that follow the rules | a cryptographic guarantee | | Scope | future issuance for the name | anything about already-issued certificates | | Trust in the answer | only as much as the DNS lookup that found it | authenticity, unless the zone is signed | Three consequences follow, and each is the kind of thing a senior candidate is expected to volunteer: - **Nothing validates it later.** A relying party checking a certificate at connection time never looks at CAA. A certificate issued in violation of a published policy verifies normally, which is why the record is a preventive control and detection of mis-issuance is a separate mechanism. - **It is retroactively powerless.** Publishing a record today says nothing about certificates issued yesterday, which remain valid until they expire or are withdrawn. - **It inherits DNS's weaknesses.** The record is only as trustworthy as the lookup that retrieved it; a signed zone is what makes the answer authenticated rather than merely received. ## Where it earns its place For a fiscal receipt service whose names a revenue authority connects to, CAA narrows the set of parties who can mint an identity for those names from *every publicly trusted authority in the world* to *the ones you chose*. That is a large reduction for one zone change, and it costs nothing at runtime. The operational traps are equally concrete: - A record set placed at a parent domain governs every child that has none of its own, so adding one at the organisation's apex can block issuance for a subdomain nobody remembered. - Changing to a different authority means changing the record **before** the first request, not after it fails. - A wildcard certificate needs `issuewild` to be considered when a set is present and restrictive. - Automated renewal will start failing at renewal time, not at record-change time, so the failure can arrive months after the mistake.

  • Does a CAA record stop a client from accepting a certificate issued in violation of it?
    No. Nothing at connection time consults CAA: a relying party validates the certificate, the path to an anchor and the name, and none of those steps looks at the zone. A certificate issued in violation verifies exactly like any other. CAA is a preventive control on the issuing side; noticing that a violating certificate exists is a different mechanism, belonging to public logging of issued certificates.
  • A record set exists at the organisation's apex and a team's subdomain has none. Which one governs issuance for that subdomain?
    The apex one. The lookup climbs from the requested name upwards and the first record set found governs outright — sets do not merge, and a child does not inherit permissions in addition to its own. This is the common operational surprise: a restrictive set added at the apex quietly blocks issuance for every subdomain that never published one, and the failure appears at the next renewal.
  • What does the iodef property tag actually do?
    It publishes an address where an authority should report a request it refused, or one that violated the published policy. It grants no issuance permission of its own, and it gives the domain holder the only signal they would otherwise never see: that someone attempted to obtain a certificate for their name from an authority they had not permitted. Whether reports arrive depends on the authority honouring it.

A CAA record is a note the name's owner leaves at the counter saying which agencies may sign on its behalf. It binds the agencies that read the note, not the one that never looks.

saying these in an interview costs you the question

  • Thinks a client checks CAA when validating a certificate.
  • Says CAA invalidates certificates that were already issued.
  • Believes a child domain inherits and merges parent permissions.
  • Treats CAA as cryptographically enforced rather than policy-bound.
  • Assumes issue also governs wildcard requests when issuewild exists.
  • Says the iodef tag grants issuance to a reporting address.