前言

之前在博文里头提到了dns记录中有一个叫做CAA记录的东西。而最近我有申请到了trust asian的免费ssl证书。索性花时间好好研究这个东西

什么是CAA记录

由来

从开始来说，我们上网所用的https中的ssl需要证书，而网站假如要被浏览器（无需人为操作）信任，则需要由受信任的（不仅受您，还受大家信任的）证书签发商发行的证书。而受信任的证书签发商又有很多，虽然他们基于信誉不会随意颁发证书，但是你很难保证有些证书签发商无意的或者偶发的，抑或是网站内部人员搞到了权限，向其他证书签发商申请证书。

这件是不是没有发生过，知名的免费证书签发商Let’s Encrypt就出现了这个问题错误的颁发了证书，具体情况可以自行在百度上搜索：点此在百度上查看相关信息。而域名的CAA记录就是尝试避免这种事件发生的一种尝试。

CAA 全称：Certification Authority Authorization 。这个是dns的一种记录，该记录能限定证书颁发机构颁发证书。所有公共证书颁发机构都必须遵守 CAA 记录。在给域名颁发证书的时候，证书签发商必须检查签发域名中的的CAA 记录，如果 CAA 没有授权该颁发商颁发，则不能颁发该证书，但是假如如果该域名中没有 CAA 记录，则可以发布。（虽然大部分情况都没有设置caa记录，这只是一种额外的防治方法）

结构

首先要注意的是，要使用caa记录，需要你的dns权威域名解析提供商支持相应的记录，反正我用的是阿里的dns云解析服务，阿里是支持的。

首先要搞明白caa记录是什么样的。

单个值结构

CAA记录的格式为：[flag] [tag] [value]

首先是[flag]记录，flag值是一个整数，范围为0~255

其中的每个flag都有特殊含义，我怕这里没有讲清楚，点这个链接直接跳转到标准组织的文件来查看源说明

flag记录一般都填做0,阿里云解析仅支持填写0或者是128。阅读ietf的文档，我们得知以下内容（以下是摘录）

The critical flag is intended to permit future versions CAA to introduce new semantics that MUST be understood for correct processing of the record, preventing conforming CAs that do not recognize the new semantics from issuing certificates for the indicated domains.
In the following example, the property ‘tbs’ is flagged as critical. Neither the example.net CA nor any other issuer is authorized to issue under either policy unless the processing rules for the ‘tbs’ property tag are understood.
$ORIGIN example.com .
CAA 0 issue “ca.example.net; policy=ev” .
CAA 128 tbs “Unknown”
Note that the above restrictions only apply at certificate issue. Since the validity of an end entity certificate is typically a year or more, it is quite possible that the CAA records published at a domain will change between the time a certificate was issued and validation by a relying party.

ietf.org

以下是我的理解（可能有错误，如发现，请指正，谢谢，邮箱q2019@q2019.org)

一般情况下填写0代表后方（下文会学习）的值中所包含的证书签发机构可以签发该域名的证书。

flag是用来让以后的证书签发商可以理解caa中的新的语义来设计的.这个值可以用来防止不理解该语义的证书签发商签发这个域名的证书。

其中 0 代表如果证书签发机构无法理解本条信息，就忽略这条信息。

而128代表除非能够理解后方提供的值（如ietf给出来的例子，tbs这个值）就不允许给该域名签发证书。

接下来就是tag记录

tag记录 tag记录可以填写以下内容

issue(一般是这个）

issuewide

iodef

其中 issue记录值记录着可以为该域名颁发ssl证书的提供商，（这所有类型的证书）

而issuewide记录则明确指定了可以为该域名颁发通配符证书的证书签发商。

iodef记录则记录着指定认证机构可以向其报告策略违规的 网址或邮箱。

那么一个正常的caa记录应该是这个样子的：

对于某个域名：（子域名或者@)caa记录可以为这样

0 issue ‘ca.example.com’

0 iodef “mailto:example@example.com”

关于其根域名与子域名的关系

一个域名可以有无限多个子域名，但是现在就出现了个问题，假如子域名有caa记录，或者根域名有caa记录，该怎么处理？

一般是子域名优先，即假如某个域名有一个caa记录，而其子域名又有一个caa记录，那么以子域名的caa记录为准，但是假如子域名没有caa的话，那就遵守上一级的caa记录。

当然，还有一个小小的问题，就是假如一个域名的记录是cname的记录类型，caa的rfc要求了一种附加的行为，即要求ca签发机构也要检查cname记录值的域名的caa域名，可以说，你的域名的caa记录可能会收到第3方caa记录的影响。。以下是Let’s Encrypt网站有关这个要求的内容,但是其中文版本和英文版本不一样，我是以英文版本来进行理解的。

Note also that CAA checking follows CNAME redirects, just like all other DNS requests. If “community.example.org” is a CNAME to “example.forum.com”, the CA will respect any CAA records that are set on “example.forum.com”. It is not allowed for a domain name with a CNAME record to have any other records, so there cannot be conflicts between CAA records on the original name and CAA records on the target of the redirect.（英文站点）（let’s encrypt)（新）

CAA 的 RFC指定了一种称为“爬树”的附加行为，它要求 CA 同时检查 CNAME 解析结果的父域名。 后来一份勘误删除了这个额外的行为，因此 Let’s Encrypt 和其他 CA 没有实施该行为。（中文站点）（let’s encrypt)（旧）

所以说我们来举个例子。假如我有一个子域名1.2.q2019715.xyz，这个网址通过cname解析到了1.2.q2019.org

那么ca证书签发商检查时候就会按照如下的顺序进行检查：

先：

1.2.q2019.org

再

2.q2019.org

然后

q2019.org

最后

org.

直到返回空值，即没有限制,注意一下啊，cname和caa记录是会有冲突的!即一个子域名不能既有cname而且有caa记录。比如说以阿里的云解析控制台为例子，假如尝试这样做，会出现如下的问题。

后记

以上就是我关于dns caa记录的学习笔记，感谢阅读。

参考文献

参考文献：https://letsencrypt.org/zh-cn/docs/caa/

参考文献：https://help.aliyun.com/document_detail/29725.html

参考文献：https://zhuanlan.zhihu.com/p/444060138?utm_id=0