Summary

  • RFC 6844 let a domain name holder publish which certificate authorities could issue for that name. Its first lookup procedure could follow a CNAME or DNAME and then climb the alias target’s parent tree, so a hosting provider’s CAA policy could become part of a customer’s issuance search.
  • RFC 8659 kept ordinary DNS alias resolution but limited the separate parent-label climb to the FQDN being checked. The change drew a sharper line between a customer’s policy and a host’s own DNS hierarchy.

The certificate question follows a DNS answer

Imagine www.client.example as a CNAME for tenant.platform.example. The customer’s name resolves through a shared host’s namespace. Before issuing a certificate, a compliant CA has another question to answer: which CAA record set governs www.client.example?

That question sounds simple until the query crosses a boundary. The customer controls one domain tree; the hosting provider controls another. A resolver can follow an alias from one into the other in a fraction of a second. Should an issuer also search the provider’s parent labels for a policy that the customer never placed in its own zone?

CAA made that a protocol question. In January 2013, RFC 6844 defined the Certification Authority Authorization resource record, DNS type 257. A domain name holder could list one or more CAs authorized to issue for a domain. Before issuing, a compliant CA had to check the relevant CAA record set and refuse a request that did not fit it, except where an exception in the CA’s certificate policy or practices statement applied.

The record sat in DNS, where the domain holder already published the name’s other instructions. That gave the issuer a policy to check before it made a certificate. It also made the exact meaning of “relevant” depend on a search through DNS names.

2013: the search could follow two trees

RFC 6844’s processing rule did more than walk from a name to its parents. If a CAA query found no record at a label and that label had a CNAME or DNAME alias, the procedure could follow the alias and recursively search its target. If that search also found nothing, it climbed to the original label’s parent and continued.

The hypothetical names make the consequence visible. Suppose www.client.example points to tenant.platform.example, and the provider publishes CAA 0 issue "issuer.example" at platform.example. Under RFC 6844’s recursive rule, a search that reached the provider’s target could climb again to platform.example and find that policy. A record written in the host’s parent namespace could therefore enter the CA’s search for a customer name.

The rule was trying to find a governing CAA set, not to transfer ownership of a customer domain. But DNS resolution and policy inheritance were traveling together. A customer’s path could pass through the provider’s alias, then encounter the provider’s ancestors. For a shared hosting service, every customer alias could inherit a policy the host had placed higher in its own tree.

2019: keep the climb in the requested name’s tree

RFC 8659, published in November 2019, replaced RFC 6844 and rewrote the processing algorithm. The CA still queries CAA for the requested FQDN using ordinary DNS lookup behavior, including alias chasing. If that query returns no CAA set, the algorithm climbs the parent labels of the FQDN under evaluation. It does not separately climb the parent tree of every CNAME or DNAME target it encounters.

That distinction is narrow and consequential. An exact CAA record returned for an alias target can still be part of the DNS answer. What no longer follows is the second, independent climb through that target’s ancestors. A customer’s own parent policy can still cover its subdomains; a provider’s parent policy does not enter the customer’s search merely because a CNAME points into the provider’s namespace.

RFC 8659 gives the reason in its comparison with RFC 6844: climbing both the name tree and every alias tree was inefficient for names with many aliases and made it difficult for hosting providers to set policies on their own FQDNs without creating potentially unwanted policies for customers. The revision changed the question from “where can this chain lead, then what are all of those parents saying?” to “what is the relevant CAA set for this requested name, using DNS resolution, and what does its own parent tree say?”

Authorization is an issuer-side decision

CAA works at issuance time. It does not tell a browser whether a certificate already in hand should be trusted, and a DNS change does not revoke a certificate that was issued earlier. The standard says relying parties must not use current CAA records as part of certificate validation. A CAA set records current authority to issue; the time of issuance matters.

The record also does not make the DNS answer self-authenticating. RFC 8659 strongly recommends DNSSEC for CAA, while allowing the issuer to check unsigned records. If a query is blocked, a response is malformed, or an empty answer is mishandled, the CA has an operational problem before it has a policy answer. RFC 8659’s deployment section lists these failure modes because an access rule is only useful when the issuer can retrieve and interpret it.

CAA also has edges of its own. issue names issuers for ordinary certificate requests; issuewild governs wildcard requests when present. A blank issuer value can request that no CA issue for the name. These tags define the policy content. RFC 8659’s correction defines which name tree supplies that content.

That is the historical move: the first CAA standard made DNS a place for the domain holder to state who could issue; its successor refined the boundary between that holder’s tree and a service provider’s tree. The lookup still follows aliases to answer DNS. The policy search no longer treats every destination’s parents as part of the customer’s chain.

The example above is constructed from the RFC algorithms, not a reported incident. The RFCs establish the intended search rules; measuring how particular CAs implemented them would require issuer query and issuance-decision logs tied to names and timestamps.

Sources