DNS 基础回顾：解析流程、记录类型与缓存机制
在 GitOps 同步窗口内，DNS 故障是导致部署中断、流量异常、证书校验失败的常见根因。要设计自动化容错与回滚策略，首先必须理解 DNS 的核心工作原理。本节从解析流程、记录类型、TTL 与缓存三个维度进行回顾，为后续故障注入与恢复演练奠定理论基础。
2.1 DNS 解析流程
DNS 解析本质是一个分布式键值查询过程，客户端通过递归或迭代方式向各级 DNS 服务器发起查询，最终获得目标域名对应的 IP 地址或其他资源记录。完整流程涉及以下角色：
| 角色 | 功能 | 典型组件 |
|---|---|---|
| 客户端（Stub Resolver） | 发起域名查询请求，通常由操作系统或应用库实现 | glibc nsswitch、getaddrinfo() |
| 递归解析器（Recursive Resolver） | 代替客户端完成完整递归查询，缓存结果 | CoreDNS、Unbound、公共 DNS（8.8.8.8） |
| 根域名服务器 | 返回顶级域（TLD）的权威服务器地址 | 13 组根服务器（a.root-servers.net） |
| 顶级域服务器（TLD） | 返回二级域（如 example.com）的权威服务器地址 | .com / .org / .cn 等 TLD 运营方 |
| 权威服务器（Authoritative） | 持有域名实际资源记录，返回最终答案 | Route53、CloudDNS、BIND |
GitOps 视角： 在 Kubernetes 集群中，CoreDNS 通常作为集群内递归解析器。当外部权威 DNS 故障时，CoreDNS 缓存过期会导致 Service 域名解析失败，进而引发 Pod 启动超时或流量中断。
下图展示了标准递归解析流程，从客户端到权威服务器的完整查询链路：
2.2 DNS 记录类型
DNS 记录类型决定了域名与资源之间的映射关系。在 GitOps 场景中，最常涉及的记录类型包括：
| 记录类型 | 用途 | 示例 | GitOps 关联场景 |
|---|---|---|---|
| A | 域名 → IPv4 地址 | app.example.com → 192.0.2.10 |
Ingress/Service 对外暴露 |
| AAAA | 域名 → IPv6 地址 | app.example.com → 2001:db8::10 |
双栈集群流量入口 |
| CNAME | 域名 → 另一个域名（别名） | www.example.com → example.com |
CDN 域名映射、蓝绿切换 |
| NS | 指定域名的权威服务器 | example.com → ns1.dns.com |
DNS 托管变更、故障转移 |
| SOA | 区域权威信息（刷新/重试/过期） | example.com → 主服务器+邮箱 |
区域传输、故障检测 |
| TXT | 文本信息（验证/SPF/DKIM） | _acme-challenge → 证书验证值 |
Let's Encrypt 证书签发 |
常见陷阱： CNAME 记录不能与同名的其他记录类型（如 A/AAAA/MX）共存。在 GitOps 自动同步中，如果同时配置了 CNAME 和 A 记录，权威服务器会返回冲突错误，导致解析失败。
2.3 TTL 与缓存机制
TTL（Time To Live）是 DNS 记录在递归解析器或客户端缓存中的存活时间，单位秒。TTL 直接影响故障切换速度和流量收敛时间。
2.3.1 缓存层级
- 客户端缓存： 操作系统或应用层（如浏览器、curl）缓存，通常遵循 TTL 但可被本地配置覆盖。
- 递归解析器缓存： 公共 DNS（8.8.8.8）或集群内 CoreDNS 缓存，TTL 到期后重新查询权威。
- 权威服务器： 不缓存自身记录，但 SOA 中的
negative caching TTL控制 NXDOMAIN 响应的缓存时长。
2.3.2 TTL 策略对比
| TTL 值 | 典型场景 | 优势 | 风险 |
|---|---|---|---|
| 30~60 秒 | 故障转移、蓝绿发布、流量切换 | 快速收敛，变更秒级生效 | 查询压力增大，权威负载高 |
| 300~600 秒 | 生产稳定服务、CDN 源站 | 缓存命中率高，延迟低 | 故障时切换慢，最长 10 分钟 |
| 86400 秒（1 天） | 静态资源、不常变动的域名 | 极低查询量 | 变更后需等待 24 小时生效 |
GitOps 最佳实践： 在同步窗口内执行 DNS 变更前，先将 TTL 临时降低至 60 秒（称为“TTL 预热”），待变更确认稳定后再恢复至常规值。此策略可将故障回滚时间从数十分钟缩短至 1~2 分钟。
2.3.3 缓存失效与负缓存
当权威服务器返回 NXDOMAIN（域名不存在）或 SERVFAIL（服务器故障）时，递归解析器会根据 SOA 记录中的 minimum TTL 字段缓存该负面结果，默认通常为 300~900 秒。这意味着：
- 即使权威服务器在 30 秒后恢复，客户端仍可能持续收到“域名不存在”错误。
- 在 GitOps 自动回滚中，必须考虑负缓存过期时间，否则回滚后的 DNS 记录无法被客户端感知。
下图对比了正向缓存与负缓存的失效路径差异：
2.4 本章小结
- DNS 解析流程涉及客户端、递归解析器、根/TLD/权威服务器，任何环节故障都会导致解析失败。
- A/AAAA/CNAME 是 GitOps 流量管理最常用的记录类型，CNAME 与同名列冲突是常见配置错误。
- TTL 控制缓存时长，低 TTL 加速故障切换但增加查询负载；负缓存 TTL 是回滚后感知延迟的主要瓶颈。
- 在同步窗口内执行 DNS 变更前，建议先降低 TTL 预热，并监控负缓存过期时间。