cert-manager 经 RFC2136 更新 DNS 报 REFUSED：先看 BIND 拒绝的是哪个区域

cert-manager 使用 RFC2136 完成 DNS01 验证，Challenge 一直重试，日志显示 DNS update failed. Server replied: REFUSED。BIND 同时记录 TSIG 签名有效，却拒绝更新主区域；你原本只授权客户端修改独立的 ACME 验证区域。这时应先核对实际更新的区域和记录名，不能直接把主区域改成允许更新。

本文针对 BIND 动态更新与 cert-manager 的 CNAME 委托验证。cert-manager 1.11.0、BIND 9.18 环境中也可能出现这种现象，但仅凭 REFUSED 不能认定某个版本存在委托缺陷。当前配置仍需按照实际 DNS 查询和服务端日志判断。

签名有效与有权修改记录，是两项检查

BIND 日志若先出现 request has valid signature，随后是 signer ... denied，说明这次请求通过了签名检查，但没有通过对应区域的更新授权。这个条件下，反复更换 TSIG 密钥通常没有针对性。

需要把同一次请求的客户端地址、view、updating zone、签名身份和拒绝原因关联起来。内外网采用不同 view 时，本机查询成功不代表 cert-manager 所在网络看到相同记录；手工更新成功，也要确认用的是相同服务器、区域、记录名和签名身份。

若日志更新的是预期 ACME 子区域，继续查该区域的授权。如果更新的是受保护的主区域，而设计要求 TXT 写入委托区域，应先查 CNAME 和所选 solver；主区域拒绝更新可能正是既定安全策略在生效。

检查每个申请名称对应的挑战记录

下面是委托结构示例：

_acme-challenge.example.com.      IN CNAME _acme-challenge.acme.example.net.
_acme-challenge.www.example.com.  IN CNAME _acme-challenge.acme.example.net.

目标 TXT 由 acme.example.net 区域管理。两个 CNAME 分别对应不同申请名称；只添加第一条，不会自动替 www.example.com 建立第二条。应从当前 Challenge 的名称出发，核对它实际使用的 _acme-challenge 名称和完整 CNAME 链。

cert-manager 默认不跟随用于委托的 CNAME。使用这类设计时，实际选中的 DNS01 solver 需要配置 cnameStrategy: Follow。以下仅展示已有 solver 的结构片段，省略字段须保留项目原值：

solvers:
  - selector:
      dnsZones:
        - example.com
    dns01:
      cnameStrategy: Follow
      rfc2136:
        nameserver: 192.0.2.53:53
        tsigKeyName: acme-updates.
        tsigAlgorithm: HMACSHA256
        tsigSecretSecretRef:
          name: acme-tsig
          key: secret

地址和 Secret 名称都是占位示例。selector 匹配原申请域名，凭据则授权更新委托目标区域，不能因为目标位于另一个域就把 selector 一并改成目标域。

如果已有 Follow，不要重复添加后就认定问题解决。核对配置是否属于实际选中的 solver，以及控制器所见 CNAME 是否与预期一致。分离视图、尚未更新的缓存或某个申请名称缺少明确记录，都需要具体查询结果支持。默认自检会使用控制器的递归解析器发现权威服务器，再查询权威服务器；自检解析器与 RFC2136 的更新服务器字段不能混为一项设置。

还应确认挑战 CNAME 是明确配置的记录。开启 Follow 后，DNS 通配 CNAME 合成的答案也可能被跟随，最终目标未必是规划的验证区域。没有委托需求时，不应为了消除错误盲目开启 Follow。

到了正确区域，再调整最小授权

BIND 的 allow-update 按区域控制更新；默认拒绝。update-policy 可根据签名身份、记录名称和类型进一步限制权限。它们不能同时配置在同一个区域中。

若更新目标已经正确，再对照现有策略核对 TSIG 身份、允许的完整名称和 TXT 类型。优先保留主区域的保护，将权限限定在规划的验证区域，必要时收窄到指定 TXT 名称。不要用 allow-update { any; };，也不要仅凭来源 IP 放开主区域来验证猜测。

调整前备份区域配置、现有授权与委托记录，并核对动态区域当前状态。密钥和 Kubernetes Secret 内容不应输出到公开日志。更改授权或 view 会影响其他 DNS 客户端，先在隔离环境检查配置和查询结果，再按已有 DNS 发布流程更新。

确需手工验证动态更新时，使用同一网络路径和身份，在规划的测试名称上验证添加及删除。不要删除整个 TXT 记录集来清理一次挑战；同一个名称可能同时存在其他待验证值。

验收从更新目标一直查到证书

有效的恢复证据包括：服务端更新日志指向预期区域；签名和授权均通过；对应 TXT 值能被需要的权威查询看见；Challenge 和 Certificate 随后达到预期状态。ACME 测试环境签发的证书不受普通浏览器信任，应将验证流程成功与生产证书可用分开检查。

等待后出现证书，不足以证明 REFUSED 由缓存造成，也不能得出固定等待若干小时即可恢复的结论。若更新已成功但自检仍失败，转向 DNS 可见性和传播检查；若仍然 REFUSED，则保留当次更新区域、view 与拒绝原因继续定位。

回退时恢复保存的 solver、委托和授权配置，确认没有意外放宽主区域权限。已经写入的记录不会因配置回退自动消失；只处理确认属于本次测试的值，保留其他证书任务仍需使用的记录。