RFC 8659

DNS Certification Authority Authorization (CAA) Resource Record

📅 published November 2019, from ietf

DNS Certification Authority Authorization (CAA) Resource Record 🎀

okay bestie, this is RFC 8659 🦋 It's a Standards Track doc (the real deal, IETF-approved), published in November 2019, with ISSN 2070-1721. It was written by P. Hallam-Baker (Venture Cryptography), R. Stradling (Sectigo), and J. Hoffman-Andrews (Let's Encrypt) ✨ It obsoletes RFC 6844, so 6844 is retired and this one replaces it 💅

Abstract

the CAA DNS record lets a domain name holder say which Certification Authorities (CAs) are allowed to issue certificates for that name 🌸 public CAs can use CAA records as an extra safety check, so there's less risk of a certificate getting issued by mistake 🫶 this doc defines the CAA record's syntax and the rules CAs follow when they process it 💖

this document obsoletes RFC 6844.

Status of This Memo

this is an Internet Standards Track document 🔥

it comes from the Internet Engineering Task Force (IETF) and reflects the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). more info on Internet Standards is in Section 2 of RFC 7841 📚

for the current status, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc8659.

copyright (c) 2019 IETF Trust and the people listed as the document authors 🌈 all rights reserved.

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. please read those carefully, because they spell out your rights and restrictions for this document 🙈 any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes.

Table of Contents

   1.  Introduction
   2.  Definitions
     2.1.  Requirements Language
     2.2.  Defined Terms
   3.  Relevant Resource Record Set
   4.  Mechanism
     4.1.  Syntax
       4.1.1.  Canonical Presentation Format
     4.2.  CAA issue Property
     4.3.  CAA issuewild Property
     4.4.  CAA iodef Property
     4.5.  Critical Flag
   5.  Security Considerations
     5.1.  Use of DNS Security
     5.2.  Non-compliance by Certification Authority
     5.3.  Mis-Issue by Authorized Certification Authority
     5.4.  Suppression or Spoofing of CAA Records
     5.5.  Denial of Service
     5.6.  Abuse of the Critical Flag
   6.  Deployment Considerations
     6.1.  Blocked Queries or Responses
     6.2.  Rejected Queries and Malformed Responses
     6.3.  Delegation to Private Nameservers
     6.4.  Bogus DNSSEC Responses
   7.  Differences from RFC 6844
   8.  IANA Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

the CAA DNS record lets a domain name holder pick out the Certification Authorities (CAs) that are allowed to issue certificates for that domain name 💅 when CAA records get published, a public CA gets extra controls to cut the risk of an accidental certificate mis-issue 🫶

okay so, the TLSA record from DNS-Based Authentication of Named Entities (DANE) [RFC6698] is kind of a cousin 👯 CAA records are also part of a mechanism for checking PKIX [RFC6698] certificate data. the difference is that CAA records set an authorization control that a CA has to do before it issues a certificate, while TLSA records set a verification control that a Relying Party does after the certificate exists 🦋

a conformant CAA record is a necessary, but not sufficient, condition for issuing a certificate. so it's required-ish, but not the whole story 💀

the criteria for putting embedded trust anchor certificates into applications are out of scope for this doc 🌸 usually those criteria ask the CA to publish a Certification Practices Statement (CPS) explaining how the Certificate Policy (CP) requirements get met. it's also super common for a CA to hire an independent third-party auditor to write an annual audit statement on how it's doing against its CPS 🧚

a set of CAA records only describes current grants of authority to issue certificates for the matching DNS domain name ⏳ certificates last for a period of time, so a certificate that doesn't match the CAA records published today might have matched the CAA records that were up when it got issued. ngl that's a very real timing thing 🙈

Relying Parties MUST NOT use CAA records as part of certificate validation. that's a hard no 🚫

CAA records MAY be used by Certificate Evaluators as a possible sign of a security policy violation. when they do, that use SHOULD take into account that the published CAA records may have changed between the time a certificate was issued and the time the Certificate Evaluator saw it 🔍

2. Definitions 📖

2.1. Requirements Language

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀

2.2. Defined Terms

these are the terms the doc uses 🍓

  • Certificate: an X.509 Certificate, as specified in [RFC5280].
  • Certificate Evaluator: a party other than a Relying Party that checks how trustworthy the certificates issued by Certification Authorities are.
  • Certification Authority (CA): an Issuer that issues certificates according to a specified Certificate Policy.
  • Certificate Policy (CP): spells out the criteria a CA commits to meeting when it issues certificates. See [RFC3647].
  • Certification Practices Statement (CPS): spells out how the criteria of the CP get met. Most of the time it's the document the CA's operations get audited against. See [RFC3647].
  • Domain Name: the label given to a node in the Domain Name System.
  • Domain Name System (DNS): the Internet naming system specified in [RFC1034] and [RFC1035].
  • DNS Security (DNSSEC): extensions to the DNS that provide authentication services, as specified in [RFC4033], [RFC4034], [RFC4035], [RFC5155], and any revisions to these specifications.
  • Fully Qualified Domain Name (FQDN): a domain name that includes the labels of all superior nodes in the DNS.
  • Issuer: an entity that issues certificates. See [RFC5280].
  • Property: the tag-value portion of a CAA Resource Record.
  • Property Tag: the tag portion of a CAA Resource Record.
  • Property Value: the value portion of a CAA Resource Record.
  • Relevant Resource Record Set (Relevant RRset): a set of CAA Resource Records that comes out of applying the algorithm in Section 3 to a specific FQDN or Wildcard Domain Name.
  • Relying Party: a party that uses an application whose operation depends on a certificate to make a security decision. See [RFC5280].
  • Resource Record (RR): a particular entry in the DNS, including the owner name, class, type, time to live, and data, as defined in [RFC1034] and [RFC2181].
  • Resource Record Set (RRset): a set of RRs with a particular owner name, class, and type. The time to live on all RRs within an RRset is always the same, but the data can differ among the RRs in the RRset.
  • Wildcard Domain Name: a domain name made up of a single asterisk character, followed by a single "full stop" character (*.), followed by an FQDN.

3. Relevant Resource Record Set 🔍

this part is the heart of it, bestie 🫶

before issuing a certificate, a compliant CA MUST check for a published Relevant RRset. if one exists, a CA MUST NOT issue a certificate unless it decides that either (1) the certificate request matches the applicable CAA RRset, or (2) an exception in the relevant CP or CPS applies. if the Relevant RRset for an FQDN or Wildcard Domain Name has no Property Tags that restrict issuance (like if it only has iodef Property Tags, or only Property Tags the CA doesn't recognize), then CAA doesn't restrict issuance at all 🌈

a certificate request MAY name more than one FQDN, and MAY name Wildcard Domain Names too. Issuers MUST verify authorization for all the FQDNs and Wildcard Domain Names in the request 💅

the search for a CAA RRset climbs the DNS name tree from the specified label up toward the DNS root, stopping before the root "." itself, until it finds a CAA RRset 🧗

given a request for a specific FQDN X, or a request for a Wildcard Domain Name *.X, the Relevant RRset RelevantCAASet(X) gets figured out like this (in pseudocode):

   Let CAA(X) be the RRset returned by performing a CAA record query
   for the FQDN X, according to the lookup algorithm specified in
   Section 4.3.2 of [RFC1034] (in particular, chasing aliases).  Let
   Parent(X) be the FQDN produced by removing the leftmost label of
   X.

   RelevantCAASet(domain):
     while domain is not ".":
       if CAA(domain) is not Empty:
         return CAA(domain)
       domain = Parent(domain)
     return Empty

for example, here's how CAA processing goes for the FQDN "X.Y.Z" when there are no CAA records at any level of the tree. RelevantCAASet would take these steps:

   CAA("X.Y.Z.") = Empty; domain = Parent("X.Y.Z.") = "Y.Z."
   CAA("Y.Z.")   = Empty; domain = Parent("Y.Z.")   = "Z."
   CAA("Z.")     = Empty; domain = Parent("Z.")     = "."
   return Empty

and here's the early exit: processing CAA for the FQDN "A.B.C", where there's a CAA record "issue example.com" at "B.C", stops as soon as it finds that record ✨

   CAA("A.B.C.") = Empty; domain = Parent("A.B.C.") = "B.C."
   CAA("B.C.")   = "issue example.com"
   return "issue example.com"

and that's where part 1 wraps up, bestie!! 🌸 the next section is Section 4. Mechanism 🧚

4. Mechanism ✨

4.1. Syntax 💖

okay so every CAA RR holds exactly one Property, and a Property is just a tag-value pair 🎀 An FQDN MAY have multiple CAA RRs attached to it, and the same Property Tag MAY show up more than once across those RRs ✨

The RDATA section of a CAA RR contains one Property, laid out like this 👑

+0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-|
| Flags          | Tag Length = n |
+----------------|----------------+...+---------------+
| Tag char 0     | Tag char 1     |...| Tag char n-1  |
+----------------|----------------+...+---------------+
+----------------|----------------+.....+----------------+
| Value byte 0   | Value byte 1   |.....| Value byte m-1 |
+----------------|----------------+.....+----------------+

n is the length you put in the Tag Length field, and m is how many octets are left over for the Value field. They're connected by m = d - n - 2, where d is the length of the RDATA section 🧮

Here's the breakdown of each field 💅

Flags: one octet with one field in it:

  • Bit 0, Issuer Critical Flag: if it's set to "1", the Property is critical. A CA MUST NOT issue certificates for any FQDN if the Relevant RRset for that FQDN contains a CAA critical Property for an unknown or unsupported Property Tag.

Quick bit-order tea ☕ According to the conventions in [RFC1035], bit 0 is the Most Significant Bit and bit 7 is the Least Significant Bit. So a Flags value of 1 means bit 7 is set, and a value of 128 means bit 0 is set.

Every other bit position is reserved for future use 🔮

For future-proofing, DNS records that follow this version of the CAA spec MUST clear (set to "0") all reserved flag bits. Applications that interpret CAA records MUST ignore the value of all reserved flag bits 🫶

Tag Length: a single octet holding an unsigned integer, which is the tag length in octets. The tag length MUST be at least 1.

Tag: the Property identifier, which is a sequence of ASCII characters.

Tags MAY contain the ASCII characters "a" through "z", "A" through "Z", and the numbers 0 through 9. Tags MUST NOT contain any other characters. Tag matching is case insensitive 🌈

Tags submitted for registration with IANA MUST NOT contain any characters other than the (lowercase) ASCII characters "a" through "z" and the numbers 0 through 9 📝

Value: a sequence of octets representing the Property Value. Property Values are encoded as binary values and MAY employ sub-formats 🦋

The length of the Value field is implied: it's just whatever is left of the enclosing RDATA section 🧚

4.1.1. Canonical Presentation Format

The canonical presentation format of a CAA record looks like this:

CAA <flags> <tag> <value>

Where:

  • Flags: an unsigned integer between 0 and 255.
  • Tag: a non-zero-length sequence of lowercase ASCII letters and numbers.
  • Value: the Value field, written either (1) as a contiguous run of characters with no interior spaces, or (2) as a quoted string. Check out the <character-string> format in [RFC1035], Section 5.1, but note that the Value field has no length byte and isn't limited to 255 characters 🍓

4.2. CAA issue Property 🔥

If the issue Property Tag is present in the Relevant RRset for an FQDN, it's basically a request that Issuers do two things 👑

  1. Perform CAA issue restriction processing for the FQDN, and
  2. Grant authorization to issue certificates containing that FQDN to the holder of the issuer-domain-name, or to a party acting under the explicit authority of the holder of the issuer-domain-name.

The CAA issue Property Value has its own sub-syntax, specified in ABNF as per [RFC5234] 🧁

issue-value = *WSP [issuer-domain-name *WSP]
   [";" *WSP [parameters *WSP]]

issuer-domain-name = label *("." label)
label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))

parameters = (parameter *WSP ";" *WSP parameters) / parameter
parameter = tag *WSP "=" *WSP value
tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))
value = *(%x21-3A / %x3C-7E)

For consistency with the rest of DNS administration, FQDN values are written in letter-digit-hyphen Label (LDH-Label) form 🌸

Here's an RRset that says no certificates can be issued for certs.example.com by any Issuer other than ca1.example.net or ca2.example.org 🙈

certs.example.com         CAA 0 issue "ca1.example.net"
certs.example.com         CAA 0 issue "ca2.example.org"

Since having an issue Property Tag in the Relevant RRset for an FQDN restricts issuance, FQDN owners can use an issue Property Tag with no issuer-domain-name to say "no issuance, period" 🛑

For example, this RRset means no certificates can be issued for nocerts.example.com by any Issuer 💀

nocerts.example.com       CAA 0 issue ";"

An issue Property Tag whose issue-value doesn't match the ABNF grammar MUST be treated the same as one specifying an empty issuer-domain-name. For example, this malformed CAA RRset forbids issuance 😭

malformed.example.com     CAA 0 issue "%%%%%"

CAA authorizations are additive, so specifying both an empty issuer-domain-name and a non-empty issuer-domain-name gives you the exact same result as specifying just the non-empty one ✨

An Issuer MAY choose to specify parameters that further constrain how it issues certificates. For example, it could require that certificates go through specific validation policies, get billed to certain accounts, or be issued under specific trust anchors 🧚

Say ca1.example.net asked its customer account.example.com to put their account number "230123" into each of their CAA records using the (CA-defined) "account" parameter. It would look like this 💖

account.example.com   CAA 0 issue "ca1.example.net; account=230123"

The semantics of parameters for the issue Property Tag are determined by the Issuer alone 🫶

4.3. CAA issuewild Property 🦋

The issuewild Property Tag has the same syntax and semantics as the issue Property Tag, with one big difference: it only grants authorization to issue certificates that specify a Wildcard Domain Name. Also, each issuewild Property takes precedence over each issue Property when it's specified. The specifics go like this 🎀

Each issuewild Property MUST be ignored when processing a request for an FQDN that is not a Wildcard Domain Name.

If at least one issuewild Property is specified in the Relevant RRset for a Wildcard Domain Name, each issue Property MUST be ignored when processing a request for that Wildcard Domain Name.

Here's an example 👀 This RRset says that only ca1.example.net can issue certificates for "wild.example.com" or "sub.wild.example.com", and that only ca2.example.org can issue certificates for "*.wild.example.com" or "*.sub.wild.example.com". Note that this assumes there are no CAA RRs for sub.wild.example.com 🌈

wild.example.com          CAA 0 issue "ca1.example.net"
wild.example.com          CAA 0 issuewild "ca2.example.org"

Next up, this RRset says that only ca1.example.net can issue certificates for "wild2.example.com", "*.wild2.example.com", or "*.sub.wild2.example.com" 🧁

wild2.example.com         CAA 0 issue "ca1.example.net"

This one says that only ca2.example.org can issue certificates for "*.wild3.example.com" or "*.sub.wild3.example.com". It doesn't let any Issuer issue for "wild3.example.com" or "sub.wild3.example.com", though 🙅

wild3.example.com         CAA 0 issuewild "ca2.example.org"
wild3.example.com         CAA 0 issue ";"

And finally, this RRset says that only ca2.example.org can issue certificates for "*.wild3.example.com" or "*.sub.wild3.example.com". It does let any Issuer issue for "wild3.example.com" or "sub.wild3.example.com" 💅

wild3.example.com         CAA 0 issuewild "ca2.example.org"

4.4. CAA iodef Property 🚨

The iodef Property specifies a way to report certificate issue requests, or cases of certificate issuance, for domains where the Property shows up in the Relevant RRset. This applies when those requests or issuances break the security policy of the Issuer or of the FQDN holder 😤

The Incident Object Description Exchange Format (IODEF) [RFC7970] is what gets used to present the incident report in a machine-readable form 🤖

The iodef Property Tag takes a URL as its Property Value, and the URL's scheme decides how the report gets sent 📬

  • mailto: means the IODEF report is sent as a MIME email attachment, in an SMTP email submitted to the mail address specified. The mail message sent SHOULD contain a brief text message to alert the recipient to what the attachment is about 💌
  • http or https: means the IODEF report is submitted as a web service request to the HTTP address specified, using the protocol described in [RFC6546] 🌐

These are the only supported URL schemes 🙌

This RRset says reports may be made by email with the IODEF data attached, through a web service [RFC6546], or both 🦋

report.example.com         CAA 0 issue "ca1.example.net"
report.example.com         CAA 0 iodef "mailto:security@example.com"
report.example.com         CAA 0 iodef "https://iodef.example.com/"

4.5. Critical Flag 🚩

The critical flag exists so future versions of CAA can add new semantics that MUST be understood for the record to be processed correctly. It also stops conforming CAs that don't recognize those new semantics from issuing certificates for the affected FQDNs 🛡️

In the example below, the Property with the Property Tag "tbs" is flagged as critical. Neither the ca1.example.net CA nor any other Issuer is authorized to issue for "new.example.com" (or any other domains where this is the Relevant RRset) unless that Issuer has implemented the processing rules for the "tbs" Property Tag 🫣

new.example.com       CAA 0 issue "ca1.example.net"
new.example.com       CAA 128 tbs "Unknown"

5. Security Considerations 🔐

CAA records assert a security policy that the holder of an FQDN wants Issuers to observe. So how well CAA records work as an access control mechanism depends entirely on Issuers actually following the CAA constraints. No cap, this part is serious 😤

The goal of the CAA record properties in this document is to reduce the risk of certificate mis-issue, not to avoid relying on a certificate that has already been mis-issued. DANE [RFC6698] describes a mechanism for avoiding reliance on mis-issued certificates, so go check that one out too 💜

5.1. Use of DNS Security 🌸

Using DNSSEC to authenticate CAA RRs is strongly RECOMMENDED, but it isn't required. An Issuer MUST NOT issue certificates if doing so would conflict with the Relevant RRset, whether or not the corresponding DNS records are signed. Non-negotiable, bestie 🙅‍♀️

DNSSEC provides a proof of non-existence for both DNS FQDNs and the RRsets within FQDNs. That means DNSSEC verification lets an Issuer figure out whether a CAA record query answer (1) is empty because the RRset is actually empty, or (2) is non-empty but the response has been suppressed 🕵️‍♀️

Using DNSSEC also lets an Issuer acquire and archive proof that they were authorized to issue certificates for the FQDN. Checking those archives may be an audit requirement, to verify CAA record-processing compliance. Publishing those archives may be a transparency requirement for the same purpose 📚✨

5.2. Non-compliance by Certification Authority ✨

okay so CAA records are lowkey the cheapest insurance a CA can get 💅 Doing the CAA checks costs basically nothing, but a mis-issue event can cost a CA its embedded trust anchor, and that's a disaster. Not me doing the math and going "yeah, just check the records" 🫶

5.3. Mis-Issue by Authorized Certification Authority 🎀

bestie, CAA records do NOT stop an authorized CA from mis-issuing 😭 I mean an authorized CA, the kind that CAA records have already said is allowed to issue for that FQDN. Those records are a gatekeeper, not a babysitter.

So FQDN holders SHOULD check that the CAs they've authorized have proper controls in place, making sure certificates only go to authorized people inside their own organization. It's giving responsibility 🧚

Honestly, those controls are best worked out by the FQDN holder and the authorized CA(s) directly, so they're out of scope for this document 💜

5.4. Suppression or Spoofing of CAA Records 🦋

ngl this one is scary 💀 If an attacker can suppress a CAA record, or sneak in a bogus one, they could trick an Issuer that isn't authorized into handing them a certificate for the FQDN. Not okay!!

Where it's possible, Issuers SHOULD do DNSSEC validation so they can spot missing or modified CAA RRsets 🔥

If DNSSEC isn't deployed for the FQDN, an Issuer SHOULD still try to lower the risk with solid DNS security controls. For example, every part of the DNS lookup SHOULD be done against the authoritative nameserver 🌸 Data that third parties have cached MUST NOT be the only source of DNS CAA info, but it MAY be used to back up extra anti-spoofing or anti-suppression controls. Think of it as a side-quest, not the main quest 🍓

Cached data is never enough on its own. Always check the authoritative source. 💅

5.5. Denial of Service 🌈

Okay so a malformed or malicious CAA RR could, in theory, enable a Denial-of-Service (DoS) attack 😬 That could happen if someone edits authoritative DNS records or spoofs in-flight DNS responses.

This specific threat doesn't really add much risk on top of just running an insecure DNS service, so it's not the scary part 🙈

An attacker could, in principle, try a DoS against an Issuer by requesting a certificate with a super long DNS name. But the DNS protocol already caps the maximum name length, and CAA processing doesn't make the need to handle DoS attacks any worse in a meaningful way ✨

5.6. Abuse of the Critical Flag 💀

This one is sneaky, bestie 🕵️‍♀️ A CA could use the critical flag to trick customers into publishing records that stop competing CAs from issuing certs, even though the customer actually wants multiple providers. That's giving villain era 😤 It could happen if customers build their CAA records from data the CA gave them instead of generating the records themselves.

In practice the effect would be pretty minimal 💅 Any competent competitor that suddenly can't issue because it doesn't support a critical Property should look into why and tell the customer what's up. The customer will then find out they got played 👑

6. Deployment Considerations 🍓

A CA implementing CAA might start getting errors when it looks up CAA records 😭 So here are some common causes, so CAs can give their subscribers guidance on fixing the underlying problems. You're welcome, besties 🫶

6.1. Blocked Queries or Responses 🛡️

Some middleboxes (anti-DDoS appliances, in particular) may be set up to drop DNS packets of unknown types. They might also start dropping those packets when they think they're under attack 🙈 This usually shows up as a timed-out DNS query, or as a SERVFAIL at a local recursive resolver.

6.2. Rejected Queries and Malformed Responses 🎀

Some authoritative nameservers respond with REJECTED or NOTIMP when someone asks about an RR type they don't recognize 🫠 At least one authoritative resolver produces a malformed response (with the QR (Query/Response) bit set to "0") when it gets queried for unknown RR types.

Per [RFC1034], the correct response RCODE for unknown RR types is 0 ("No error condition") 💖 So that's the behavior to aim for!

6.3. Delegation to Private Nameservers 🔒

Some FQDN administrators make a subdomain unresolvable on the public Internet by delegating it to a nameserver with a private IP address 🙃 When a CA processes CAA records for those subdomains, its recursive resolver will return SERVFAIL. The CA MAY read that as a reason to prevent issuance.

If an FQDN administrator wants to issue certificates for private FQDNs, they SHOULD use split-horizon DNS with a publicly available nameserver. That way CAs can get a valid, empty CAA response for those FQDNs 🧚

6.4. Bogus DNSSEC Responses 🔐

Okay, queries for CAA RRs are different from most DNS RR types, and this is the tea ☕ A signed, empty response to a CAA query is meaningfully different from a bogus response. A signed, empty response tells you there's definitely no CAA policy set at a given label. A bogus response might mean the zone is misconfigured, or that an attacker is messing with the records 👀

DNSSEC implementations can have bugs with signatures on empty responses and nobody notices, because for more common RR types like A and AAAA, an end user doesn't care whether a response is empty or bogus. Either way the site is unavailable 🥲

At least two authoritative resolvers that implement live signing had bugs when returning empty RRsets for DNSSEC-signed zones, when mixed-case queries were involved. Mixed-case queries, also known as DNS 0x20, are used by some recursive resolvers to boost resilience against DNS poisoning attacks 🦋 DNSSEC-signing authoritative resolvers are expected to copy the same capitalization from the query into their ANSWER section, but they also need to sign the response as if they had used all lowercase. PowerDNS versions prior to 4.0.4 had this bug 💀

7. Differences from RFC 6844 💜

This document obsoletes [RFC6844] 🌸 The biggest change is to the "Certification Authority Processing" section, which is now called "Relevant Resource Record Set" (Section 3), as explained below.

[RFC6844] specified an algorithm that did DNS tree-climbing not only on the FQDN being processed, but also on all CNAMEs and DNAMEs encountered along the way. That made the algorithm super inefficient for FQDNs with lots of CNAMEs. It also made it hard for hosting providers to set CAA policies on their own FQDNs without accidentally setting potentially unwanted CAA policies on their customers' FQDNs 😤 This document swaps in a simplified algorithm that only does tree-climbing on the FQDN being processed, and it leaves CNAME and DNAME processing up to the CA's recursive resolver ✨

This document also has a "Deployment Considerations" section (Section 6) with experience from real-world CAA enforcement among CAs in the WebPKI 🌈

It clarifies the ABNF grammar for the issue and issuewild tags and fixes some inconsistencies in the document text. Most importantly, it specifies that parameters are separated with semicolons. It also allows hyphens in Property Tags 🎀

It clarifies how to process a CAA RRset that isn't empty but doesn't contain any issue or issuewild tags 🧠

This document removes the section titled "The CAA RR Type" and merges it into "Mechanism" (Section 4), because the definitions were mostly duplicates 🫶 It moves the "Use of DNS Security" section into Security Considerations (Section 5), and it renames "Certification Authority Processing" to "Relevant Resource Record Set" (Section 3). It also puts more emphasis on that term, so it's clearer which domains are affected by a given RRset 💖

8. IANA Considerations 🦋

IANA has added this document as a reference for the "Certification Authority Restriction Flags" and "Certification Authority Restriction Properties" registries. It also updated the references to [RFC6844] within those registries so they point to this document instead ✨ IANA additionally updated the CAA TYPE in the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry with a reference to this document 🌷

9. References 📚

9. References 📚

9.1. Normative References 💖

Okay, these are the ones you HAVE to read to get the whole picture, bestie 🫶 Each one is listed with its title, status, and DOI so you can find it fast:

9.2. Informative References 🦋

These one's more of a "good to know" situation, no cap 🌸

Acknowledgements ✨

The authors wanted to shout out everyone who helped design and document this work item, and honestly they deserve all the flowers 💐 Corey Bonnell, Chris Evans, Stephen Farrell, Jeff Hodges, Paul Hoffman, Tim Hollebeek, Stephen Kent, Adam Langley, Ben Laurie, James Manger, Chris Palmer, Scott Schmit, Sean Turner, and Ben Wilson. 🫶

Authors' Addresses 🎀

Phillip Hallam-Baker Venture Cryptography Email: phill@hallambaker.com

Rob Stradling Sectigo Ltd. Email: rob@sectigo.com

Jacob Hoffman-Andrews Let's Encrypt Email: jsha@letsencrypt.org

And that's the whole spec, bestie! 💅✨

📦 where this page comes from