AdGuard Home中TLS上游DNS服务器配置问题解析

问题现象

在AdGuard Home的DNS设置中配置上游服务器时，用户发现只有tls://unfiltered.adguard-dns.com能够正常工作，而其他TLS类型的公共DNS服务器（如某CDN服务商的tls://security.example-dns.com）均返回错误提示"could not be used"。

技术背景

AdGuard Home作为DNS服务器时，上游DNS配置支持多种协议：

1. 普通DNS（UDP/TCP）
2. DNS-over-TLS（DoT）
3. DNS-over-HTTPS（DoH）
4. DNS-over-QUIC（DoQ）

其中TLS类型（DoT）的上游服务器需要满足：

• 服务器必须开放853端口
• 客户端需要验证服务器证书
• 网络环境需允许TLS连接

问题排查过程

1. 基础验证
   通过dig命令验证两个域名都能正常解析，排除了DNS解析问题：

   • unfiltered.adguard-dns.com解析到94.140.14.140/141
   • security.example-dns.com解析到1.0.0.2/1.1.1.2

2. 环境测试
   在不同环境（OPNsense社区版和Debian LXC容器）测试结果一致，排除了系统兼容性问题。

3. 网络层分析
   发现只有AdGuard DNS能正常工作，其他TLS连接均失败，暗示可能存在网络层面的拦截。

根本原因

通过深入排查发现：

1. 网络中存在Suricata入侵检测系统
2. Suricata启用了ET规则集
3. 规则ET INFO Observed DNS Over HTTPS Domain拦截了除AdGuard外的其他DNS-over-TLS流量

解决方案

1. 临时方案
   在Suricata中禁用相关规则：

   ET INFO Observed DNS Over HTTPS Domain
   

2. 长期建议

   • 在防火墙/IDS中为内部DNS查询添加白名单
   • 或者明确允许DNS-over-TLS的853端口通信
   • 考虑使用受信任的CA证书以避免SNI检测

最佳实践建议

1. 配置上游DNS时建议：

   • 同时配置多个上游服务器实现冗余
   • 混合使用不同供应商的DNS提高可靠性
   • 定期测试DNS解析性能

2. 网络安全配置建议：

   • 在部署IDS/IPS时，应为内部基础设施服务预留例外规则
   • 对于DNS-over-TLS流量，建议基于IP白名单而非深度包检测

3. 故障排查方法论：

   • 先验证基础网络连通性（ping/telnet）
   • 再检查应用层协议（dig/curl）
   • 最后审查安全设备日志

总结

这个案例展示了在复杂网络环境中配置加密DNS服务时可能遇到的典型问题。通过系统化的排查方法，从应用层到网络层逐步分析，最终定位到安全设备的规则拦截是根本原因。这提醒我们在部署加密DNS服务时，需要全面考虑网络架构中各组件的相互影响。