Certification Authority Authorization – CAA Records

Q: Does Total Uptime support these new record types?

A: YES!

For domains/zones added to our platform on or after August 24, 2020, we natively support CAA records. Simply add the new record type to your zone using the blue button, as shown below.

Creating CAA records isn’t very complex, but for those who need a good tutorial, we recommend taking a look at this incredibly handy CAA Record Generator by SSLMate. While most certificate authorities will give you the exact details of the record to add, the SSLMate wizard will walk you through creating it from scratch.

For domains/zones added to our platform before August 24, 2020, we can upgrade your zone to support CAA records natively if you create a support case, or you can add the older version called a TYPE257 record today. So by converting your CAA record to RFC 3597 syntax, you can implement “CAA” records right now.

Background on CAA

In February 2017 the CA/Browser Forum voted to mandate Certification Authority Authorization (CAA) support and to enforce use of this validation method starting in September 2017. CAA lets the owner of a domain name authorize designated and specific Certification Authorities (CAs) to issue SSL certificates for their domain name. Even though CAA was specified in RFC 6844 back in 2013 by the IETF, it never really took off until early 2017 when it was voted on, as is typical with so many proposed DNS changes, improvements, record types etc.

Because many DNS record types are proposed and then never adopted, we at Total Uptime simply keep an eye on things, and if they are adopted we proceed to implement them. Generally there is more than enough time to roll out new changes, but with CAA everything started rolling very quickly, and with good reason.

Issuing SSL Certificates is often considered the weakest link in the PKI ecosystem since any CA can issue a certificate for any domain. CAA attempts to prevent that, and as such, organizations wishing to purchase SSL certificates will need to have this record in place come September when Certificate Authorities are required to start looking for them.

As mentioned above, we don’t support the exact CAA record just yet, but we do support the TYPE257 record which will work precisely the same way. So if you want to implement something now so you’re ready for the deadline, you can!

How to create your CAA / TYPE257 record

The easiest way to create a new record is to use this incredibly handy CAA Record Generator by SSLMate. Their tool truly takes the complexity out of it, especially when you need to convert it to RFC 3597 syntax. Simply enter your domain name (optional), choose the certificates and the code will be generated below.

Here’s an example I generated for Comodo Non-Wildcard only:

You’ll see that two records are generated. Issue “comodoca.com” which allows Comodo to issue non-wildcard certs, and issuewild “;” which indicates that all other Cas are not authorized to issue certificates.

To implement this in our UI, create a new TYPE257 record and add the first one as follows:

You’ll notice that only a few pieces of data are required from the syntax generated by the SSLMate tool.

The Host is most likely the @ symbol, if your CA is going to look at the root or apex of your domain. If they are looking at a sub domain, such as “secure.example.com” then you may need to enter “secure here instead”

The bytes is taken from the generated syntax which is directly following the \#

The Value is the long hexadecimal string to the far right.

If you compare what we’ve entered in the screen capture above to what was generated by the SSLMate tool, you’ll figure it out pretty quickly. And for our example above, after clicking Submit to save the record, we would create another one.

That’s about all there is too it!

For advanced DNS administrators, the tool named-rrchecker from BIND 9.11 can be used to convert a CAA-record into the RFC 3597 format useable for older DNS server:

$ echo “IN CAA 128 issue ‘letsencrypt.org’” | named-rrchecker -u

Which returns:

CLASS1 TYPE257 \# 24 80056973737565276C657473656…

Testing the results

Confirming whether the record was added successfully is pretty easy. After waiting a couple of minutes for the change to propagate our network, you can simply perform a dig against the CAA or TYPE257 record. Here is an example:


[root@centos ~]# dig @a1.uberns.com CAA example.com
;
; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.1 <<>> @a1.uberns.com CAA example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER< ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;example.com. IN CAA
;
;; ANSWER SECTION:
example.com. 3600 IN CAA 0 issuewild "\;"
example.com. 3600 IN CAA 0 issue "comodoca.com"
;
;; AUTHORITY SECTION:
example.com. 28800 IN NS a1.uberns.com.
example.com. 28800 IN NS b1.uberns.com.
;
;; Query time: 7 msec


So as you can see above in the ANSWER SECTION, the two CAA records are there, even though you created a TYPE257.

Lastly, if you need help, don’t hesitate to reach out to us. We’re here to help.