使用Lego与Hetzner DNS服务时遇到的TXT记录验证问题分析

问题背景

在使用Lego库（通过Traefik集成）与Hetzner DNS服务进行Let's Encrypt证书自动化申请时，用户遇到了TXT记录验证相关的问题。主要表现为两种错误情况：

1. API返回422错误，提示记录已存在
2. DNS传播验证超时，尽管在Hetzner控制台能看到TXT记录

问题原因分析

422 API错误

当Lego尝试通过Hetzner API创建TXT记录时，API返回422状态码并提示记录已存在。这通常表明：

• 之前的验证尝试可能已经创建了记录但未正确清理
• Hetzner API对记录创建有并发限制或缓存机制
• DNS系统存在最终一致性，记录可能尚未完全同步

DNS验证超时问题

即使用户在Hetzner控制台能看到TXT记录，Lego的DNS验证仍然失败，返回NXDOMAIN。这主要与DNS解析环境有关：

1. 本地DNS缓存：用户使用了Pi-hole作为本地DNS服务器，可能存在缓存或延迟问题
2. DNS传播延迟：Hetzner的DNS变更可能需要时间才能传播到所有权威服务器
3. 验证服务器与本地DNS不一致：Let's Encrypt的验证服务器可能查询的是不同的DNS路径

解决方案

调整超时参数

1. 增加传播延迟：在Traefik配置中增加delayBeforeChecks参数（如设置为1分钟），给DNS变更足够时间传播
2. 调整Hetzner专用超时：设置HETZNER_PROPAGATION_TIMEOUT环境变量为更高值（如120秒）

DNS验证测试方法

建议使用以下命令直接查询Hetzner权威DNS服务器，验证TXT记录是否真正生效：

drill @hydrogen.ns.hetzner.com. _acme-challenge.example.com TXT

环境优化建议

1. 绕过本地DNS缓存：在验证期间临时使用公共DNS（如1.1.1.1或8.8.8.8）
2. 检查Pi-hole配置：确保Pi-hole不缓存TXT记录或设置较短的TTL
3. 重试机制：配置Traefik/Lego在失败时自动重试

技术原理深入

Lego的DNS验证流程

1. 通过DNS提供商的API创建TXT记录
2. 定期查询DNS系统直到找到预期记录
3. 向Let's Encrypt确认验证
4. 清理创建的TXT记录

Hetzner DNS特性

Hetzner的DNS系统具有以下特点：

• API变更不是即时生效的
• 不同地理位置的DNS服务器可能有不同的同步状态
• 对相同记录的频繁操作可能触发速率限制

最佳实践

1. 在自动化证书管理系统中实现指数退避重试机制
2. 监控DNS记录的创建和删除操作，确保资源清理
3. 在非生产环境充分测试配置参数
4. 考虑使用DNS服务的API日志功能排查问题

通过理解这些底层原理和采取适当的配置调整，可以显著提高使用Lego与Hetzner DNS服务进行证书自动化管理的成功率。