DNS CAA record

How it works

CAA selection has two stages: find the relevant record set, then interpret its properties. The full lookup procedure in RFC 8659 §3 includes alias handling and wildcard-name preparation. This model deliberately covers only names without aliases.

For ordinary www.example.test, the inherited fixture checks www.example.test and then example.test, where it finds the relevant set. If the child publishes its own relevant set, that set takes priority rather than being merged with the parent's. For *.example.test, the wildcard prefix is removed before owner selection, so the lookup starts at example.test.

Within the selected set, ordinary requests use issue and ignore issuewild. For wildcard requests, issuewild takes precedence when present; otherwise issue applies. These property rules are described in RFC 8659 §4.3.

The critical order is RRset discovery before property evaluation. A more specific child RRset takes precedence over inherited policy; you do not simply combine all ancestors into a single allowlist. An alias can change the full standard search path, so this alias-free fixture deliberately refuses to claim a result for that case. Once an applicable RRset is found, issuewild controls wildcard requests when present, whereas ordinary certificates ignore that property.

A worked example

The inherited fixture gives example.test two authorizations: issue names ca1.example.net, while issuewild names ca2.example.net. Starting from baseline, the ordinary www.example.test request asks for CA1 and uses issue, so CA1 is permitted by the fixture. The wildcard preset changes two inputs: the requested name becomes *.example.test and the requested CA becomes ca2.example.net. Owner selection starts at example.test after removing the wildcard prefix; issuewild applies and permits CA2. The record set stays unchanged. This is a complete preset comparison, not a single-input experiment: CA1 is absent from the wildcard issuer list.

For comparison, change only the requested certificate type while keeping the inherited RRset and CA1: the ordinary authorization from issue does not mean CA1 is authorized for a wildcard when the same RRset has an applicable issuewild naming CA2. This is a policy distinction, not a measurement of certificate issuance. The named wildcard preset changes both the name and requested CA, which is why its final permitted result cannot be attributed to the name change alone.

What changes the conclusion

An explicit empty issuer is not the same as missing policy. In the blocked fixture, the relevant record set contains an issue property that authorizes no issuer, so CA1 is not permitted by that fixture. By contrast, an issuewild-only set does not restrict an ordinary request through issuewild alone: ordinary requests ignore that property. Neither situation should be confused with a failed DNS lookup, which leaves the answer unknown.

In practice

Before live issuance, use read-only checks of the authoritative DNS records, any aliases, the relevant CAA record set and the current CA's issuer-specific requirements. No DNS-editing permission is needed to use this simulation, and it makes no live changes.

An issuance failure alone does not diagnose a CAA problem. A confirmed applicable restriction, an unavailable DNS answer and a different CA requirement are different possibilities that need different evidence. STOP using this model as a decision tool if the path involves an alias, lookup evidence is unavailable or the conclusion depends on CA-specific behavior. A successful synthetic retest is not proof that a real service now works.

Limits and unknowns

Read the result at its stated scope. “Permits by fixture” means the requested CA passes this modeled CAA criterion, not that issuance is guaranteed. “Not permitted by fixture” is a confirmed negative within the selected synthetic policy, not evidence that a live CA rejected a request.

Unavailable lookup evidence means unknown, not permission, denial or verified absence of records. Certificate revocation status is not evaluated at all; “not evaluated” does not mean “not revoked.” The simulation also provides no evidence about HTTPS certificate validity.

What to take away

Before concluding that CAA explains an issuance outcome, establish the exact requested name, ordinary/wildcard type, relevant DNS lookup result and issuer identity. A known nonmatching restriction and a failed or alias-unsupported lookup require different next steps. Even a model-permitted result is not proof of issuance or validity of a certificate in a browser.