最后更新时间： | 查看所有文档
CAA 是一种 DNS 记录类型，它允许网站所有者指定哪些证书颁发机构 (CA) 被允许签发包含其域名证书。它最早在 2013 年被标准化，我们今天使用的版本在 2019 年由 RFC 8659 和 RFC 8657 标准化。默认情况下，每个公共 CA 都被允许为公共 DNS 中的任何域名签发证书，前提是它们验证了对该域名的控制权。这意味着，如果许多公共 CA 之一的验证流程中存在漏洞，则每个域名都可能受到影响。CAA 为域名持有者提供了一种降低这种风险的方法。
使用 CAA
如果您不关心 CAA，您通常无需执行任何操作（但请参阅下面的 CAA 错误）。如果您想使用 CAA 来限制哪些证书颁发机构被允许为您的域名签发证书，您需要使用支持设置 CAA 记录的 DNS 提供商。查看 SSLMate 的 CAA 页面 以获取此类提供商的列表。如果您的提供商已列出，您可以使用 SSLMate 的 CAA 记录生成器 生成一组 CAA 记录，列出您要允许的 CA。
在何处放置记录
通常，您希望在注册的域名（例如“example.org”或“mysite.co.uk”）上设置 CAA 记录。这样，它们将应用于该域名及其下创建的任何子域名，例如“community.example.org”。
请注意，CA 将始终尊重最靠近其为其签发证书的域名的 CAA 记录。因此，如果您请求为“www.community.example.org”签发证书，CA 将检查“www.community.example.org”，然后检查“community.example.org”，然后检查“example.org”，在找到第一个 CAA 记录时停止。
这意味着您可以覆盖子域的 CAA。例如，假设您自己托管“example.org”，但将“api.example.org”托管在云提供商上。您可以使用“example.org”上的 CAA 记录来表明只有 Let's Encrypt 可以为该域名及其所有子域名签发证书，还可以使用“api.example.org”上的 CAA 记录来覆盖它并允许云提供商为该子域名签发证书。
还要注意，CAA 检查遵循 CNAME 重定向，就像所有其他 DNS 请求一样。如果“community.example.org”是“example.forum.com”的 CNAME，则 CA 将尊重“example.forum.com”上设置的任何 CAA 记录。不允许具有 CNAME 记录的域名拥有任何其他记录，因此原始名称上的 CAA 记录与重定向目标上的 CAA 记录之间不会发生冲突。
在记录中放置什么
所有 CAA 记录都遵循相同的基本格式
CAA <flags> <tag> <value>
标志只是一个整数，并且几乎始终只是整数0，表示没有设置标志。如果您愿意，可以将标志设置为整数128，表示“关键位”已设置，并且如果 CA 不识别标签字段的内容，则应立即停止并不会签发证书。
标签是一个字符串，指示这是一种什么样的 CAA 记录：在大多数情况下，它是issue 或 issuewild。下面将详细介绍这些内容。
最后，值是一个字符串，包含最多一个 CA 标识符（例如“letsencrypt.org”）以及一些可选的分号分隔的参数，这些参数将在下面讨论。
issue 和 issuewild 属性
带有issue 标签的记录仅控制 CA 是否可以为该域名及其子域名签发证书。通常，这是您唯一需要的记录，因为它在没有其他记录的情况下控制着普通（例如“example.org”）和通配符（例如“*.example.org”）签发。您可以通过在 CAA 记录的 value 部分中放入该 CA 的标识域名来控制哪个 CA 可以为该域名签发证书。
带有issuewild 标签的记录控制 CA 是否可以签发通配符证书（例如“*.example.org”）。您只需要在希望对通配符和非通配符签发有不同权限时才使用issuewild 记录。
请注意，您可以拥有多个具有相同属性类型的记录，它们是累加的：如果这些记录中的任何一个允许 CA 签发，则它就被允许。
Let's Encrypt 的 CAA 标识域名是letsencrypt.org。这在 我们的 CP/CPS 的第 4.2.1 节 中正式记录。
validationmethods 参数
此参数可以放在 CA 标识域名之后，以控制该 CA 可以使用哪些验证方法来确认对域名的控制权。这可以用来将验证限制为您更信任的方法。例如，如果您想将 CA 限制为仅使用 TLS-ALPN-01 方法，您可以将;validationmethods=tls-alpn-01 附加到您的 CAA 记录值。
Let's Encrypt 识别以下验证方法字符串
http-01dns-01tls-alpn-01
accounturi 参数
此参数可以放在 CA 标识域名之后，以控制哪些 ACME 帐户可以请求为该域名签发证书。这可以用来确保暂时劫持您的域名但无法访问您的 ACME 帐户密钥的人无法签发恶意证书。
Let's Encrypt 的帐户 URI 类似于https://acme-v02.api.letsencrypt.org/acme/acct/1234567890，其中最后的数字是您的帐户 ID。
示例
一个允许 Let's Encrypt 为“example.org”签发的简单 CAA 记录可能如下所示
example.org CAA 0 issue "letsencrypt.org"
一组更复杂的 CAA 记录可能如下所示
example.org CAA 0 issue "myca.org;validationmethods=dns-01"
example.org CAA 0 issuewild "myca.org"
example.org CAA 128 issue "otherca.com;accounturi=https://otherca.com/acct/123456"
在此示例中，MyCA 可以为“example.org”签发证书，但只能使用 DNS-01 验证方法。它也可以使用任何验证方法签发通配符证书。最后，OtherCA 也可以签发证书，但前提是请求来自帐户号123456，并且只有当 OtherCA 识别并知道如何正确处理accounturi 限制时。
CAA 错误
由于 Let's Encrypt 在签发每个证书之前都会检查 CAA 记录，因此有时我们即使对于没有设置任何 CAA 记录的域名也会遇到错误。当我们遇到错误时，无法判断我们是否被允许为受影响的域名签发证书，因为可能存在禁止签发的 CAA 记录，但由于错误而不可见。
如果您收到与 CAA 相关的错误，请尝试对我们的 测试环境 进行几次更多尝试，以查看它们是暂时的还是永久的。如果它们是永久性的，您需要向您的 DNS 提供商提交支持问题，或更换提供商。如果您不确定您的 DNS 提供商是谁，请咨询您的托管提供商。
一些不熟悉 CAA 的 DNS 提供商最初会以“我们不支持 CAA 记录”的回复来解决问题报告。您的 DNS 提供商不需要专门支持 CAA 记录；它只需要对未知查询类型（包括 CAA）返回 NOERROR 响应。对无法识别的 qtype 返回其他操作码，包括 NOTIMP，违反了 RFC 1035，需要修复。
SERVFAIL
人们遇到的最常见的错误之一是 SERVFAIL。大多数情况下，这表示 DNSSEC 验证失败。如果您遇到 SERVFAIL 错误，第一步应该是使用 DNSSEC 调试器，例如 dnsviz.net。如果这不起作用，则可能是您的域名服务器在响应为空时仅生成不正确的签名。而 CAA 响应通常为空。例如，PowerDNS 在 4.0.3 及以下版本中存在此错误。
如果您没有启用 DNSSEC 并收到 SERVFAIL，第二个最有可能的原因是您的权威域名服务器返回了 NOTIMP，如上所述，这违反了 RFC 1035；它应该返回一个空响应的 NOERROR。如果是这种情况，请向您的 DNS 提供商提交错误报告或支持票证。
最后，SERVFAIL 可能由您权威域名服务器的故障引起。检查您域名服务器的 NS 记录并确保每个服务器都可用。
超时
有时 CAA 查询会超时。也就是说，即使经过多次重试，权威域名服务器也不会回复任何答案。最常见的情况是，您的域名服务器前面有一个配置错误的防火墙，它会丢弃具有未知 qtype 的 DNS 查询。向您的 DNS 提供商提交支持票证并询问他们是否配置了这样的防火墙。