DNS 传播

Q: DNS 传播 是什么？

DNS更改在全球所有DNS服务器上传播所需的时间。

DNS传播是什么？

DNS传播是指DNS记录更改在整个Internet上被识别所需的时间。当您更新DNS记录(更改名称服务器、更新A记录、修改MX记录)时，更改不会立即生效——它们必须通过分层DNS系统传播，因为缓存过期并刷新。

理解"传播"

术语"传播"有些误导——DNS更改不会主动"传播"或传播。相反：

1. 您更新记录在您的权威名称服务器

2. 缓存副本过期基于TTL(生存时间)

3. 新查询从权威服务器获取更新的记录

4. 旧的缓存副本继续服务直到TTL过期

说"DNS缓存过期"比"传播"更准确，但术语传播被广泛使用。

DNS更改的工作原理

更新过程

步骤1：更新DNS记录 example.com A记录：203.0.113.50 → 203.0.113.51 步骤2：权威名称服务器立即提供新记录步骤3：现有缓存副本仍有效直到TTL过期步骤4：TTL过期后新查询接收更新的记录步骤5：所有缓存最终过期并刷新

→ "传播完成"

时间表示例

时间：10:00 - DNS已更新(TTL：300秒/5分钟) 解析器A(在09:58缓存)： 09:58 - 缓存旧IP，在10:03到期 10:03 - 缓存过期，重新查询，获得新IP 解析器B(在10:01缓存)： 10:01 - 缓存旧IP，在10:06到期 10:06 - 缓存过期，重新查询，获得新IP 解析器C(在10:05查询)： 10:05 - 无缓存，立即查询，获得新IP 所有解析器在以下时间前有新IP：10:06

传播时间：6分钟(基于TTL的最坏情况)

影响传播时间的因素

TTL(生存时间)

最重要的单一因素：

TTL值	传播时间	使用场景
60秒	1-2分钟	活跃迁移，负载均衡
300秒(5分钟)	5-10分钟	生产更改，合理的默认值
3600秒(1小时)	1-2小时	稳定基础设施
86400秒(24小时)	24-48小时	很少更改的记录

名称服务器更改

更改名称服务器需要更长时间：

注册表级别：24-48小时(TLD名称服务器缓存) 解析器级别：基于NS记录TTL

总时间：最坏情况下48小时

ISP和解析器行为

并非所有DNS解析器都尊重TTL值：

行为良好的解析器：Google(8.8.8.8)、Cloudflare(1.1.1.1)、OpenDNS

严格遵守TTL
快速传播

有问题的解析器：某些ISP

可能忽略低TTL值
缓存时间长于指定
可将传播延迟数小时

地理分布

不同地区根据本地解析器缓存在不同时间更新：

北美：10:05 - 已更新欧洲：10:08 - 已更新

亚洲：10:12 - 已更新

客户端缓存

即使DNS服务器更新后，本地缓存也可能保留旧值：

浏览器缓存：通常为60秒
操作系统缓存：数分钟到数小时
应用缓存：因应用而异

检查DNS传播

在线传播检查器

whatsmydns.net：显示来自全球20多个位置的DNS解析 dnschecker.org：检查A、AAAA、CNAME、MX、TXT记录的全球分布 DomScan健康检查:

curl "https://domscan.net/v1/health?domain=example.com"

# 显示当前DNS配置

命令行检查

检查多个解析器:

# Google DNS dig @8.8.8.8 example.com # Cloudflare DNS dig @1.1.1.1 example.com # 您的ISP(未指定@服务器) dig example.com

# 比较结果

直接查询权威名称服务器:

# 查找名称服务器 dig example.com NS # 直接查询权威NS

dig @ns1.example.com example.com

这显示"事实"——无缓存涉及。

从多个位置检查

# 使用DNS over HTTPS

curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

最小化传播时间

更改前

步骤1：降低TTL(更改前24-48小时)

旧：example.com. 3600 IN A 203.0.113.50 新：example.com. 300 IN A 203.0.113.50 ^^^

减少到5分钟

步骤2：等待旧TTL过期

等待旧TTL的完整持续时间(3600秒 = 1小时)

步骤3：进行DNS更改

example.com.    300    IN    A    203.0.113.51

步骤4：监控传播

全球检查解析器

步骤5：恢复TTL(确认成功后)

example.com.    3600    IN    A    203.0.113.51

更改期间

使用任播DNS：Cloudflare等提供商使用任播网络，在其全球网络上近乎即时更新 持续监控：跟踪关键地区和解析器的传播 制定回滚计划：直到传播完成，保持旧基础设施运行

常见传播场景

更改A记录

预期时间：5-30分钟(基于TTL)

# 之前 example.com → 203.0.113.50 # 之后 example.com → 203.0.113.51

# 传播：1x TTL持续时间

更改MX记录

预期时间：5-30分钟(基于TTL) 风险：传播期间电子邮件可能传递到旧服务器缓解：在传播完成后的24-48小时内保持旧邮件服务器活跃

更改名称服务器

预期时间：24-48小时

原因是什么？
TLD注册表缓存NS记录
注册表TTL通常为24-48小时
无法控制注册表缓存

最佳实践：在切换前在新名称服务器处配置所有记录

添加新子域

预期时间：立即到1小时问题：负面缓存

如果之前查询了子域但不存在： → NXDOMAIN被缓存(SOA最小TTL)

→ 新子域在缓存过期前无法解析

缓解：在添加新记录前降低SOA最小TTL

排除传播问题

更改未传播

检查1：验证权威名称服务器

dig @ns1.example.com example.com

# 应显示新值

检查2：验证TTL

dig example.com | grep -i ttl

检查3：检查SOA以获取负面缓存

dig example.com SOA

# 查看最小TTL字段

检查4：清空本地缓存

清除浏览器、操作系统和应用程序缓存

部分传播

症状：某些用户看到新记录，其他用户看到旧记录原因：不同的解析器在不同时间缓存 解决方案：等待最大TTL持续时间，然后清空客户端缓存

传播卡住

症状：几天后，某些解析器仍提供旧记录原因：ISP解析器忽略TTL或配置错误 解决方案：

1. 验证权威名称服务器正确

2. 如持续，请联系ISP

3. 用户可切换到公共DNS(8.8.8.8、1.1.1.1)

DNS传播与缓存TTL

概念	它是什么	持续时间
TTL	记录可被缓存多长时间	由域所有者设置
传播	所有缓存过期所需的时间	大约TTL的2倍
名称服务器TTL	NS记录缓存多长时间	通常为24-48小时(注册表)
负面缓存	NXDOMAIN缓存多长时间	SOA最小TTL

最佳实践

1. 更改前降低TTL：在DNS更新前24-48小时降低TTL

2. 使用适当的TTL：平衡性能(高TTL)与灵活性(低TTL)

3. 全球监控：从多个地理区域检查DNS

4. 保持旧服务运行：在传播完成前维护以前的服务器

5. 记录更改：跟踪更改内容和时间以进行故障排除

6. 彻底测试：在切换前验证新DNS记录有效

7. 与用户沟通：警告可能的短暂中断

8. 使用托管DNS：具有任播网络的提供商最大程度地减少传播时间

9. 自动化监控：为DNS更改和传播状态设置警报

10. 制定回滚计划：知道如何在出现问题时恢复更改

传播清单

☐ 在更改前24-48小时降低TTL ☐ 等待旧TTL过期 ☐ 进行DNS更改 ☐ 在权威名称服务器上验证 ☐ 检查多个公共解析器 ☐ 从多个地理位置测试 ☐ 监控2x TTL持续时间 ☐ 验证未报告任何错误 ☐ 如需要，恢复更高的TTL

☐ 记录更改完成

DNS传播是DNS缓存的自然结果——理解TTL行为并相应地计划更改可确保平稳、可预测的更新，中断最少。