Introducing CAA records
Today we are happy to introduce a new record type to all DNSimple customers: the CAA record. CAA stands for Certification Authority Authorization, and is a record type used to indicate to Certificate Authorities if they should issue certificates for a domain.
A brief history
Historically, any Certificate Authority is allowed to issue SSL/TLS certificates for any domain. There is no specific rule that prevents, for example, the authority AlphaAuthority to issue a certificate for google.com.
Like any other internet entity, Certificate Authorities can be compromised. In fact, there are multiple past reports of security breaches affecting CAs that resulted in misissued certificates. Probably the most well-known story is the one about DigiNotar, that eventually caused their revocation from all the root programs, and the bankruptcy of the company. Another more recent example is from 2015, when Google detected the unauthorized issuance of some certificates for the hostname google.com.
In January 2013, to reduce the likelyhood of misissued certificate from unauthorized CAs, Rob Stradling from Comodo proposed the Certification Authority Authorization (CAA) DNS Resource Record and formalized it as RFC 6844. (Don't know what an RFC is? Start with the wikipedia article about RFCs to find out more).
The CAA record lets domain owners expose preferences to the outside world. CAA records not only define a way to specify which Certificate Authorities are allowed to issue certificates for a domain, but also provide ways to report cases where the Certificate Authority is asked to issue a certificate but not authorized by the CAA record.
The CAA is not the only possible alternative to protect a domain from misissuance. Certificate and Public Key pinning is a possible alternative that delegates the validation effort to the client (e.g. the browser). CT logs are another resource that domain owners can monitor to determine what certificates are issued for a domain. Each of these three options has strengths and weaknesses, but that is for a future post.
In 2014 the CA/Browser forum (that effectively determines the rules for certificate issuance) obtained to require Certificate Authorities to disclose their CAA support, and the forum members are in discussions about requiring mandatory CAA support by Certificate Authorities at some point in the future.
So what does this mean for you?
If you secure your domains with SSL certificates (and you should given that some browser vendors will begin labeling non-HTTPS connections as insecure soon), then CAA records are a useful way to ensure that only the Certificate Authorities you use are allowed to issue an SSL certificate for your domain. With the CAA record, you can decide if the Certificate Authority is allowed to issue wildcard, non-wildcard, or both types of certificates. You can also indicate that Certificate Authorities send an email or call an HTTP or HTTPS URL whenever someone attempts to issue a certificate that is not allowed by that Certificate Authority.
Using CAA records
You can get started using CAA records today by navigating to a domain's record editor, and selecting the CAA record type from the "Add a Record" drop down.
You can test to see if a CAA record is present on a host name using
dig. For example, here is the
dig command to check the google.com domain:
dig google.com type257
And here are the results:
; <<>> DiG 9.11.0-P1 <<>> google.com type257 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7810 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;google.com. IN CAA ;; ANSWER SECTION: google.com. 86399 IN CAA 0 issue "symantec.com" ;; Query time: 249 msec ;; SERVER: 188.8.131.52#53(184.108.40.206) ;; WHEN: Mon Dec 26 10:59:13 CET 2016 ;; MSG SIZE rcvd: 70
So get started adding CAA records to your domains now, and get ahead of the curve in protecting your domains with SSL certificates from only the Certificate Authorities you trust and use.
I break things so Simone continues to have plenty to do. I occasionally have useful ideas, like building a domain and DNS provider that doesn't suck.
We think domain management should be easy.
That's why we continue building DNSimple.
How We Work as a Remote Team
Inspired by a recent blog post from Travis CI, I'd like to share details about how DNSimple team members work together without offices.
The Top DNS Servers And What They Offer
There are a lot of DNS Servers out there. We're looking at some of the top ones here and comparing their features and why some are chosen