解决dae项目中使用外部DNS服务的问题分析

问题背景

dae项目是一个网络工具，用户在使用过程中报告了一个关于DNS解析的问题。具体表现为：当配置上游DNS为1.1.1.1使用UDP 53端口时工作正常，但配置为加密DNS(https://1.1.1.1/dns-query)使用TCP 443端口时则无法正常通信。

问题排查过程

经过开发者团队的分析和测试，发现该问题与网络接口绑定配置有关。具体表现为：

1. 当不绑定外部接口时，DNS查询可以正常工作
2. 绑定外部接口后，加密DNS查询会出现问题
3. 问题与BPF(伯克利包过滤器)的处理逻辑有关

技术原因分析

问题的根本原因在于BPF处理逻辑中对于网络接口流量的处理方式不当。在同时绑定外部和内部接口时，BPF程序错误地返回了TC_ACT_OK而不是TC_ACT_PIPE，导致流量无法正确转发。

TC_ACT_OK和TC_ACT_PIPE是Linux流量控制中的两种不同动作：

• TC_ACT_OK表示流量处理完成，不再继续后续处理
• TC_ACT_PIPE表示流量应继续通过后续的处理链

在dae的特定场景下，需要返回TC_ACT_PIPE才能正确处理外部和内部在同一网卡的情况。

解决方案

开发团队通过以下方式解决了该问题：

1. 修改BPF程序，将外部接口的返回改为TC_ACT_PIPE
2. 建议用户在配置中启用auto_config_kernel_parameter参数

此外，对于测试和验证，开发团队还提供了以下实用方法：

• 使用dae trace命令进行流量追踪和调试
• 通过PR Build直接获取预编译的二进制进行测试

最佳实践建议

基于此问题的解决经验，建议dae用户：

1. 对于DNS配置，优先考虑使用本地DNS服务
2. 在配置复杂网络环境时，注意外部/内部接口的绑定设置
3. 遇到问题时，可以使用trace功能进行诊断
4. 保持dae版本更新，及时获取问题修复

总结

这个案例展示了网络工具中DNS处理的复杂性，特别是在涉及不同协议(UDP/TCP)和加密场景下的挑战。通过深入分析BPF处理逻辑和网络接口绑定机制，开发团队最终找到了有效的解决方案，为用户提供了更稳定的DNS解析体验。