ACME DNS-01报NXDOMAIN：_acme-challenge记录与权威DNS排查

申请通配符或多域名证书时ACME DNS-01常见的第一句报错就是NXDOMAIN。它不是“TXT值不对”的同义词而是查询链路里连这个名字都没有找到。先把重试按钮放一边查错名称重试只是在给DNS服务器增加心理负担。本文把验证域名、CNAME委托、权威NS、TXT传播和DNSSEC拆开定位到哪一层再修哪一层。一、NXDOMAIN到底说明了什么DNS-01要求客户端把客户端根据token与账户密钥派生出的验证值放在_acme-challenge.待验证域名的TXT记录中ACME服务器再查询该名称并比对值。Let’s Encrypt官方文档明确了这个名称和TXT验证方式RFC 8555也把dns-01定义为由ACME服务器查询DNS记录完成验证。NXDOMAIN的重点是“名称不存在”和NOERROR但没有TXT、SERVFAIL、超时不是一回事。不同解析器可能缓存负结果所以改完记录后不能只看本机一次查询。二、先确认ACME真正查询的名称最容易犯的错是把待签发域名直接加TXT或者通配符写成带星号的查询名。验证*.example.com时常规DNS-01查询仍围绕_acme-challenge.example.com不是_acme-challenge.*.example.com。实际名称以ACME客户端日志和订单授权对象为准不要凭记忆拼接。DOMAINexample.com NAME_acme-challenge.${DOMAIN} printf query%s\n $NAME dig noall answer $NAME TXT dig noall authority $NAME TXT第一条看答案第二条看权威区是否返回SOA。若查询名写错后面的CNAME和TXT检查都没有意义。生产脚本应把最终规范化FQDN写入日志避免把根域、子域和通配符混成一锅。三、区分NOERROR空答案与NXDOMAIN两者在排障上完全不同NXDOMAIN通常表示权威服务器认为该名字不存在NOERROR/NODATA表示名字存在但没有所请求类型的记录。若父域存在而子域不存在权威响应里的SOA通常能帮助判断否定缓存边界。dig noall comments authority _acme-challenge.example.com TXT dig trace _acme-challenge.example.com TXT # 只把实际返回的状态写入诊断日志不用grep到空输出就判定成功 dig noall answer _acme-challenge.example.com TXT不要只执行dig TXT后看“没有输出”。保存 status、ANSWER、AUTHORITY 和 SERVER才能区分没有记录、被权威拒答和本地递归缓存异常。trace适合定位委派链路不代表ACME服务器一定使用同一个递归解析器。四、沿权威NS一路查别被本地缓存带偏先查域名的NS再直接询问权威服务器。权威服务器没有记录而公共递归仍有旧TXT说明缓存尚未过期权威已有记录而本地仍NXDOMAIN则优先检查负缓存、查询线路和DNSSEC。ZONEexample.com dig short NS $ZONE for ns in $(dig short NS $ZONE); do printf \nserver%s\n $ns dig noall comments answer authority \ $ns _acme-challenge.$ZONE TXT done本例验证区域根域查子域时单独指定NAME不能把查询名改成区域根域。ZONE应为实际权威区域子区委派需用trace确认。若DNS服务商控制台显示记录但权威NS回答没有它常见原因是改错了账户、区域或记录名若权威回答正确再看递归缓存和传播不要继续改记录。五、CNAME委托时查目标不要同时塞CNAME和TXT如果把_acme-challenge.example.comCNAME到专用验证域TXT通常应放在CNAME目标上。DNS名称不能同时把同名CNAME和其他数据记录当成普通并列项使用委托目标也必须再追到它自己的权威NS。NAME_acme-challenge.example.com dig noall answer $NAME CNAME TARGET$(dig short $NAME CNAME | sed s/\.$//) if [ -n $TARGET ]; then dig noall answer $TARGET TXT dig noall authority $TARGET TXT fi这里有个很隐蔽的坑CNAME目标末尾的点表示完整域名API填值时有的服务商要求相对名有的要求FQDN。最终以权威查询结果为准。若历史TXT残留先确认是否属于仍在进行的并发验证再按服务商语义删除不能用“清空全部TXT”这种粗暴方案。六、DNSSEC、SERVFAIL和传播延迟怎么分层NXDOMAIN修正后变成SERVFAIL方向可能已经从记录名转到DNSSEC、签名过期或委派不一致。对比普通解析器、权威NS和带DNSSEC校验的结果不要把SERVFAIL当作TXT值错误。响应现象通常含义先做什么NXDOMAIN权威认为名称不存在查验证名称、区域和委派NOERROR无TXT名称存在但没有TXT查记录类型、目标和生效区SERVFAIL解析链或DNSSEC失败查权威状态、签名和委派NOERROR有旧TXT能查到但值不匹配保留并发值核对token后重试DNS传播不是一个固定秒数。TTL影响缓存但负缓存还受SOA中的否定缓存参数影响权威服务器、递归解析器和CA验证器看到的时间可能不同。修改后等待并重复查询比连续创建新订单更稳妥。七、用三种方案做中立对照纯命令行可以直接调用DNS Provider APIacme.sh等开源客户端也能通过DNS API自动写入TXT平台化方案则通常把订单、权限、重试和多目标部署统一管理。无论选哪种核心验收都一样写入的是正确验证名称权威NS能查到正确TXT验证完成后按策略清理旧值。本文只作技术边界对照不把某个方案写成唯一答案。参考Let’s Encrypt DNS-01文档、acme.sh开源仓库 与 CertbotX。八、续期前验收清单从ACME日志取出准确授权域名确认没有把星号写进查询名。递归查询与至少一台权威NS分别读取TXT并记录status、ANSWER和AUTHORITY。存在CNAME时只沿目标查TXT确认目标区域和末尾点语义。把NXDOMAIN、NOERROR空答案、SERVFAIL和旧TXT分开处理。确认验证完成后再清理对应TXT不删除并发订单仍需要的值。最终用ACME staging或受控测试订单复验再接入自动续期和告警。事实依据RFC 8555 第8.4节、Let’s Encrypt Challenge Types文档。线上证书是否真正更新还要另行读取部署节点的证书指纹和有效期DNS查询成功不等于Nginx已经加载新证书。