BIND 添加 TXT 后报 CNAME and other data：同一名称不能兼作别名

给子域名添加 TXT 验证记录后，BIND 加载区域失败，日志出现 CNAME and other data。这通常需要检查该 TXT 的完整名称是否已经存在 CNAME：同一个名称不能一面作为别名，一面又存放自己的普通 TXT、A 等数据。

本文针对 BIND 9 的静态区域文件编辑。通过动态更新、DNS 管理面板或签名自动化维护的区域，应走原管理流程，不要直接改文件绕过 journal 或自动签名。

对照完整名称，而不是只看新增那一行

下面是会冲突的记录结构示例，不能作为可加载配置使用：

portal.example.com. IN CNAME service.example.net.
portal.example.com. IN TXT "verification-value"

两个记录的 owner 都是 portal.example.com.，冲突就发生在这里。CNAME 的目标 service.example.net. 是另一个名称，不要把目标地址与别名混为一处。

区域里的相对名称受 $ORIGIN 影响。portal、某行省略的 owner、include 文件中的名称，都可能最终指向同一个完整名称。日志的区域路径、行号与出错名称可以帮助定位。把 TXT 文本再加一层引号，或者给原名称补末尾点，不会让已有 CNAME 和同名 TXT 合法共存。

DNSSEC 所需的签名等元数据有专门规则，不属于这里要删除的普通业务记录；看到别名旁的签名时，不要为了“只留 CNAME”手动清理它们。

验证方要求哪个名称，就处理哪个名称

先查看验证服务要求的确切 TXT 名称。如果它给的是 _verify.portal.example.com.，就应按那个名称配置，而不是自行省略前缀放到 portal.example.com.。子名称和父名称不是同一个 owner，但也不能未经验证方支持随意改名。

若确实要求在别名自身放 TXT，可选路径取决于业务：验证方是否支持另一个验证名称、其他验证方式，或者是否可以调整该名称的解析结构。不能默认把 TXT 移到 CNAME 目标就能验证成功，也不要直接删除正在承载网站的 CNAME。

只有服务方允许直接用稳定地址、并已核对可维护性时，才考虑把别名改成地址记录后再共存 TXT。托管服务的地址可能变更，简单复制当前解析出来的 IP 会失去它原本的更新机制；不要为通过验证引入后续访问故障。

加载前检查，加载后核对每台权威服务器

保存原区域文件和有关配置，按区域发布流程更新 SOA serial，再检查待发布文件。命令中的区域名和路径均为示例：

named-checkzone example.com /etc/bind/zones/example.com.zone

这条检查验证区域文件的语法与完整性，不负责发布。通过后才按现有方式加载并同步。不要用降低检查等级让冲突记录强行进入服务。

加载失败时，查看日志及当前实际提供的答案，不要假定新记录已经上线，也不要假定所有节点仍使用同一旧版本。加载成功后，对每台实际权威服务器查询目标 TXT 和仍需保留的解析记录，确认区域版本一致，最后由验证服务重新检查。

如果改动影响网站或验证，恢复原记录内容并按区域版本规则发布回退；涉及 secondary 时，不能简单退回较小的旧 serial 然后期待自动同步。缓存里的旧答案仍可能保留到 TTL 到期。验收既要满足 TXT 验证，也要确认原业务域名的解析和访问正常。