锐捷路由器DNS缓存翻车实录：一次因TTL设置不当引发的全网‘断网’与排查修复
锐捷路由器DNS缓存故障全记录：一次TTL配置失误引发的连锁反应
那天早上8:15，我刚端起咖啡，运维群里的消息就开始疯狂刷屏。"企业微信能发消息但打不开网页"、"OA系统时好时坏"、"部分外网资源完全无法访问"...作为网络负责人，我立刻意识到这不是普通的网络波动。放下咖啡杯，一场持续36小时的DNS排障马拉松就此开始。
1. 故障现象与初步判断
故障最初表现为间歇性的网页访问异常。市场部的同事反映，他们能正常使用企业微信沟通，但访问客户官网时频繁出现"无法连接服务器"的提示。财务部的报障更诡异——上午9点前能正常使用网银系统，9:30后突然无法登录，而其他部门却可以。
通过抓包分析，我们发现了几个关键特征：
- 受影响域名具有随机性，无固定规律
- 故障表现为DNS查询超时而非连接拒绝
nslookup直接查询上游DNS结果正常- 路由器CPU和内存占用均在正常范围
提示：当出现部分网站可访问而部分不可访问时，应优先排查DNS而非网络连通性问题
我们使用的锐捷RG-RSR77-X核心路由器部署了DNS Proxy功能，基础配置如下：
# 当前DNS Proxy配置 dns proxy enable dns proxy listen-interface Vlan100 ip dns server-address 114.114.114.114 ip dns server-address 8.8.8.8 dns proxy cache-size 10000 dns proxy cache-ttl 86400 # 24小时缓存2. 深度排查过程
2.1 缓存状态分析
执行show dns proxy cache命令后，发现了异常情况：
| 域名 | 解析IP | 缓存剩余时间 | 首次缓存时间 |
|---|---|---|---|
| www.bank.example | 192.0.2.1 | 12h34m | 昨日18:23 |
| api.oa.example | 203.0.113.5 | 8h12m | 今日01:45 |
| cdn.static.example | 198.51.100.3 | 23h59m | 昨日00:01 |
对比权威DNS查询结果：
- www.bank.example 实际已更新为192.0.2.2
- api.oa.example 实际IP应为203.0.113.7
- cdn.static.example 记录正确
2.2 TTL机制验证
我们设计了验证实验：
- 清理特定域名缓存：
clear dns proxy cache name www.bank.example - 立即发起查询并抓包
- 观察缓存更新行为
实验结果：
- 清理后首次查询走完整DNS解析流程
- 新记录仍按配置的86400秒TTL缓存
- 期间域名实际TTL仅为300秒（5分钟）
2.3 上游DNS健康检查
排除了上游服务器问题：
# 测试上游DNS响应 for server in 114.114.114.114 8.8.8.8; do dig @$server www.bank.example +short ping -c 4 $server done所有上游服务器均响应正常，平均延迟<50ms。
3. 故障根源定位
经过上述排查，确认问题核心在于：
- TTL配置冲突：路由器强制覆盖了域名的原始TTL（300秒→86400秒）
- 缓存更新失效：即使原始记录变更，客户端仍获取陈旧缓存
- 无失效机制：缓存记录不会主动验证有效性
这种配置在以下场景会引发问题：
- CDN节点切换
- 灾备IP切换
- 云服务弹性扩缩容
- 业务服务器迁移
4. 解决方案与优化措施
4.1 紧急修复方案
立即调整缓存策略：
configure terminal no dns proxy cache-ttl 86400 dns proxy cache-ttl 300 # 对齐主流CDN的TTL设置 end write memory并执行缓存清理：
clear dns proxy cache *4.2 长期优化方案
- 动态TTL策略：
dns proxy cache-ttl min 60 max 3600- 缓存验证机制：
dns proxy cache-verify enable dns proxy cache-verify-interval 1800- 监控告警系统：
# 示例：DNS缓存健康检查脚本 import datetime from ruijie_sdk import RouterAPI router = RouterAPI('10.0.100.1') cache = router.get_dns_cache() alert_domains = [] for entry in cache: if entry['ttl'] > 3600 and 'bank' in entry['domain']: alert_domains.append(entry['domain']) if alert_domains: send_alert(f"长TTL缓存告警: {', '.join(alert_domains)}")4.3 配置最佳实践
根据实际运维经验，推荐配置参数：
| 参数项 | 推荐值 | 说明 |
|---|---|---|
| cache-size | 5000-20000 | 根据用户规模调整 |
| cache-ttl | min 60, max 1800 | 不强制覆盖原始TTL |
| cache-verify-interval | 900 | 每15分钟验证热点记录 |
| max-retries | 3 | 上游查询重试次数 |
| timeout | 2000 | 查询超时时间(ms) |
5. 故障预防体系
我们后续建立了三层防护机制：
变更管理：
- DNS配置变更需双人复核
- 重大变更前执行影响评估
监控体系：
- 实时监控缓存命中率
- 关键域名TTL异常告警
- 上游DNS健康状态检测
应急方案：
- 自动化缓存清理脚本
- 备用DNS服务切换流程
- 客户端DNS缓存刷新指南
这次事故让我们深刻认识到，即使是看似简单的DNS缓存，配置不当也会造成全网级故障。现在我们的运维手册新增了一条铁律：任何强制覆盖TTL的配置必须经过架构师审批。