SpoofDPI项目中的DNS-over-HTTPS实现方案探讨

背景介绍

SpoofDPI是一个网络流量处理工具，在其v0.10版本中，DNS-over-HTTPS(DoH)的实现从原来的babolivier/go-doh-client切换到了likexian/doh。这一变更引发了一些技术层面的讨论，特别是关于DoH实现方案的选择问题。

技术问题分析

当前使用的likexian/doh实现存在几个关键问题：

1. 非标准实现：该库并非真正的RFC8484标准实现，而是直接调用了特定DNS提供商(如知名服务商A和B)的JSON API端点。这种实现方式与标准DoH协议不兼容。

2. 灵活性缺失：由于硬编码了特定的DNS提供商地址(providerA.com和providerB.com)，当这些地址无法解析时，系统将回退到传统DNS查询，存在DNS投毒风险。

3. 提供商锁定：用户无法自由选择其他DoH提供商，限制了在不同网络环境下的适应性。

解决方案探讨

针对这些问题，社区提出了几个可能的解决方案：

1. 回退到原实现：虽然babolivier/go-doh-client可能不再活跃维护，但它遵循RFC8484标准，提供了更好的兼容性和灵活性。

2. 自主开发轻量级解析器：考虑到SpoofDPI主要需要处理A记录(IPv4地址)和AAAA记录(IPv6地址)，可以开发一个专用的轻量级DoH客户端。

3. 采用IETF参考实现：使用m13253/dns-over-https中的doh-client组件，这是一个符合RFC8484标准的实现，具有更好的兼容性。

技术建议

从技术角度考虑，建议采取以下方案：

1. 优先考虑标准兼容性：选择符合RFC8484标准的实现，确保与各种DoH服务器的兼容性。

2. 保持提供商可选性：实现应允许用户配置不同的DoH提供商，而不仅限于特定的几家服务商。

3. 考虑维护状态：在选择第三方库时，应评估其维护活跃度，或者考虑自主维护fork版本。

4. 性能考量：对于SpoofDPI这样的网络工具，DoH解析的性能和可靠性同样重要，需要在选择时进行充分测试。

结论

DNS-over-HTTPS作为现代网络安全的重要组成部分，其实现方案的选择直接影响工具的可靠性和可用性。对于SpoofDPI项目而言，回归标准兼容的实现或开发专用组件可能是更优的选择，既能保证功能完整性，又能提供更好的用户体验。