Certificate Authority Authorization Records

Support for the CAA record was added to BIND with the 9.10.1B release, after Rick Andrews of Symantec approached us at an IETF meeting and asked why we didn’t have it already.  Rick is an expert and evangelist for the use of certificates, so we invited Rick to explain why people should use CAA records.


Certificate Authority Authorization (CAA, RFC 6844) is intended to reduce the risk of unintended SSL/TLS certificate mis-issuance, either by malicious actors or by honest mistake.  The goal is to allow a DNS domain name holder to specify the certificate authority or authorities that the owner has authorized to issue SSL/TLS certificates for that domain.

For example, if you own example.com, and wish to express your preference that certificates for that domain should only be issued by Primary CA, Inc., you would create a record in DNS indicating such. If a malicious actor, or an employee who is not aware of your preference, engages a different CA, Secondary CA, Inc. to purchase a certificate, Secondary CA might first check in DNS. If they see that you have a CAA record that does not specify Secondary CA as a preferred certificate authority, Secondary CA could alert you of that. You could then choose to deny the certificate purchase, or change or add to DNS your preference to allow Secondary CA to issue certificates for your domain.

For this reason, we recommend use of the CAA record.

Rick Andrews, Senior Technical Director for Trust Services, Symantec.com



  1. Dave August 29, 2014 Reply

    How does this differ from DANE?

  2. Author
    Vicky Risk August 29, 2014 Reply

    Well, I can quote from the IETF RFC:
    “Like the TLSA record defined in DNS-Based Authentication of Named
    Entities (DANE) [RFC6698], CAA records are used as a part of a
    mechanism for checking PKIX certificate data. The distinction
    between the two specifications is that CAA records specify an
    authorization control to be performed by a certificate issuer before
    issue of a certificate and TLSA records specify a verification
    control to be performed by a relying party after the certificate is

    I think the upshot is, DANE is used for verification, and the CAA record really does not have a role in verification. It is more informational.

  3. Aannemer Amsterdam February 9, 2015 Reply

    Dane is diffrent…!

  4. Alice Wonder April 22, 2015 Reply

    It seems rather useless to me. The only benefit is to help Certificate Authorities avoid issuing fraudulent signed certs, it does nothing to help a client validate a certificate.

    Certificate Authorities should only trust the data in this RR type if it is DNSSEC signed, but if it is DNSSEC signed then DNSSEC is already a much better MITM defense that does directly benefit clients.

    For EV and OV certs the CAs should already be doing fairly extensive verification to avoid issuing fraudulent certs. For DV certs there may be some value, but rather than checking for the presence of an optional RR type that can only be trusted when DNSSEC signed, it would be better for the CA to ask that a text record with a code be put into the zone. That is something that a fraudulent person couldn’t do unless they had control over the zone file (which would make this RR type useless) and would be a much more secure method of doing domain validation than the current e-mail method, and it would completely eliminate any perceived value of this RR type.

    It seems to me this RR type will probably rarely be used by webmasters and rarely checked by CAs so it doesn’t really address the problem. A fraudster who has access to an e-mail address will just shop around until he or she finds a CA that doesn’t check. Which right now is most of them.

Leave a reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Protected with IP Blacklist CloudIP Blacklist Cloud

Last modified: August 29, 2014 at 3:44 pm