# DNS 查询超时问题分析与修复计划

## 问题现状
- 客户端请求 DNS 解析需要两次才能成功
- 第一次返回 SERVFAIL，第二次才有正确结果
- 错误数量高达 29,594 条

## 已尝试的修复
- 将 `queryTimeout` 从 5ms 修改为 5000ms
- 服务器已重启

## 需要深入调查的问题

### 1. 超时配置的实际生效情况
- 检查配置文件中 queryTimeout 的单位（毫秒还是秒）
- 验证代码中如何解析和使用这个配置值
- 确认配置是否真正被重新加载

### 2. 上游 DNS 服务器可达性
- 测试上游 DNS 服务器 (10.35.10.200, 106.14.121.141) 是否可达
- 检查上游服务器的响应时间
- 验证上游服务器是否支持递归查询

### 3. 网络层面问题
- 检查是否有防火墙规则阻止 DNS 查询
- 验证 UDP 53 端口是否畅通
- 检查是否存在网络延迟或丢包

### 4. DNS 缓存逻辑问题
- 检查缓存是否正常工作
- 验证缓存 TTL 设置是否合理
- 确认缓存命中时是否还会超时

### 5. 代码逻辑问题
- 检查并行查询模式的实现
- 验证超时处理逻辑是否正确
- 查看是否有竞态条件导致的问题

## 调查步骤

### 第一步：检查当前配置和日志
1. 查看当前配置文件中的 queryTimeout 值
2. 检查最新日志中的超时设置
3. 统计错误日志中的错误类型分布

### 第二步：测试上游 DNS 服务器
1. 直接测试上游 DNS 服务器的响应
2. 测量到上游服务器的网络延迟
3. 验证上游服务器是否工作正常

### 第三步：分析代码中的超时处理
1. 查看 forwardDNSRequestWithCache 函数中的超时逻辑
2. 检查 dns.Client 的 Timeout 设置
3. 验证并行查询的超时处理

### 第四步：检查网络配置
1. 检查防火墙规则
2. 测试 DNS 端口连通性
3. 检查路由表和网络接口

## 可能的修复方案

### 方案 A：修复配置单位问题
如果配置单位是秒而不是毫秒，需要将 5000 改为 5

### 方案 B：修复上游服务器配置
如果上游服务器不可达，需要更换可用的 DNS 服务器

### 方案 C：修复代码中的超时逻辑
如果代码中存在超时处理 bug，需要修改相关代码

### 方案 D：优化查询模式
如果并行查询模式有问题，可以切换到 fastest-ip 模式

## 验证标准
1. DNS 查询一次成功，不需要重试
2. 错误率降低到接近 0
3. 平均响应时间合理（<100ms）
4. 日志中不再有大量 SERVFAIL 记录