--- id: "dns-propagation" kind: "glossary-term" title: "DNS传播" language: "zh-Hans" category: "DNS与技术基础" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/zh/cihui/dns-chuanbo/" translations: en: "https://tldlog.com/glossary/dns-propagation/" es: "https://tldlog.com/es/glosario/propagacion-dns/" de: "https://tldlog.com/de/glossar/dns-propagation/" fr: "https://tldlog.com/fr/glossaire/propagation-dns/" it: "https://tldlog.com/it/glossario/propagazione-dns/" pt-BR: "https://tldlog.com/pt/glossario/propagacao-dns/" ru: "https://tldlog.com/ru/glossariy/rasprostranenie-dns/" --- # DNS传播 对DNS变更被所有人看到之前那段延迟的非正式说法。实际上并没有什么在互联网上“传播”：解析器只是保留旧应答，直到所存副本过期。等待时间取决于记录的TTL；如果更换的是域名服务器，还取决于顶级域自身的设置。 当某个域名的DNS设置发生变更时，例如迁移网站或改用新的域名服务器，并非所有用户都能同时看到变化。在一段时间内，有些人访问的是旧配置，另一些人访问的是新配置。这段等待就是人们所说的DNS传播。 ## 人们所说的DNS传播是什么意思 “传播”（propagation）是一个非正式的说法。它暗示变更会在互联网上向外扩散，但实际上并没有任何内容被推送出去。解析器，即为用户查询域名的服务器，会保存已收到的应答副本，并在其过期之前重复使用，过期后才会重新查询。IETF的DNS术语文件RFC 9499中没有“propagation”这一词条。 这一说法通常涵盖两类变更： - 对域名自身区域中某条记录的变更，例如新增一条A记录，将该域名指向新的网页服务器。 - 域名服务器的变更。这类变更在注册服务机构处进行，由其提交给注册管理机构；注册管理机构随后在顶级域区域中发布新的委派。 ## 变更为何不能立即生效：缓存与TTL 主要的缓存位于互联网服务提供商、企业和公共服务所运营的递归解析器中。手机或计算机上的存根解析器通常依赖其中之一。 每条DNS记录都带有一个TTL（生存时间）：由区域运营方设定的秒数，表示副本可以保存多久。缓存副本会倒计时，归零时副本即被丢弃，下一次查询会重新获取该记录。TTL为0表示该记录不得被缓存。 TTL是上限，而非承诺。解析器可能会限制过长的TTL（RFC 8767建议上限为七天），许多解析器即使在TTL更低时也会将应答保存至少数十秒。最重要的是，任何人都无法删除他人解析器中的缓存副本。这才是需要等待的真正原因。 ## 实际需要多长时间，以及如何在变更前缩短等待 不存在统一的通用数字：所需时间取决于相关的TTL。 对于记录变更，旧应答在解析器中最多可保留该记录旧TTL的时长，从该解析器最后一次获取该记录时算起。如果TTL为3,600，解析器在变更后最多一小时内仍可能返回旧应答。 对于域名服务器变更，有三段延迟叠加： 1. 注册服务机构将变更发送给注册管理机构。 2. 注册管理机构在顶级域区域中发布变更。截至2026年10月，对于适用ICANN基本注册管理机构协议（2024年1月21日版本）的通用顶级域，服务水平要求是在至少95%的ICANN测试探针中达到60分钟。这一数字不适用于拥有各自协议的传统通用顶级域（如.com），也不适用于ccTLD。 3. 缓存的NS记录过期。顶级域区域保存着该域名NS记录的自有副本，其TTL是域名持有人无法更改的。 缩短等待的标准做法早在1987年就已在RFC 1034中说明：提前降低TTL，至少提前一个完整的旧TTL周期，然后进行变更，再将TTL调回。对于.es区域，Red.es建议正常情况下SOA的TTL和Minimum值为3,600秒，在重大变更前可临时降至900秒（15分钟）（截至2026年10月）。降低自己的TTL并不能缩短顶级域中NS记录副本的保存时间。 ## 否定缓存：新域名为何可能一直显示“不存在” 解析器也会记住某个名称不存在。如果有人在某个域名的记录创建之前就查询它，解析器可能缓存一个NXDOMAIN应答（该名称不存在）或NODATA应答（该名称存在，但没有该类型的记录）。 否定应答的保存时间取区域SOA记录中两个值的较小者：SOA记录自身的TTL和其Minimum字段。按Red.es的正常值3,600和3,600计算（截至2026年10月），最长为一小时。RFC 2308建议解析器默认将否定缓存限制在一到三小时。 实践中的经验是：在测试或公布新域名之前先创建记录。过早测试可能使该域名在整个否定缓存期间都显示为不存在。 ## 如何检查变更是否可见 - 直接查询该域名的权威服务器。它们根据区域数据作答，而不是来自缓存。 - 然后查询一个或多个递归解析器。如果它们仍返回旧数据，其显示的TTL就是重新查询前的剩余时间。 - 对于域名服务器变更，检查顶级域的服务器是否返回新的NS记录。ICANN的更新时间衡量的正是这一节点。 ## 规划无停机迁移 1. 先设置新的托管服务或域名服务器，并确认新服务器已能为该域名正确地作出权威应答。Red.es对.es域名推荐这样做。 2. 按上文所述提前降低TTL。 3. 进行变更：编辑记录，或通过注册服务机构更换域名服务器。对于.es，委派变更需按既定程序向Red.es申请。 4. 让旧服务器或旧托管服务继续以正确数据运行，时间至少为顶级域TTL和域名自身TTL中较长的一个。 5. 核实无误后，再将TTL调回。 示例（数值仅作说明）：example.com有一条A记录，TTL为86,400秒（一天）。迁移网站前两天，持有人将TTL降至900。旧的一天TTL过去后，持有人更改A记录，约15分钟内，遵守TTL的解析器就会获得新地址。 ## 来源 - [Domain names - concepts and facilities (RFC 1034)](https://www.rfc-editor.org/rfc/rfc1034.txt) - [Negative Caching of DNS Queries (DNS NCACHE) (RFC 2308)](https://www.rfc-editor.org/rfc/rfc2308.txt) - [Considerations for Large Authoritative DNS Server Operators (RFC 9199)](https://www.rfc-editor.org/rfc/rfc9199.txt) - [Registry Agreement (ICANN base gTLD Registry Agreement, version of 21 January 2024), Specification 10](https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-21-01-2024-en.html) - [Guía informativa DNS, Versión 1.1 (dominios.es, Red.es)](https://www.dominios.es/sites/dominios/files/2026-02/dns-guia-informativa-y-requisitos-de-configuracion.pdf) ## 相关术语 - [DNS缓存](https://tldlog.com/zh/cihui/dns-huancun/) - [TTL](https://tldlog.com/zh/cihui/ttl/) - [解析器](https://tldlog.com/zh/cihui/jiexiqi/) - [NS记录](https://tldlog.com/zh/cihui/ns-jilu/) - [否定缓存](https://tldlog.com/zh/cihui/fouding-huancun/)