2. DNS基础回顾：DNS解析流程、A记录/CNAME记录/TXT记录、TTL与缓存机制
DNS（Domain Name System）是互联网的电话簿，将人类可读的域名（如 api.example.com）转换为机器可读的IP地址。在GitOps同步窗口设计中，DNS的解析路径、记录类型和缓存行为直接决定了故障切换的生效速度和回滚的可靠性。本节从SRE视角梳理DNS核心机制，为后续的故障回滚设计奠定基础。
2.1 DNS解析流程：从浏览器到权威服务器
一次完整的DNS解析涉及多个层级，每个层级都可能引入缓存或故障点。以下流程图展示了典型递归解析路径：
SRE要点：在GitOps故障回滚场景中，权威DNS服务器是变更的“源点”，而递归解析器和客户端缓存是“延迟放大器”。理解这一路径有助于设计合理的TTL策略和同步窗口。
2.2 核心记录类型：A、CNAME、TXT
DNS记录类型定义了域名与资源之间的映射关系。在GitOps自动化容错设计中，以下三种记录最为关键：
| 记录类型 | 作用 | 典型值 | GitOps场景用途 |
|---|---|---|---|
| A记录 | 将域名直接映射到IPv4地址 | 192.0.2.1 |
服务入口的IP切换，故障时直接指向备用集群 |
| CNAME记录 | 将域名别名指向另一个域名（规范名） | app.example.com → lb-prod.example.com |
抽象负载均衡器域名，切换时只需修改CNAME目标 |
| TXT记录 | 存储任意文本数据，常用于验证和策略 | "v=spf1 include:_spf.google.com ~all" |
GitOps状态标记、ACME验证、故障策略标识 |
实战对比：A记录 vs CNAME
- A记录：直接、无额外解析开销，但IP变更需要修改所有相关记录。
- CNAME：增加一次额外解析（CNAME目标需再查A记录），但提供抽象层——切换时只需修改CNAME指向，适合蓝绿部署和金丝雀发布。
- 限制：CNAME不能与其它记录类型共存于同一节点（RFC 2181），且不能用于根域（如
example.com本身）。
2.3 TTL与缓存机制：故障切换的时间窗口
TTL（Time To Live）是DNS记录在缓存中的存活时间，单位秒。它直接决定了DNS变更的传播延迟，是GitOps同步窗口设计的核心参数。
2.4 TTL策略对比与选择
不同TTL值在故障切换速度和系统稳定性之间做出权衡。以下是常见策略：
| TTL值 | 典型场景 | 故障切换速度 | DNS查询负载 | 风险 |
|---|---|---|---|---|
| 30-60秒 | 高频变更、故障演练、蓝绿切换 | 极快（1分钟内） | 高 | 递归解析器压力大，可能被限流 |
| 300秒（5分钟） | 生产环境常规服务 | 中等（5-10分钟） | 中等 | 切换窗口可接受，缓存命中率良好 |
| 3600秒（1小时） | 稳定服务、CDN源站 | 慢（1-2小时） | 低 | 故障时影响范围大，回滚延迟高 |
| 86400秒（1天） | 静态资源、不常变动的记录 | 极慢（1-2天） | 极低 | 不适合需要快速故障切换的场景 |
⚠️ 常见陷阱：许多团队在故障发生后临时降低TTL，但旧TTL仍在缓存中生效，无法立即加速切换。正确的做法是：在变更前提前降低TTL（至少2×旧TTL时间），等待缓存刷新后再执行切换。GitOps同步窗口应内置这一预热阶段。
2.5 缓存层级与故障回滚影响
DNS缓存不仅存在于递归解析器，还分布在多个层级。每个层级都可能延长故障回滚的生效时间：
- 浏览器缓存：Chrome默认缓存60秒（可通过
chrome://net-internals/#dns查看），Firefox默认缓存60秒。 - 操作系统缓存：Linux的
nscd或systemd-resolved，Windows的DNS Client服务，TTL通常遵循记录值但可配置最小上限。 - 递归解析器缓存：公共DNS（如8.8.8.8、1.1.1.1）严格遵循TTL，但可能设置最小TTL下限（如Google Public DNS最小30秒）。
- 中间代理/CDN缓存：部分CDN节点可能忽略TTL或设置自定义缓存策略，需额外注意。
GitOps回滚设计建议：
- 将权威DNS记录的TTL设置为 60-300秒，平衡切换速度与缓存压力。
- 在同步窗口中加入 TTL预热阶段：变更前先降低TTL，等待至少2×旧TTL时间。
- 使用 TXT记录 携带GitOps状态元数据（如
gitops-commit-sha、rollback-strategy），便于自动化工具验证当前生效版本。 - 监控DNS解析延迟和缓存命中率，作为同步窗口健康度的指标。