Unbound DNS解析器中serve-expired配置的安全隐患与最佳实践

背景与问题发现

在DNS解析器Unbound中，serve-expired功能允许在记录过期后继续提供缓存响应。然而，当该功能启用时，默认配置serve-expired-ttl=0会导致无限期提供过期记录，这违反了安全默认原则。这一设计缺陷可能导致严重的安全问题：用户可能被重定向到已变更的IP地址，特别是在云服务动态分配IP的环境下。

技术分析

默认配置的风险

• 无限期缓存：serve-expired-ttl=0意味着过期记录可被永久使用
• 与RFC 8767的差异：RFC建议在提供过期数据前应尝试刷新，而Unbound默认直接返回过期数据
• 实际案例影响：用户可能访问到已重新分配的云资源，导致隐私数据泄露风险

相关RFC规范

RFC 8767对过期记录服务提出了明确要求：

1. 在提供过期数据前应尝试刷新
2. 建议设置1-3天的最大过期服务时间
3. 客户端超时建议值为1.8秒（低于典型客户端重试阈值）

解决方案与改进建议

配置优化方案

1. 安全默认值：

   • serve-expired-client-timeout=1800（遵循RFC建议）
   • serve-expired-ttl=86400（1天，取RFC建议范围下限）

2. 高级配置建议：

   serve-expired: yes
   serve-expired-ttl: 86400  # 最大1天
   serve-expired-client-timeout: 1800  # 1.8秒
   

3. 替代方案：

   • 禁用serve-expired，改用prefetch功能
   • 在受控环境中才考虑启用过期记录服务

实现改进建议

1. 动态TTL适配：可考虑实现基于原始TTL百分比的过期服务时间（如原始TTL的180%）
2. 性能监控：利用unbound-control的recursion.time指标优化超时设置
3. 安全警告：在文档中明确标注启用此功能的风险

最佳实践总结

1. 生产环境建议：

   • 若非必要，应保持serve-expired=no
   • 必须启用时，务必设置合理的TTL限制
   • 云服务应设置较短的原始TTL（如60秒）

2. 容器部署注意：

   • 检查Docker镜像的默认配置
   • 避免使用未经安全审核的配置模板

3. 监控与调优：

   • 定期检查解析延迟指标
   • 根据实际网络条件调整客户端超时值

通过合理配置和风险意识，可以在保持服务可用性的同时，有效降低DNS缓存带来的安全风险。