缓存、TTL 和 DNS 问题

每次查找都查询完整的 DNS 层次结构，速度会很慢，也会使服务器负载过高。缓存会保存最近的响应，因此重复查找可以立即完成。

解析器、操作系统，甚至浏览器都会保存 DNS 缓存。缓存让 DNS 能够在每天数十亿次查询的规模下保持快速和可扩展。

每条 DNS 记录都带有一个 TTL（生存时间），这是一个以秒为单位的数值，用于告诉缓存答案在过期前可以保存多久。

TTL 为 3600 的记录可以缓存一小时。TTL 到期后，缓存会丢弃该条目，下次必须重新查找。

TTL 是一种权衡。长 TTL意味着查找次数更少、响应更快，但更改需要更长时间才能传播。短 TTL可以让更改快速传播，但会增加查询负载。

管理员通常会在计划迁移前降低 TTL，使新地址快速传播，然后在迁移完成后再次提高 TTL。

更新 DNS 记录后，更改不会立即出现在所有地方。世界各地的缓存仍会保存旧值，直到各自的 TTL 到期。

这种延迟称为传播。根据之前的 TTL，更改可能需要几分钟到几小时才能在全球范围内生效——这也是编辑记录后经常令人困惑的原因。

常见的 DNS 问题是过期缓存：设备在实际地址已经更改后，仍继续使用旧的缓存 IP。此时记录本身是正确的，但网站看起来却无法访问。

解决方法是等待 TTL 到期，或刷新缓存。在许多系统中，您可以手动清除缓存，立即强制执行新的查找。

过期条目导致问题时，刷新缓存会强制设备丢弃缓存的记录并重新查询。这是排查问题时常用的早期步骤。

不同系统有各自的刷新命令。刷新后，下一次查找会从解析器获取最新结果，并读取最近的记录更改。

如果设备指向无法访问或配置错误的解析器，即使网络正常，名称解析也会完全失败。检查已配置的 DNS 服务器是关键的诊断步骤。

切换到已知正常的公共解析器（例如 8.8.8.8 或 1.1.1.1），可以快速测试原解析器是否存在问题。

在查询 DNS 之前，大多数系统都会检查本地的主机文件，该文件可以手动将名称映射到地址。文件中的条目会覆盖该名称的 DNS 结果。

遗忘的或恶意的主机条目可能会将名称悄悄重定向到错误的 IP。因此，当只有某个特定名称出现异常而其他名称都能正常解析时，检查主机文件是明智的做法。

DNS 故障的典型迹象包括：通过 IP 可以加载网站，但通过名称无法加载；出现“找不到服务器”错误；或初始连接速度很慢。

如果对 IP 执行 ping 成功，但对名称执行 ping 时因未知主机错误而失败，那么问题很可能出在 DNS。这项快速测试可以将 DNS 问题与其他连接问题区分开来。

使用 nslookup 或 dig 直接查询 DNS。您可以指定服务器、检查返回的是哪条记录，并查看剩余的 TTL。

这些工具可以让您将解析器返回的结果与权威答案进行比较，从而发现过期缓存或源站配置错误的记录。

大多数 DNS 问题都可以追溯到缓存和 TTL 行为、错误的解析器或不正确的记录。按照结构化步骤进行检查——通过 IP 测试、验证解析器、刷新缓存、使用 nslookup 查询——即可定位原因。理解 TTL 和传播机制，有助于解释更改为何会延迟生效。

这为 Network+ 考试所必需的地址和名称基础知识补上了最后一环。

解读一个 TTL 场景。

您已经学习了缓存、TTL 和 DNS 问题。

• 缓存保存最近的答案，使 DNS 保持快速。
• TTL规定记录在刷新前可以缓存多长时间。
• 长 TTL = 查找次数更少但更改较慢；短 TTL = 更改更快但负载更高。
• 传播延迟和过期缓存会导致许多 DNS 问题；刷新缓存有助于解决这些问题。
• 可以通过基于 IP 的测试、解析器检查和 nslookup 进行诊断。