CAA Records: An Alternative to DANE for Protecting SSL/TLS Certificate Users

← Blog Home



I. Introduction

One of the oddities of the SSL/TLS certificate ecosystem is that there are many broadly-trusted Certificate Authorities (CAs), and EACH of those CAs (technically) has the ability to issue a trusted certificate for ANY domain.

Moreover, the mere fact that one CA may have already issued a certificate for a given domain DOESN’T prevent a second CA from also issuing a certificate for that SAME domain!

This sort of trusted-certificates-from-multiple-providers scenario can legitimately arise when a site changes from one CA to another.

However, wrong certs have been mis-issued by accident, and from time-to-time the bad guys have also figured out ways to get certificates for domains they don’t legitimately control. Certificate authorities go to great lengths to ensure that this rarely happens, but even just the possibility that this could potentially occur is still worrisome.

You’d really like to have the ability to say, ‘Hey, my domain ONLY obtains certificates from CA “Foo.” If you see a certificate for this domain from some OTHER provider, that CA is NOT one we use, so don’t trust it!’

There are now two main approaches, both DNS-based, that you can use to try to protect your domains from mis-issued certs: DANE and CAA.

Let’s consider DANE first.

II. DANE (“DNS-Based Authentication of Named Entities”)

DNSSEC was originally created as a way to prevent cache-poisoning and related attacks against the domain name system.

DNSSEC creates a cryptographically-signed trust hierarchy that flows from the root domain (.) down through top-level domains (such as .com), on through 2nd-level domains (such as to individual fully qualified domain names (such as When resolving a DNSSEC-signed domain name, the results that are received get checked to ensure that they cryptographically validate.

That DNSSEC trust hierarchy also creates an alternative trust hierarchy for SSL/TLS certificates: DANE.

DANE can be used both as potential alternative to traditional commercial CAs, OR as a way of confirming the commercial certificate authority/the commercial certificate that a site is using. See the usage modes as described here.

Unfortunately, using DANE means that a site needs to DNSSEC-sign their zone. DNSSEC deployment has seen limited uptake to-date. For example, in the ISOC report “State of DNSSEC Deployment 2016”, ISOC reports that only about 0.5 percent (1/2 of 1%) of all dot com zones are DNSSEC-signed.

The number of sites that are publishing TLSA records (needed to do DANE) is even smaller. We can check Farsight Security’s passive DNS database, DNSDB, for https TLSA records for the default https port (443/TCP) by saying:

$ -r _443._tcp.\*/TLSA -l 1000000 > _443._tcp.txt

Our output will be in “_443._tcp.txt”. We can clean up that file by deleting comment lines (lines containing the literal string “;;”) and blank lines by using vim (or some other preferred editor). Having done so, at the time this article was prepared, we’re left with just 304 TLSA records. That’s not very many.

If we reduce those records to just unique effective 2nd-level domains, we take the count of unique TLSA records down even further, to just 145 unique effective 2nd-level domains:

$ awk '{print $1}' < _443._tcp.txt | 2nd-level-dom | sort -u | wc -l

That’s REALLY not very many. A list of these domains is attached as Appendix I. [If there are domains that are publishing TLSA domains for 443/TCP that we’ve missed, we’d love to hear about them.]

The other factor limiting the impact of DANE is “end-user visibility.” Even if sites publish TLSA records, without a 3rd-party browser extension, most browsers won’t actually check and validate a domain’s DANE status. This means that even if a domain is secured with DANE, without a validating browser extension installed, you’d never know it. More significantly, if a domain is secured with DANE and you bump into someone’s who’s “trying something fishy,” without a browser extension installed you’d not know THAT, either! Clearly, browser extensions providing end-user visibility play an important role in making DANE operationally meaningful. If you’d like to add DANE validation support to the browser you use, see Mr. Shumon Huque’s excellent article. It does a very nice job of explaining how to go about adding a DANE validation extension to Firefox.

III. The Alternative to DANE: Certification Authority Authorization (CAA) Resource Records

Since DANE has not been very broadly adopted as a way of “nailing down” the CA that a site actually uses, an alternative has been developed, the CAA record as defined in RFC6844.

Checking for CAA records by broadly trusted CAs has been adopted as mandatory, effective 8 September 2017, per CAB Forum ballot. This means that if a CAA record exists for a domain, any broadly trusted CA approached to issue a certificate for that domain must check and honor the constraints imposed by a CAA record, if defined. If no CAA record exists, normal certificate issuance procedures will be followed.

We checked the June 2017 DNSDB Export data (271,530,170,657 octets) to see if we could find any CAA records. We did that with the commands:

$ dnstable_dump -r /export/dnstable/mtbl/dns.201706.M.mtbl | rg -i " CAA " > caa.txt

The “ripgrep” tool (rg) used in the above pipeline is available here.

We condensed that output to just the effective 2nd-level domains by saying:

$ awk '{print $1}' < caa.txt | 2nd-level-dom | sort -u > caa-doms-only.txt

There were 418 domains which had one or more CAA records defined. A copy of those domains can be found in Appendix II. Again, this is not a lot of domains right now, but we expect that this number will grow over time.

We took those domains and performed a “dig” (limited to just CAA records) for each such domain.

Looking at just the “issue” records, the nine most popular CAs were:


No other CA had half a dozen or more “issue” CAA records during June 2017.

Looking at just the “issuewild” records, the only CAs with half a dozen or more “issuewild” records were:

24 ""
9 ""
7 ""

Looking at just the iodef records, there was no email (or web) entry associated with 6 or more CAA records.

We also checked the flag value in the CAA records. Normally the flag will either be set to 0 (not critical) or 128 (critical), but we also saw a few 1s and 5s:

      Count    Value
        416    0
         37    128
         8     1
         2     5

IV. What This All Means and More Information

Neither DANE nor CAA is seeing much adoption and use so far, but we’re just getting started. Hopefully DANE and/or CAA records will soon be a part of everyone’s domain configuration!

For more information about obtaining access to DNSDB or any Farsight product, please see our services page.

Appendix I. Effective 2nd-Level-Domains With TLSA records Known to DNSDB

Appendix II. Effective 2nd-Level Domains With One or More CAA Records

Joe St Sauver, Ph.D. is a Scientist with Farsight Security, Inc.

← Blog Home

Protect against cybercriminal activity in real-time.

Request demo

Email: Phone: +1-650-489-7919