CoreDNS中rewrite cname插件与缓存交互导致的截断响应问题分析

问题背景

在DNS解析过程中，当响应数据包过大时，服务器会设置TC(Truncated)标志位，表示响应被截断，客户端应改用TCP协议重新查询以获取完整响应。CoreDNS作为一款高性能DNS服务器，在处理这类场景时出现了一个值得关注的行为异常。

问题现象

当CoreDNS同时启用cache插件和rewrite cname指令时，在特定条件下会返回不完整的DNS记录集。具体表现为：

1. 当内部查询生成CNAME记录时，rewrite cname会触发对CNAME目标的递归查询
2. 上游服务器返回的UDP响应因数据量过大被截断(TC标志置位)
3. CoreDNS将包含CNAME和部分记录的截断响应返回给客户端
4. 客户端收到TC标志后改用TCP重试查询
5. 此时CoreDNS错误地从缓存中返回之前不完整的记录集，而非通过TCP获取完整响应

技术分析

这个问题涉及CoreDNS多个插件的交互逻辑：

1. rewrite cname插件：负责处理CNAME重写逻辑，当发现CNAME记录时会发起后续查询
2. cache插件：缓存DNS响应以提高性能
3. forward插件：处理向上游服务器的查询转发

问题的核心在于缓存插件对截断响应的处理逻辑不够完善。当收到上游的截断响应时，CoreDNS应该：

1. 不缓存截断的响应
2. 在客户端改用TCP重试时，应绕过缓存直接向上游发起TCP查询
3. 只缓存完整的最终响应

影响范围

该问题会影响以下使用场景：

1. 使用rewrite cname插件进行CNAME重定向
2. 同时启用了缓存功能
3. 查询的目标记录集较大，可能触发UDP响应截断
4. 客户端支持TCP回退机制

解决方案

修复方案应着重于：

1. 修改缓存逻辑，避免缓存截断响应
2. 在TCP重试路径中绕过缓存查询
3. 确保最终只缓存完整的记录集

对于用户而言，临时解决方案可以是：

1. 暂时禁用rewrite cname功能
2. 或调整缓存设置，减少缓存时间
3. 或配置上游服务器使用TCP协议

最佳实践建议

为避免类似问题，建议在CoreDNS配置中：

1. 对于可能返回大量记录的查询，考虑增加EDNS0缓冲区大小
2. 监控DNS响应中的TC标志出现频率
3. 定期检查CoreDNS版本并更新到包含修复的版本
4. 在关键业务场景中考虑强制使用TCP协议

总结

这个问题展示了DNS协议中UDP/TCP交互的复杂性，特别是在插件化架构中多个组件协同工作时可能出现的行为异常。理解这类问题有助于我们更好地设计和使用DNS基础设施，确保域名解析的完整性和可靠性。