/tags/high-availability/ Recent content in high-availability on Hugo -- gohugo.io en Tue, 31 Mar 2026 10:00:00 +0800 /posts/cdn-dns-survivability/ Tue, 31 Mar 2026 10:00:00 +0800 /posts/cdn-dns-survivability/ 一场“DNS 挂了”的事故，是怎么把 CDN 一起拖下水的 如果你经历过一次真实的 DNS 故障，就会发现它的表象非常有迷惑性：源站明明还活着，负载均衡也没全部坏，甚至某些地区的用户还能短暂打开页面，但外界感受到的却像是“整个网站突然消失了”。 这里最容易产生的误解是：CDN 在前面，所以只要 CDN 健康，网站就应该继续可用。 但很多情况下并非如此。对绝大多数网站来说，DNS 不是一张静态电话簿，而是把用户请求导向某个 CDN 边缘入口的控制平面。DNS 出问题，用户甚至拿不到“该连哪个边缘节点”的答案，于是 CDN、源站和负载均衡会一起表现成不可达。RFC 1034 和 RFC 1035 对 DNS 的权威数据模型做了最基础的定义，NIST SP 800-81r3 则直接把 DNS 基础设施视为网络架构里的关键依赖。 这篇文章就从这个灾难视角出发：先解释 CDN 和 DNS 到底是怎么配合工作的，再推演几类最常见的失效路径，最后收束到“怎样让网站在 DNS 级事故里争取更强韧性”的设计原则。 CDN 和 DNS 是怎么配合工作的？ 当用户在浏览器里输入一个域名时，请求并不会直接飞到某个 CDN 边缘节点，而是先经过本地 stub resolver，再进入递归解析器，然后由递归解析器去查询权威 DNS。RFC 1034 与 RFC 1035 定义了这条查询链路的基本角色和数据结构。 接入 CDN 的常见做法是：域名所有者把自己的记录通过 CNAME 指向 CDN 提供的入口域，或者直接把 NS 记录委托给 CDN 的权威 DNS。这样会出现两段解析：第一段由域名所有者的权威 DNS 返回 CNAME 或直接委托；第二段由 CDN 的 authoritative DNS 根据实时策略返回当前最合适的边缘入口。Amazon Route 53 的 latency-based routing 和 Cloudflare 的 traffic steering 都在第二段做同一件事：基于延迟、健康状态、地理位置或端点可用性，让不同用户解析到不同答案。