你给博客换了服务器在管理后台把域名指向新 IP。自己刷新页面看到的却还是旧网站朋友那边已经正常手机切到移动网络后也正常。为什么同一个域名会在不同设备上得到不同结果要解释这件事不能只把 DNS 理解成一本“域名对应 IP 的电话簿”。它是一套分层管理、分散查询、允许缓存的系统。下面跟着一次查询走完再回头看博客换服务器的问题。浏览器准备访问https://www.example.com/articles/network需要查询地址的是其中的www.example.com。https决定如何访问/articles/network表示网站里的资源路径都不属于这次地址查询的域名。DNS 通常也不知道你想读哪篇文章。它先帮助浏览器找到可以连接的地址之后才轮到 TCP、TLS 和 HTTP。设备发起网络查询前可能已经在浏览器或系统缓存里找到可用结果。不同系统、浏览器的处理细节不完全相同下面先假设缓存里没有答案需要向外查询。设备首先联系的通常是递归解析器。你在网络配置里看到的“DNS 服务器”往往就是它的地址也可能是负责转发查询的家用路由器。这个地址可以由 DHCP 提供或由用户、系统、浏览器另行配置。所以电脑不必先查域名才能找到第一个 DNS 服务器它通常已经知道可以把查询发往哪个 IP。你可以把这次请求读成请帮我查出www.example.com的 IPv4 地址查完把结果交给我。递归解析器收到请求后也会先查自己的缓存。它服务的可能不止你一台设备别的用户刚查过相同记录你就可能直接用上缓存结果。假设它也没有相关缓存才需要沿着 DNS 的层级继续寻找。域名从右往左看能看出管理层级www.example.com. │ └─ 根最后这个点平时常省略 └─── com顶级域 example.com一个具体域名 www.example.com这个域名下的名称这里要分清两个角色递归解析器负责替你查权威 DNS 服务器负责提供自己管理范围内的正式记录。在这个简化例子里递归解析器会经历三轮问路问根服务器。根服务器给出负责.com的服务器线索。问.com的服务器。它给出负责example.com的权威服务器线索。问example.com的权威服务器。如果www.example.com的地址记录由它管理它就返回相应记录。注意是递归解析器拿到线索后继续发问。根服务器一般不会替你一路查到网站再把最终 IP 送回来。设备向递归解析器提出的是“请帮我查到结果”的请求解析器沿途进行的查询则可能得到“去问这些服务器”的转介。课本里说的递归查询与迭代查询可以先从这个区别理解。DNS 的基本查询模型见 RFC 1034。实际查询不一定每次走完三层。只要缓存里还留着可用的答案或中途线索解析器就能少走几步。域名也可能继续委派给其他权威服务器这里先保留最常见的主干。查到的“答案”究竟长什么样DNS 保存的是一条条有类型的记录。你问某个名称的 IPv4 地址通常查询A 记录问 IPv6 地址则查询AAAA 记录。同一个名称可以有不同类型的记录它们回答不同问题记录类型表达的内容A这个名称对应的 IPv4 地址AAAA这个名称对应的 IPv6 地址CNAME这个名称是另一个名称的别名NS哪些服务器负责相应 DNS 区域MX这个域名接收邮件时使用哪些邮件服务器TXT文本信息常用于域名验证、邮件策略等因此“查不到 A 记录”不等于“域名不存在”。它可能有其他记录只是没有你正在查询的这一种。CNAME 也值得单独说一下。假设博客配置成blog.example.com → site.hosting.example这条别名记录本身没有给出 IP。解析过程还需要继续查目标名称的地址。浏览器的网址也不会因为收到 CNAME就自动变成右边那个名字DNS 别名与网页跳转是两回事。一个名称还可能返回多个地址。大型网站可以根据解析器位置、服务部署和调度策略给出不同结果。两个人查到的 IP 不同单凭这一点还不能断定谁的 DNS 出错了。查完之后为什么要缓存如果每次打开博客都从根服务器开始问一遍访问会变慢DNS 系统也会承受大量重复查询。于是解析器会把可缓存的记录暂时保留下来。记录中的TTL用来告诉缓存这份记录通常可以保存多久单位是秒。这里的 TTL 与第五篇 IP 数据包中的 TTL 含义不同DNS TTL 管缓存时间IP TTL 限制数据包的转发寿命。相关定义见 DNS 术语规范 RFC 9499。假设博客原来的记录是blog.example.com → 旧服务器地址 TTL 3600 秒某个解析器在 10:00 缓存了它。你在 10:10 把权威服务器上的记录改成新地址这个解析器并不一定立刻得知变化它手里的旧记录仍可能在剩余有效时间内被使用。另一个解析器恰好没有旧缓存10:11 去查询时就可能拿到新地址。于是同一个博客出现了“我这里还是旧的他那里已经新的”。这也说明域名修改后所谓的“生效”通常不能理解为有一条更新消息正在逐台推送给全世界。权威记录更新了各处旧缓存还需要陆续到期。准备迁移博客时如果希望缩短切换期间旧缓存的影响可以提前降低相关记录的 TTL并等原来的较长缓存周期过去再修改地址。切换当天才降低 TTL不会自动缩短别人已经缓存的旧记录剩余时间。甚至“这个名字不存在”的结果也可以被缓存。刚创建一个此前查不到的名称时短时间内仍有人得到不存在的回答可能与这种否定缓存有关。这一机制由 RFC 2308 说明。现在可以在自己的电脑上看一次真实查询了。Windows 打开命令提示符输入nslookup -typeA example.com先观察输出的两部分。开头的Server、Address通常表示你正在询问的 DNS 服务器后面的名称和地址才是被查询域名的结果。第一次使用这个命令很容易把两者看反。如果看到“非权威应答”通常表示回答你的这台服务器不是该名称的权威来源。它可能从缓存中回答也可能刚替你完成查询。这几个字本身不表示答案不可信。再分别运行nslookup -typeAAAA example.com nslookup -typeNS example.com第一条查询 IPv6 地址第二条查看这个域名的 NS 记录。记录内容可能变化以你实际看到的结果为准。如果想找 TTL可以查看更详细的输出nslookup -debug -typeA example.com找到相应回答记录里的ttl。连续查询时你可能看到它下降也可能由于缓存刷新、不同后端等原因看到不同变化不必要求每次结果完全一样。遇到失败时先分清失败的种类结果通常说明什么NXDOMAIN不存在的域DNS 回答这个名称不存在SERVFAIL解析过程失败原因可能在服务器、验证或其他环节超时在等待期限内没有收到可用回应查询成功但没有该类型记录名称可能存在只是没有这类记录不要把后三种情况一律解释为“域名写错了”。命令用法及错误说明可参考微软的 nslookup 文档。还有一个排查时很有用的边界nslookup成功不保证浏览器正在使用同一个查询结果。浏览器可能有自己的缓存也可能启用了独立的加密 DNS 服务。浏览器仍打不开网站时需要确认它实际使用的解析方式而不是只反复运行同一条命令。即便浏览器拿到了正确 IP后面还有连接、TLS 和 HTTP 等步骤。DNS 完成的是地址查询不会替网站检查证书是否有效、服务是否启动、文章是否存在。今天的练习做到这里可以在纸上留下四项你询问的 DNS 服务器、查询的名称、记录类型、返回结果。下次博客换服务器时再分别比较权威记录和递归查询结果你就有了判断旧地址从哪里来的依据。下一篇我们终于可以读一读浏览器与网站真正交换的内容一条 HTTP 请求里写了什么服务器又怎样用状态码、响应头和正文回答它。