2. DNS 基础回顾：层级结构、解析流程与常见记录类型
在深入排查证书轮换引发的域名解析故障之前，必须牢固掌握 DNS 的核心工作机制。DNS（Domain Name System）本质上是一个分布式、层次化的键值数据库，负责将人类可读的域名（如 api.example.com）转换为机器可用的 IP 地址。本章将系统梳理 DNS 的层级结构、递归与迭代解析流程，以及最常见的资源记录类型，为后续故障定位打下坚实基础。
2.1 DNS 层级结构：从根到叶子
DNS 命名空间采用树形结构，从根域（Root）向下逐级委派。每个节点代表一个域名，每个层级由独立的权威服务器管理。这种分层设计实现了全球范围内的可扩展性与管理自治。
api.example.com 失败时，首先要判断故障发生在哪个层级。例如，根域和 TLD 通常由公共递归服务器（如 8.8.8.8）处理，而二级域和子域可能由企业内部 DNS 或云服务商托管。证书轮换通常只影响子域或主机记录层级的权威响应。
2.2 解析流程：递归与迭代
DNS 解析分为两种模式：递归查询和迭代查询。实际解析过程通常是两者的组合：客户端向本地递归解析器发起递归查询，递归解析器再向各级权威服务器发起迭代查询。
2.2.1 递归查询
客户端（如 Pod 中的 glibc 解析器）将解析任务完全交给本地递归解析器（如 CoreDNS、systemd-resolved、运营商 DNS）。递归解析器负责完成整个查询链，并将最终结果返回给客户端。客户端只需等待一个完整响应。
2.2.2 迭代查询
递归解析器向根服务器查询，根服务器返回顶级域（TLD）服务器的地址；递归解析器再向 TLD 服务器查询，TLD 返回二级域权威服务器的地址；依此类推，直到找到包含目标记录的权威服务器。每一步，服务器只返回“下一步该问谁”，而不直接给出最终答案。
/etc/resolv.conf 通常将 nameserver 指向集群 DNS 服务（如 CoreDNS 的 ClusterIP）。如果 CoreDNS 本身无法完成递归查询（例如上游 DNS 不可达或缓存了错误记录），即使权威服务器配置正确，Pod 也会解析失败。证书轮换后，务必同时检查权威侧和递归侧。
2.3 常见 DNS 记录类型
不同的记录类型服务于不同的解析场景。在证书轮换相关的故障中，A/AAAA 和 CNAME 记录是最常涉及的。SRV 记录在服务发现场景（如 Kubernetes 内部 Headless Service）中也很关键。
| 记录类型 | 全称 | 作用 | 典型示例 | 与证书轮换的关联 |
|---|---|---|---|---|
| A | Address Record | 将域名映射到 IPv4 地址 | api.example.com → 192.0.2.10 |
证书绑定 IP 或域名，A 记录指向错误 IP 会导致 TLS 握手失败 |
| AAAA | IPv6 Address Record | 将域名映射到 IPv6 地址 | api.example.com → 2001:db8::10 |
双栈环境中，AAAA 记录缺失或错误可能导致 IPv6 优先的客户端连接失败 |
| CNAME | Canonical Name Record | 将域名别名指向另一个域名 | www.example.com → example.com |
证书轮换时，CNAME 链中的任何节点解析失败都会导致最终目标不可达 |
| SRV | Service Record | 指定服务所在的主机名和端口 | _sip._tcp.example.com → 0 10 5060 sipserver.example.com |
Kubernetes 内部服务发现依赖 SRV；证书轮换后 SRV 记录未更新会导致服务路由错误 |
2.3.1 A/AAAA 记录：最直接的映射
A 和 AAAA 记录是 DNS 系统中最基础的类型。当客户端请求 api.example.com 时，权威服务器返回对应的 IP 地址。证书轮换后，如果后端服务器的 IP 发生变化（例如负载均衡器重建），但 DNS 记录未同步更新，客户端将连接到错误的 IP，导致证书域名不匹配。
2.3.2 CNAME 记录：别名的陷阱
CNAME 记录将查询重定向到另一个域名。例如，api.example.com 可能是 lb-123456.elb.amazonaws.com 的 CNAME。证书轮换时，如果 CNAME 目标域名对应的 A/AAAA 记录过期，或者 CNAME 链中存在循环，解析将失败。此外，CNAME 记录不能与其他记录类型共存于同一节点名，否则会导致解析冲突。
2.3.3 SRV 记录：服务发现的关键
SRV 记录在 Kubernetes 中用于 Headless Service 的 DNS 发现。格式为 _service._proto.name，包含优先级、权重、端口和目标主机。证书轮换后，如果后端 Pod 被替换，SRV 记录中的目标主机名可能指向已终止的 Pod，导致连接被拒绝。
_grpc._tcp.svc.cluster.local 的 SRV 记录返回了旧 Pod 的 IP。客户端使用该 IP 建立 gRPC 连接时，服务端已轮换证书，但旧 Pod 上的证书已过期，导致 TLS 握手失败。排查时发现 SRV 记录的 TTL 设置为 600 秒，而 Pod 重建后 DNS 缓存未及时刷新。
2.4 本章小结
- 层级结构决定了故障隔离的边界：根/TLD 问题影响全局，子域/主机记录问题影响局部。
- 递归与迭代流程中，递归解析器（如 CoreDNS）是集群内的关键节点，其缓存策略和上游配置直接影响解析成功率。
- A/AAAA/CNAME/SRV 记录在证书轮换场景下各有不同的故障模式：IP 变更、别名链断裂、服务端点过期。
- 后续章节将基于这些基础，深入分析证书轮换如何具体影响 DNS 解析，以及如何通过
dig、nslookup和 CoreDNS 日志进行定位。