从 A 记录到 CDN 切换：我的 DNS 认知跃迁之路

前言

最近在实际工作中涉及 DNS 解析、CDN 配置和流量调度的场景，让我对 DNS 的理解经历了几次显著的"认知跃迁"。从最初以为"DNS 只是把域名转成 IP"，到后来理解了 A 记录、CNAME、权威 DNS、递归 DNS、CDN 回源、hosts 测试等一系列概念之间的关联，我发现 DNS 远没有想象中那么简单。

这篇文章不是为了系统地讲解 DNS 协议，而是记录我理解层级的跃迁过程，希望能帮助正在经历同样困惑的读者少走弯路。

第一阶段：DNS 不就是"电话簿"吗？

初学阶段，我对 DNS 的理解停留在最基础的层面：

DNS 就是把域名解析成 IP 地址，浏览器拿着 IP 去访问服务器。

知道有 A 记录（IPv4）、AAAA 记录（IPv6）、CNAME（别名），也知道一个域名可以对应多个 A 记录做负载均衡，同一个 IP 也可以对应多个域名做虚拟主机。

但这个阶段的认知有两个严重缺陷：

我只知道"有这些记录类型"，但不知道它们在什么场景下用、为什么这么用。
我把"域名→IP"的映射理解成一个静态的、一对一的关系。

第二阶段：多 A 记录 vs 虚拟主机 ------ 分层的本质

当我开始深入理解 A 记录和虚拟主机的区别时，第一次认知跃迁发生了：

场景	技术实现层级	解决什么问题
一个域名 → 多个 A 记录	DNS 层	流量分散、基础容灾（找哪台机器）
同一个 IP → 多个域名	Web 服务器层（Nginx/Apache）	多租户、资源共享（找哪个服务）

关键认知： DNS 只负责"找到机器"，而"路由到哪个服务"是 Web 服务器的事情。两者职责清晰，互不干扰。

延伸理解： 多 A 记录的 DNS 轮询虽然简单，但存在致命缺陷------不感知服务器健康状态、客户端强缓存导致负载不均。因此现代高并发架构中，它正逐渐被 Nginx 反向代理或硬件负载均衡器的"单一 VIP"模式取代。

第三阶段：CDN 切换前的 hosts 测试 ------ 到底在测什么？

接触 CDN 后，我遇到了一个看似简单但细思极恐的问题：

CDN 切换前为什么要改 hosts 测试？到底在测什么？

这个问题的答案层层递进：

第一层理解： 通过 hosts 强制指定 IP，绕过 DNS 缓存，提前验证新 CDN 节点是否可用。

第二层理解： hosts 测试实际上是制造了一个"假的 DNS 解析"，骗过操作系统，在不修改全球 DNS 的情况下，抢先访问新 CDN 节点。

第三层理解（关键跃迁）： hosts 中绑定的 IP 绝不是源站 VIP ，也不是 CDN 的公网生产 VIP，而必须是 CDN 厂商提供的测试节点 VIP/边缘节点 IP。

为什么？

绑源站 VIP → 彻底绕过 CDN，直接打源站 → 根本没有测试 CDN 配置！
绑 CDN 公网生产 VIP → 配置可能滞后，IP 可能动态变化，测试结果不可靠。
绑 CDN 测试专属 VIP → 配置抢先生效、流量隔离、安全可控 → 这才是正确的做法。

这个认知跃迁的核心是： 我明白了 CDN 的"测试节点"和"生产节点"是两套完全独立的环境，hosts 测试的本质是在隔离环境中验证新配置，而非验证源站是否正常。

第四阶段：权威 DNS、递归 DNS、缓存 ------ 谁在真正回答？

当我开始排查 CDN 切换后的生效延迟问题时，第四次认知跃迁发生了：

用户拿到的 DNS 解析结果，真的是从权威 DNS 实时查到的吗？

真相： 绝大多数情况下不是。用户电脑直接打交道的是本地递归 DNS（如 ISP 的 DNS 或 114.114.114.114），而递归 DNS 会缓存解析结果。在 TTL 过期之前，它根本不会去问权威 DNS。

链路拆解：

text

复制代码

浏览器 → 操作系统缓存 → 本地递归DNS → [缓存命中] → 直接返回
                                    → [缓存未命中] → 根域 → 顶级域 → 权威DNS

关键认知： 权威 DNS 只是逻辑上的"最终源头"，但实际返回给用户的是递归 DNS 的缓存结果。这也是为什么修改 DNS 记录后，需要等待 TTL 过期才能全球生效。

额外收获： 还存在 hosts 文件（最高优先级）和浏览器本地缓存，它们比递归 DNS 更靠近用户，也更容易导致问题定位时的"假象"。

第五阶段：有 CDN vs 无 CDN ------ 链路对比中的本质差异

结合实际的 CDN 流量链路和无 CDN 场景，我画出了两条完整的路径：

有 CDN 的链路

text

复制代码

用户 → DNS解析（CNAME链 → CDN边缘节点IP）
     → CDN边缘节点
     → 缓存命中？是 → 直接返回
                否 → 回源DNS解析 → F5 VIP → Nginx

无 CDN 的链路

text

复制代码

用户 → DNS解析（权威DNS直接返回A记录 → 源站机房公网IP）
     → 互联网路由
     → 机房防火墙/DDoS清洗
     → F5/LVS VIP
     → Nginx → 后端应用

对比后的核心差异：

环节	有 CDN	无 CDN
DNS 解析结果	CNAME 链 → CDN 边缘节点 IP	A 记录 → 源站公网 VIP
中间缓存层	CDN 边缘节点	无（Nginx 本地缓存属于内部）
回源概念	有（边缘节点→源站）	无（用户直达源站）

关键认知： 无 CDN 时，源站 VIP 直接暴露在公网上，每一次请求都消耗机房带宽和连接数，源站成了第一道也是最后一道防线 。这也是为什么几乎所有的互联网业务都必须上 CDN------不是为了加速，首先是为了"保命"（扛流量洪峰、隐藏源站 IP）。

第六阶段（最终跃迁）：A 记录 vs CNAME ------ DNS 的"终点"与"路标"

这是我最核心的认知跃迁，源于一个问题：

在有 CDN 和无 CDN 的场景中，权威 DNS 之前的查询流程是一样的吗？

答案是：完全相同。真正的分水岭发生在权威 DNS 返回记录的那一瞬间。

text

复制代码

用户查询 test.example.com
        ↓
（无论有无 CDN，查询路径完全一样）
        ↓
浏览器缓存 → hosts → 递归DNS → 根域 → .com顶级域 → example.com权威DNS
        ↓
        ═══ 分水岭 ═══
        ↓
  权威DNS返回什么？
        ↓
┌───────┴───────┐
↓               ↓
A记录           CNAME
（无CDN）       （有CDN）
↓               ↓
直接返回IP      返回别名域名
↓               ↓
流量直冲源站    触发二次DNS查询
                ↓
            CDN厂商权威DNS
            （GSLB就近调度）
                ↓
            返回最近边缘节点IP

这个认知跃迁的本质是：

A 记录是"终点"------告诉你去哪，解析到此结束。
CNAME 是"路标"------告诉你去问谁，触发新一轮查询。

正是这个区别，让 CDN 能够实现就近调度、故障剔除、流量清洗，也解释了为什么 CDN 切换时必须经历 CNAME 链的逐级生效，而不是像修改 A 记录那样"感觉上"更快。

总结：我的 DNS 认知演进路线图

阶段	核心问题	认知跃迁
初学	DNS 是干什么的？	域名 → IP 的电话簿
深入	多 A 记录和虚拟主机有什么区别？	DNS 层 vs Web 服务器层，职责分离
CDN 测试	hosts 测试到底在测什么？	测试节点 VIP ≠ 源站 VIP ≠ 生产 VIP
生效延迟	用户拿到的是权威 DNS 的结果吗？	递归 DNS + 多层缓存才是"直接回答者"
链路对比	有 CDN 和无 CDN 的链路差异在哪？	有无缓存层、有无回源概念、源站是否暴露
终极理解	权威 DNS 返回 A 还是 CNAME？	A=终点，CNAME=路标，决定后续一切

写在最后

DNS 看起来是一个"老掉牙"的基础协议，但在现代互联网架构中，它依然是流量调度的第一环。无论你用的是 AWS 的 Route 53、阿里云的 DNS，还是自建的 BIND，理解权威、递归、缓存、CNAME 链、TTL这些概念之间的关联，远比记住几条命令重要。

如果你也在经历类似的困惑，希望这篇文章能帮你少走弯路。