/tags/dns/ Recent content in dns 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 都在第二段做同一件事：基于延迟、健康状态、地理位置或端点可用性，让不同用户解析到不同答案。 /posts/cilium-gateway-argocd-dns-recovery/ Sun, 08 Mar 2026 18:30:00 +0800 /posts/cilium-gateway-argocd-dns-recovery/ 背景 这次故障一开始看起来像两个互不相干的问题： ArgoCD 里 gateway Application 一直是 Degraded 其他几个 Application 又出现了 OutOfSync 或者后续的 Unknown 如果只看表面，很容易把它归类成“Cilium Gateway API 有问题”或者“ArgoCD 状态异常”。 但真正麻烦的地方在于，这次故障不是单点失效，而是一条跨层级的链路问题： ArgoCD 健康状态异常 -> 先看到 Gateway Degraded -> 再发现 repo-server 拉 Git 也失败 -> 往下追到 CoreDNS 外部解析异常 -> 再继续追到 ZITADEL 根本没有把 backend Service 建出来 -> 最后发现 Vault 里的 ZITADEL master key 长度也不对 也就是说，最上层暴露出来的是 Gateway 和 ArgoCD，真正的根因却横跨了： Cilium Gateway API ArgoCD repo-server CoreDNS systemd-resolved Vault + External Secrets ZITADEL Helm 安装链路 这篇文章就按我实际排查的顺序，把整个问题怎么拆开、怎么验证、最后怎么收敛讲清楚。