AdGuardHome DNS-over-TLS端口配置异常导致CPU高负载问题分析

问题现象

在AdGuardHome中启用加密功能并指定DNS-over-TLS(DOT)端口后，系统CPU使用率从正常的1-2%急剧上升到50%左右。这一现象在多个环境中重现，包括Docker容器和Proxmox虚拟环境。

技术背景

DNS-over-TLS是一种通过TLS加密DNS查询的协议，默认使用853端口。AdGuardHome支持多种加密DNS协议，包括DOT和DNS-over-HTTPS(DOH)。当启用这些功能时，系统需要额外的计算资源来处理加密/解密操作。

问题排查过程

1. 环境验证：问题在两种不同部署方式(Docker和Proxmox容器)中均能重现，排除了单一环境配置错误的可能性。

2. 证书类型检查：使用的Let's Encrypt RSA证书，理论上不会导致如此高的CPU负载。

3. 网络拓扑分析：服务仅部署在内网环境，排除了来自互联网的滥用攻击可能性。

4. 客户端排查：发现Home Assistant的备用DNS设置与AdGuardHome的DOT端口配置产生了冲突。

根本原因

Home Assistant的备用DNS功能不断尝试通过DOT端口进行查询，但由于配置不当导致大量重试请求。这些请求被AdGuardHome接收并处理，触发了频繁的TLS握手过程，消耗了大量CPU资源。

解决方案

1. 禁用冲突配置：在Home Assistant中关闭备用DNS功能后，CPU负载立即恢复正常。

2. 替代方案：

   • 使用DNS-over-HTTPS(DOH)作为替代加密方案
   • 检查并优化所有客户端的DNS配置
   • 考虑使用ECC证书替代RSA证书以降低加密计算开销

最佳实践建议

1. 监控部署：在启用新功能后，应密切监控系统资源使用情况。

2. 分阶段测试：先在小范围环境中测试加密DNS功能，确认无异常后再推广到生产环境。

3. 客户端审计：在部署加密DNS服务前，应全面审计网络内所有客户端的DNS配置。

4. 性能基准测试：对于资源受限的环境，建议先进行性能测试评估加密DNS的可行性。

总结

加密DNS服务虽然能提高隐私保护，但配置不当可能导致意外的性能问题。通过本次案例，我们了解到客户端配置对服务端性能的重要影响。在部署类似服务时，全面的环境检查和分阶段验证是确保稳定运行的关键。