[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fI5A65QW8t9SZQbCpi3DECzWIhpIac3J5RWW95U-GnFQ":3},{"item":4,"related":40},{"id":5,"type":6,"title":7,"slug":8,"summary":9,"body":10,"coverUrl":11,"productScreenshots":12,"productLinks":13,"authorName":14,"authorUrl":15,"authorSubject":16,"category":17,"tags":22,"sourceLabel":31,"sourceName":32,"sourceUrl":32,"status":33,"seoTitle":32,"seoDescription":32,"canonicalUrl":32,"isFeatured":34,"sno":35,"sortOrder":36,"publishedAt":37,"updatedAt":38,"createdAt":39},"1ac7c91d-cac3-44c2-a137-c8aa8079c6a1","article","DNS 缓存：为什么改了域名却不能立即生效","dns-cache-ttl-propagation-explained","DNS 解析不是一次查询，而是浏览器、操作系统、递归解析器和权威服务器共同完成的缓存链路。本文解释 TTL、递归与权威、A\u002FAAAA\u002FCNAME、迁移节奏，以及 DNSSEC 能解决和不能解决的问题。","“我已经把域名指向新服务器了，为什么有人能打开新站，有人还在访问旧站？”这不是 DNS 修改失败，而是 DNS 的缓存机制正在按各自的计时器工作。DNS 记录带有 TTL（Time To Live），递归解析器可以在这段时间内复用旧答案；RFC 1034 把 TTL 定义为资源记录在缓存中可以保留的时间。[RFC 1034](https:\u002F\u002Fwww.rfc-editor.org\u002Finfo\u002Frfc1034\u002F)\n\nDNS 不是“改一个中心表格，全世界立即刷新”。它更像一套分层的分布式目录：权威服务器保存源数据，递归解析器代替大量客户端查询并缓存结果，操作系统和浏览器还可能保留更近一层的缓存。\n\n## 从域名到 IP，查询经过哪些人\n\n当浏览器访问 `www.example.com`，客户端通常不会直接询问根服务器。一个简化过程是：\n\n1. 浏览器和操作系统先检查本地缓存。\n2. Stub Resolver 把请求交给配置好的递归解析器。\n3. 递归解析器若没有可用缓存，先问根服务器“`.com` 在哪”。\n4. 再问 `.com` 顶级域服务器“`example.com` 的权威服务器在哪”。\n5. 最后问 `example.com` 的权威服务器“`www` 的 A 或 AAAA 记录是什么”。\n6. 递归解析器缓存结果，并把答案返回给客户端。\n\n```mermaid\nflowchart TD\n    A[浏览器访问域名] --> B[浏览器 \u002F 操作系统缓存]\n    B -->|未命中| C[递归解析器]\n    C -->|未命中| D[根服务器]\n    D --> E[顶级域服务器]\n    E --> F[权威 DNS 服务器]\n    F --> G[A \u002F AAAA \u002F CNAME 等记录]\n    G --> C\n    C --> H[缓存并返回客户端]\n```\n\n实际系统还会处理 CNAME 链、IPv4 与 IPv6 双栈、DNSSEC、负面缓存和超时重试。图里的层级是帮助理解的骨架，不代表每次查询都必须完整走一遍。\n\n## TTL 不是“全世界刷新时间”\n\n假设一条 A 记录的 TTL 是 300 秒。一个递归解析器在 12:00 查询到旧 IP 后，通常可以把它缓存到 12:05 左右。另一个解析器可能在 12:02 才首次查询，于是它的缓存会保留到 12:07。不同解析器的查询时间不同，就会出现用户在不同网络看到不同结果。\n\nTTL 还不一定决定所有本地缓存行为。操作系统、浏览器、应用内 DNS 缓存、CDN 和中间网络设备都可能有自己的策略。TTL 是缓存资源记录的重要依据，但不是一个能精确控制所有客户端的遥控器。\n\n## 为什么迁移前要提前降低 TTL\n\n域名迁移常见做法是提前把旧记录的 TTL 降低，等待旧的长缓存自然过期，再切换到新 IP。切换后保留旧服务器一段时间，让仍持有旧答案的客户端继续得到服务；等观察窗口过去，再下线旧站。\n\n降低 TTL 不能追溯性地清除已经缓存的旧记录。如果一条记录昨天的 TTL 是 86400 秒，今天才改成 300 秒，昨天已经拿到旧值的解析器仍可能继续使用旧值，直到原来的缓存周期结束。\n\n```text\n迁移前：降低 TTL → 等旧缓存逐渐过期\n切换时：修改权威记录 → 新查询获得新地址\n观察期：新旧服务器同时可用 → 监控错误与流量\n收尾：确认旧缓存基本消退 → 下线旧服务\n```\n\n## A、AAAA、CNAME 有什么区别\n\n- `A` 记录把名称指向 IPv4 地址。\n- `AAAA` 记录把名称指向 IPv6 地址。\n- `CNAME` 记录把一个名称指向另一个名称，解析器还要继续解析目标名称。\n\n使用 CNAME 能让多个服务共享一个目标，但会增加解析链和故障排查复杂度。根域、CDN、邮件和证书验证还可能受到不同记录类型与服务商限制，不能只记住“域名就是一个 IP”。\n\n## DNSSEC 能解决什么\n\nDNSSEC 通过签名验证 DNS 数据来源和完整性，帮助客户端判断答案是否被篡改。但 DNSSEC 不会让缓存更快失效，也不会把旧的合法记录变成新的合法记录。它解决的是“这个答案是否经过权威签名验证”，不是“这个答案是不是最新”。\n\n## 一份迁移与排查清单\n\n- 先确认修改的是权威 DNS，而不是只改了本地 hosts 文件。\n- 同时检查 A、AAAA、CNAME 和 CDN 配置。\n- 用多个递归解析器查询，比较它们的 TTL 剩余时间。\n- 保留旧服务，直到旧缓存和长尾客户端明显下降。\n- 修改 DNS 后不要立刻把所有问题归因于 DNS，TLS、缓存、CDN 和应用路由也可能指向旧目标。\n\n## 一句话带走\n\nDNS 的“传播慢”本质上是分布式缓存按不同时间开始、不同时间过期。理解权威服务器、递归解析器和 TTL 三层关系，就能把“玄学等待”变成可观测的迁移流程。\n\n## 延伸阅读\n\n- [RFC 1034：Domain Names—Concepts and Facilities](https:\u002F\u002Fwww.rfc-editor.org\u002Finfo\u002Frfc1034\u002F)\n- [DNS 层级结构图](https:\u002F\u002Fcommons.wikimedia.org\u002Fwiki\u002FFile:DNS_schema.svg)","\u002Fuploads\u002F2026-08-09\u002Fb7da716c-c1d0-4f6b-a443-dee46124973d.jpg",[],[],"Foundit","https:\u002F\u002Ffoundit.cn","f39339b1-aaa6-4e86-b0c2-a6e6a21113b5",{"id":18,"name":19,"slug":20,"description":21},"6179d3b6-dc34-4483-9ded-3cd9f1b37a47","科普","abbreviation","介绍各领域新兴概念",[23,27],{"id":24,"name":25,"slug":26},"4c2bbea6-eab7-40a8-8447-1de478ff7749","分析","analyse",{"id":28,"name":29,"slug":30},"7c76bfc2-f80f-4ee0-a95d-27bd8708b434","技术","slug","资料来源",null,"published",false,65,0,"2026-08-09T00:00:00.000Z","2026-08-09T12:47:02.204Z","2026-08-09T12:13:32.284Z",[41,50,58],{"id":42,"type":6,"title":43,"slug":44,"summary":45,"coverUrl":46,"authorName":14,"sno":47,"publishedAt":48,"createdAt":49},"d6ff32b0-f499-453a-b1e3-c31a4a7a5b16","布隆过滤器：系统如何快速判断一个东西肯定不存在","bloom-filter-probabilistic-membership-explained","布隆过滤器用位数组和多个哈希函数，以极少内存快速筛掉肯定不存在的对象。本文讲清误报与漏报、误报率、删除难题，以及它在缓存、数据库和去重系统中的正确用法。","\u002Fuploads\u002F2026-08-06\u002F234915f6-2ef2-4820-8523-1a98544732f9.jpg",61,"2026-08-06T00:00:00.000Z","2026-08-06T05:38:25.381Z",{"id":51,"type":6,"title":52,"slug":53,"summary":54,"coverUrl":55,"authorName":14,"sno":56,"publishedAt":48,"createdAt":57},"a04c10a4-3fe8-4537-81bd-354103c1078f","WebGPU：浏览器为什么能跑 3D、滤镜和部分 AI","webgpu-browser-gpu-computing-explained","WebGPU 让网页能更直接地使用 GPU 做渲染与通用计算。本文从 CPU 与 GPU 的分工讲起，拆解适配器、设备、缓冲区、WGSL 着色器和命令队列，并说明什么时候并行计算真的值得。","\u002Fuploads\u002F2026-08-06\u002F05f26f06-cda2-4ed3-b1f2-5f26c82c2a37.jpg",62,"2026-08-06T05:38:22.834Z",{"id":59,"type":6,"title":60,"slug":61,"summary":62,"coverUrl":63,"authorName":14,"sno":56,"publishedAt":48,"createdAt":64},"23cd6a50-6716-4620-99f3-d5307511c8ee","CRDT：两个人同时改同一段文字，为什么不会互相覆盖","crdt-collaborative-editing-explained","CRDT 允许多个副本先本地修改，再通过可合并的数据结构最终收敛。本文用计数器和协同编辑讲清 CvRDT、CmRDT、并发插入、删除标记、元数据成本与业务语义冲突。","\u002Fuploads\u002F2026-08-06\u002F50641649-08d8-4cac-94f0-647eabe9fc5f.jpg","2026-08-06T05:38:23.928Z"]