配置CAA记录限制证书签发机构

CAA记录用来声明哪些证书颁发机构可以为域名签发公开信任证书。它不是域名所有权证明，不会直接申请或安装证书，也不能代替HTTP或DNS验证。修改CAA主要影响后续签发和续期，不会因此立即吊销已经签发的证书。

先确认实际由谁签发证书

列出源站、CDN、托管服务和通配符证书分别由哪些CA签发、哪些服务负责自动续期。若有平台使用多家CA或备用CA，只授权其中一家可能使后续签发失败。不要仅因为正在用某个CDN，就把CDN公司名称当成CA标识。

向实际签发或负责续期的CA确认其CAA授权标识及必要参数；不要把证书中显示的颁发者名称、服务商品牌、CA官网地址或证书文件名直接当成记录值。托管服务可能使用多家CA，应先取得完整授权要求。没有CAA限制时，公开CA仍必须验证域名控制权；允许某家CA也不意味着可以免验证签发。

理解名称、标记和值

以下三行只展示字段关系，不是建议整组照抄。ca.example与wildcard-ca.example均为文档占位标识，不对应实际CA；security@example.com也是占位邮箱，必须替换为已确认的授权标识和自己控制的接收地址。DNS面板若把Flags、Tag、Value拆成不同输入项，应分别填写，不把整段文本塞入CA标识一栏。

example.com. CAA 0 issue "ca.example"
example.com. CAA 0 issuewild "wildcard-ca.example"
example.com. CAA 0 iodef "mailto:security@example.com"

允许多家CA时增加多条对应issue记录，授权是相加的，不在同一值中用逗号拼接多家标识。没有颁发者标识的issue值（例如分号）表示不授予任何CA该条授权；它不会覆盖同一记录集中另一条有效的正向授权。拼错值或误填空值可能阻断签发，不随意复制其他域名的记录。iodef可使用mailto、HTTP或HTTPS报告地址，但CA不一定发送报告；仅有iodef不会限制签发，也不能代替监控或issue授权。

issuewild与子域继承怎么判断

如果存在issuewild记录，通配符签发使用对应issuewild授权；没有issuewild时，通配符使用issue规则。普通域名证书检查时忽略issuewild；如果相关CAA集合只有issuewild而没有issue，它并不因此限制普通域名证书的CA。只有确实需要把普通与通配符授权分开时，才分别配置。

对不含别名的名称，CA从目标域名向父级查找，使用最近遇到的CAA记录集。例如api.example.com有自己的CAA时，不再把example.com的记录机械合并成同一组授权。申请包含多个域名的证书时，每个名字都需要满足相应CAA检查。

有CNAME别名时，CAA检查还会跟随别名。不要在一个已有CNAME的同名记录旁直接添加冲突的CAA，也不要只检查父域就认定别名目标不会影响签发。应同时核对服务商说明及实际查询链。

在支持CAA的权威DNS中创建记录

1. 先根据域名当前的权威NS确定实际维护DNS的管理入口，选择正确DNS区域，并确认该服务支持CAA记录。不因为域名在某处注册，就假定应在注册商处改记录。
2. 在实际记录管理界面创建CAA，名称使用本次授权的完整域名或面板认可的区内名称；只有面板明确支持时才使用@代表区根。
3. 按实际界面的字段分别填写Flags、Tag和值；普通授权示例使用Flags 0、Tag issue，值填写已向CA确认的真实授权标识，不填写本文占位值。只提供整行输入的界面则按它明确要求的格式填写。
4. 只有需要区分通配符授权时再配置issuewild；只有确认报告接收方式及维护责任后才配置iodef。不要为了凑齐示例而添加没有用途的记录。
5. 保存后对照实际记录列表，核对完整名称、Flags、Tag与值。保留仍有用途的其他CA授权，并记录本次改动，避免影响现有自动续期。

具体菜单和字段布局以正在使用的DNS服务实际界面为准。保存后继续查询权威响应，不能只凭列表一行认定授权范围已经符合预期。

在权威DNS保存后查询

以下命令在macOS或已安装dig的Linux执行。Ubuntu/Debian尚未提供dig时可安装dnsutils；Windows应使用已提供CAA查询能力的工具或相应环境，不把查询工具不支持CAA误判成域名没有限制。example.com和NS_NAME必须换成自己域名及其权威NS主机名。

dig example.com NS +short
dig @NS_NAME example.com CAA
dig @NS_NAME api.example.com CAA
dig example.com CAA +short

先看完整响应头的status、权威回答的aa标志，以及ANSWER区是否符合保存的名称、Tag和CA标识，再比较递归查询的缓存结果。子域若已经独立委派，应使用该子域真正的权威NS；父区返回的委派referral不能当成子域CAA的最终答案。只用+short时可能看不到错误状态，因此故障排查要保留完整输出。目标子域返回空结果时，还应检查父级继承；NOERROR下的空答案、NXDOMAIN、SERVFAIL和超时是不同结果，不能一概解释为“没有CAA，所以允许”。

有CNAME时，还要查询真实别名目标的CAA。先从自己保存的CNAME记录或接入服务商配置确认目标；下面仅演示www.example.com指向edge.example.net的情况，两者都必须换成实际名称：

dig www.example.com CAA
dig edge.example.net CAA

单次CAA查询会按DNS规则跟随CNAME；上面的目标查询用于辅助核对实际别名链，不是另起一条目标父域继承链。按RFC 8659，如果对原申请名称的本轮CAA查询跟随别名后仍未找到CAA，应回到原申请名称的父级继续查询。例如www.example.com指向edge.example.net，本轮结果为空时下一层查example.com，而不是改查example.net。不能把旧算法中的别名目标父域爬升混入这一流程。

别名目标属于另一个DNS区域时，权威检查使用该目标所在区域的真实权威NS，不能沿用原域名的NS_NAME。保留每次完整响应和实际别名链；超时或SERVFAIL不是空CAA结果，不能据此继续按无记录处理。

核对托管服务与实际CAA集合

DNS托管、CDN或托管证书服务可能按各自机制管理或补充CAA记录；具体行为、使用的CA以及控制台是否显示完整记录，应向实际服务确认，不能从其他平台的规则推断。将权威查询得到的完整CAA集合与自己的授权目标逐项比较，不把面板只显示一条当成只授权一家CA的证明。

若目标是严格的单一CA授权，先确认DNS与托管证书方案能否满足。发现额外记录时先核实其用途和管理来源，不直接判为入侵，也不为删除它们而关闭线上证书服务，造成HTTPS中断。

签发或续期失败时查什么

变更前保存原记录、实际CA要求与证书续期安排；修改后先核对完整权威响应，再按实际CA的流程做受控签发或续期验证，确认自动任务。若本次变更导致失败，先恢复已记录的原CAA集合并查询确认，再结合CA错误排查，避免临近证书到期仍没有可用续期路径。