Separate reporting, absence and lookup errors
06A reporting contact does not authorize an issuer. A valid empty DNS answer is different from a failed lookup.
A private nameserver delegation produces SERVFAIL in this example. This CA chooses to defer issuance, which §6.3 permits. The error has not been converted into a successful empty policy result.
Key idea: Treat CAA results as policy input, not an automatic certificate.
Terms
- CAA
- Certification Authority Authorization: DNS policy checked by a CA before it issues a certificate.
- CA
- Certification Authority: an issuer of certificates under a stated certificate policy.
- Relevant RRset
- The first nonempty CAA resource-record set found by the RFC’s lookup algorithm. A set can contain several properties.
- Property tag
- The case-insensitive name of a CAA property, such as issue, issuewild or iodef.
- Wildcard name
- A certificate name beginning with *., such as *.example.com. For CAA lookup, remove that leading *. first.
- CP / CPS
- Certificate Policy / Certification Practices Statement. Section 3 allows an exception specified in the relevant CP or CPS; the worked examples assume none applies.
Rules & examples
Treat CAA results as policy input, not an automatic certificate.
- iodef supplies a reporting URL for policy-violating certificate requests or issuances. Supported schemes are mailto, http and https, using the specified IODEF transport. Publishing a contact neither mandates a report for every request nor grants issuance authority (§4.4). All displayed URLs here are inert; no report is sent.
- An iodef-only Relevant RRset does not restrict issuance, but it still stops ancestor searching. A CA must satisfy its other issuance requirements; "CAA does not restrict" does not mean "certificate approved" (§§1,3).
- DNSSEC authentication of CAA is strongly RECOMMENDED, not required. A CA MUST NOT issue in conflict with the relevant set whether or not it is signed. Where possible, issuers SHOULD validate DNSSEC, and third-party cached data MUST NOT be their sole source of CAA information (§§5.1,5.4).
- A signed valid empty answer at one label allows continuing the parent search. Bogus DNSSEC or lookup errors are not the same as an empty answer (§6.4). The RFC describes timeouts, SERVFAIL and malformed replies; it does not define a universal issuance retry schedule (§6).
- For a subdomain delegated to a private nameserver, a CA can receive SERVFAIL and MAY interpret that as preventing issuance (§6.3). The final frame depicts that chosen deferral, not a universal MUST-abort rule for every DNS error.
Fictional names, inert records and simulated DNS answers. The examples assume no CP/CPS exception and no extra issuer-defined parameter constraint. Passing CAA does not satisfy the other checks needed to issue a certificate.
Sources
New to this? Start hereA quick picture + helpful background
Check the domain’s issuer list before signing
Imagine a certificate printer checking a domain’s published list of permitted signing organizations. That list is only one check before printing; it is not the later reader’s test of an existing certificate. This is an analogy for issuance policy, not a complete certificate system.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.