地址栏敲下回车之后：一次 DNS 解析的接力赛——DNS域名解析详解
一次 DNS 解析的完整“接力赛”
引言
你打开浏览器，在地址栏输入 www.example.com，按下回车。屏幕闪了一下，页面就出来了。
整个过程安静得让人察觉不到。在这不到一秒里，你的电脑先问了问自己“我认识这个域名吗”，又去系统里翻小抄，实在没答案，才把问题一路问到了运营商的机房、问到了全球的根域名服务器，最后从域名的“管家”那里拿到一个 IP 地址。随后，TCP 握手、TLS 握手、HTTP 请求依次发生，页面才开始渲染。
这一连串动作里，DNS 解析只是第一棒，却也是最容易被忽略的一棒。因为建立 TCP 连接需要 IP 地址，应用层在发起连接之前，就必须先完成这次“名字到地址”的翻译。
我们平时记住的是好记的网站域名，可网络设备之间只认 IP 地址——就像快递员只认门牌号，不认“张三”“李四”。于是，必须有一个东西负责把名字翻译成地址。这个东西就是 DNS（Domain Name System，域名系统）。
但 DNS 并不是一台“什么都知道”的服务器。恰好相反，它是一个高度分布式的系统：根服务器只知道 .com、.cn 这些顶级域该找谁，顶级域服务器只知道 example.com 这个域该找谁，真正掌握 www.example.com 对应哪个 IP 的，是域名自己的权威服务器。每一级只回答“下一跳去哪问”，像一场接力赛。
看到这里，你可能已经有点蒙圈了。不过没关系，下面我会把这场“接力赛”里你可能有的疑问一一解答，让你对 DNS 解析了解得足够透彻。
所以，这场“接力赛”到底是怎么跑起来的呢？
解答的问题
- 为什么打开网页前必须先做一次 DNS 解析？除了浏览器，还有哪些地方会触发它？
- 浏览器、操作系统、
hosts文件——一次解析会先查哪里？它们各自记着什么？ - 如果本机都没有答案，递归解析器为什么要先问根、再问
.com、最后问权威？它们各自知道什么、又不知道什么？ - 解析结果最后会被谁记住？为什么下一次查询可能不用再跑一遍全程？
一、为什么打开网页前必须先做一次 DNS 解析？
引言里，我们把 DNS 比作这场接力赛的第一棒。可有没有想过：凭什么第一棒必须是它？TCP 握手、TLS 握手、HTTP 请求，哪个不能先跑？
TCP 只认 IP，不认名字
答案藏在互联网的一条死规矩里：设备之间通信，只认 IP 地址，不认域名。
你记得住 www.example.com 这种好念的名字，但 TCP 连接不认字。当程序调用 connect() 去连接服务器时，参数里必须填 IP 和端口——就像寄快递时，快递单上必须写门牌号，“张三家的那栋楼”这种描述，快递员是送不到的。域名是给人看的，IP 是给机器用的，这两套语言之间必须有人翻译。
DNS 就是负责翻译的那个角色，也可以把它理解成互联网的“114 查号台”：你报名字，它给号码。只不过这个查号台并不是一个总机，而是一群分工明确的分台——这些我们下一节再细说。
所以流程其实很简单：
应用拿着域名 → 先问 DNS“这名字对应的 IP 是多少” → 拿到 IP → 才轮到 TCP 握手 → 再 TLS 握手 → 最后 HTTP 请求上路。
DNS 不是可选项，它是进门之前必须出示的门票。你不可能跳过它直接去敲 TCP 的门，因为 TCP 连“你是谁”都听不懂。
DNS 不是“夹在中间”的那一层
很多教程会说：“DNS 解析发生在应用层和传输层之间。”这句话听着顺耳，但容易把人带偏。
DNS 自己就是一个应用层协议，和 HTTP、SMTP 住在同一层，默认跑在 UDP 53 端口上（少数情况走 TCP 53）。它并不充当应用层和传输层之间的关卡，而是另一个应用层服务，由应用层调用，用来帮忙。
这事儿有点绕，打个比方：你要寄快递，得先查收件地址，于是你打开手机问地图 App。查地址这件事，本身也得用手机、用网络。DNS 就是那个地图 App：它是“查地址”的服务，但它查地址的时候，自己也要走传输层，也要占用网络。而且大多数 DNS 查询走 UDP，不用握手，相当于地图 App 不用排队买票，隔着窗口喊一嗓子就能问。
所以准确的顺序是：
- 应用（浏览器、curl、你的程序）在建立 TCP 连接之前，先调用系统提供的解析接口（比如
getaddrinfo）； - 系统解析器发出 DNS 查询，这次查询自己走 UDP 53；
- 拿到 IP 后，应用才真正开始 TCP 握手、TLS 握手、发 HTTP 请求。
用接力赛的话说：DNS 是第一棒，但它跑的这一棒，也得有跑道。它不是站在跑道边吹哨的裁判，它是第一个上场的运动员。
除了浏览器，这些地方也在偷偷解析
“DNS 不就是浏览器的事吗？”——恰恰相反。只要一个程序手里只有域名、却要跟另一台机器说话，它就得先解析。浏览器只是最显眼的那个。
- 浏览器：地址栏是一次解析；页面里的图片、CSS、JS、接口请求，每个新域名都可能再来一次。你以为只打开了一个网页，背地里可能已经问了好几轮。
- 命令行三兄弟：
ping、curl、ssh。你敲下回车，它们第一件事不是连接，而是先翻通讯录。ping www.example.com输出里第一个括号中的 IP，就是刚查出来的。 - 数据库客户端：连接串里写的是
mysql.example.com:3306，客户端也得先把它翻译成 IP，才能建连接。数据库可不会因为你会背域名就网开一面。 - 微服务和容器：Kubernetes 里的 Service 名、Consul/Nacos 里的服务名，本质上都是“名字→地址”的游戏，只是换了个场景。服务发现，说穿了就是 DNS 的亲戚。
- 邮件：发邮件前要先查 MX 记录——“这个域名的邮局在哪”，然后才把信投过去。
- 包管理器和镜像仓库：
npm install、pip install、apt update、docker pull，第一步都是找到仓库的 IP。下次npm install卡住时，可以安慰自己：它可能正在 DNS 的某个路口等红灯。 - 还有一堆你没想到的：NTP 对时、日志上报、监控探针、甚至某些游戏的登录服……凡是配置里写了域名的地方，背后都站着一次解析。
一句话总结：不是“上网才需要 DNS”，而是“只要你要找另一台机器，而手里只有名字，就得先解析”。 浏览器只是让你最直观地感受到这件事的那个窗口。
一个例外：有时候连第一棒都省了
严谨一点，也有“不跑第一棒”的情况：浏览器可能直接复用了之前已经建立的连接（keep-alive、HTTP/2、HTTP/3），压根不需要再查一次；如果你挂了代理，浏览器真正解析的可能是代理服务器的域名，而不是目标网站的域名。
这些属于“缓存和连接复用”的边角料，我们留到第四节再算账。现在先记住主线：大部分情况下，打开网页的第一步，就是 DNS 解析。
既然这第一棒已经确定要先跑，那它到底是怎么跑的？下一节，我们回到你自己的电脑里，看看第一站先问谁。
二、浏览器、操作系统、hosts 文件，解析时先查哪个？
上一节说 DNS 是第一棒。但这一棒不是一个人在跑：浏览器、操作系统、hosts 文件，三位选手挤在起跑线上，谁都觉得自己该先迈腿。
那到底谁先上？
先给结论，免得你带着悬念往下看：没有放之四海而皆准的顺序。大原则是“先本机，后外援”；本机内部，浏览器通常先翻自己的小本本，至于系统缓存和 hosts 谁先，得看操作系统的心情和配置。 别急着背顺序，先看看这三位各自记了些什么，你自然就明白了。
第一站：浏览器的小本本
浏览器是离你最近的那个“前台”。你刚访问过 www.example.com，过几秒再访问一次，它多半会直接从小本本里报出 IP，连操作系统都不用惊动。
这个小本本叫 DNS 缓存，和网页缓存、图片缓存不是一回事。它记的就是“域名 → IP”这种最简单的对应关系，并且带过期时间——毕竟 IP 可能会变，不能记一辈子。
想偷看它？可以：
-
Chrome：地址栏输入
chrome://net-internals/#dns，能看到缓存条目，也能一键清空。
比如我这里使用Chrome查看deepseek的域名和IP地址的映射关系
输入：deepseek.com
点击Lookup可以看得到如下：
-
Firefox：地址栏输入
about:networking#dns，同样能看能清。
火狐浏览器就不做演示了，自己可以尝试解析查看。
这里有个特别常见的误会：“我清了浏览器缓存，为什么 DNS 还是旧的？” 因为你清的是网页、图片、Cookie 那一套，DNS 小本本还在兜里揣着呢。这两个缓存各过各的日子，得分别清。
第二站：操作系统的账本
浏览器没答案，就会把域名交给操作系统去查（大多数浏览器都是这么干的）。操作系统也有一本账，叫 DNS 解析缓存，由系统里的解析服务统一管理。
它比浏览器的小本本“官大一级”：所有程序共享这一本账。浏览器查完，ping、curl、你的数据库客户端再来问，都可能直接命中同一份缓存。
不同系统的查看和清理方式不太一样：
- Windows：命令行执行
ipconfig /displaydns查看缓存，ipconfig /flushdns清空。Windows 的 DNS Client 服务（Dnscache）在后台管着这本账。 - macOS：查看可以用
dscacheutil -cachedump -entries Host（可能要提权），清空用sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder。 - Linux：如果用的是 systemd-resolved，
resolvectl statistics看统计，resolvectl query 域名看单次解析，resolvectl flush-caches清空。
比如我Windows系统使用命令行 ipconfig /displaydns 查看：
这些命令不用背，收藏一下，等“改了域名怎么还不生效”的时候，它们就是救命稻草。
第三站：hosts 文件——互联网最古老的通讯录
接下来这位，年纪最大，脾气也最硬：hosts 文件。
它是一个纯文本文件，一行一条“IP 对应哪个域名”的记录，比如：
127.0.0.1 myapp.local
0.0.0.0 ads.example.com
第一行是本地开发常用的招数：把域名指到自己电脑上；第二行是广告拦截软件爱干的事：把广告域名指到“黑洞”地址，请求发出去也没人接。
它的位置：
- Windows：
C:\Windows\System32\drivers\etc\hosts - macOS / Linux：
/etc/hosts
编辑它通常需要管理员权限。改完可以用 ping myapp.local 验证——如果回显的是 127.0.0.1，说明 hosts 生效了。
hosts 有多老？在 DNS 诞生之前，整个互联网就靠一份叫 HOSTS.TXT 的文件维护主机名和地址的对应关系，由 SRI 的网络信息中心统一维护，各个站点定时下载更新。后来机器越来越多，这份文件实在管不过来了，直到 1983 年 DNS 出现，它才逐渐退休。所以你可以把 hosts 理解成：DNS 的前辈，退休后留在你电脑里的那张便利贴。
这张便利贴有两个特点：
- 没有 TTL。缓存会过期，hosts 不会。写进去就像纹身，不主动擦掉，它就一直在。
- 优先级通常很高。在很多系统里，hosts 的条目会盖过 DNS 返回的结果，这也是为什么“改 hosts 能改域名指向”这个偏方流传至今。
一个坑：顺序不是背出来的
现在回到标题的问题：到底先查哪个？
很多教程会给你一个固定顺序：浏览器缓存 → 系统缓存 → hosts 文件。这个顺序“大体上”没错，但别把它当成铁律，因为不同系统的实现并不一样：
- Linux 上，顺序由
/etc/nsswitch.conf里的hosts:一行决定，常见配置是files dns——files就是 hosts 文件，它排在dns前面。 - Windows 的 DNS Client 服务会把 hosts 文件预载进解析器缓存，所以在 Windows 上，hosts 和缓存几乎是同一本账。
- macOS 则由 mDNSResponder 统一打理，hosts 也在这套体系里。
所以更准确的说法是：先本机，后外援；本机内部，浏览器在前，hosts 和系统缓存谁先，取决于系统配置。 你不需要记住每个系统的细节，只需要知道——它们都是“自己人”，查不到才会出门找人。
也正因为它们各记各的，才会出现那个经典问题：“我改了 hosts，怎么没生效？” 八成是某本小抄还没翻篇。排查顺序可以很简单：
- 清浏览器 DNS 缓存；
- 清系统 DNS 缓存；
- 重启程序（有些程序自己也会缓存解析结果，甚至复用旧连接）。
三招下去，绝大多数“改了半天没反应”都能解决。
本机都没有？该请外援了
如果浏览器、系统缓存、hosts 三位都摇头，说明这件事已经超出“本机”的能力范围了。操作系统会把这个域名交给它配置的 DNS 服务器——也就是递归解析器，让它出门去问。
到这里，DNS 这一棒才真正跑出家门。下一节，我们就跟着递归解析器出门，看看它为什么要先找根服务器，再找 .com，最后才找到权威服务器。
三、本机没有答案时，递归解析器为什么要一路问到权威？
上一节，浏览器、系统缓存、hosts 三位本地选手都摇了摇头。问题被交给出场的下一位：递归解析器。接力赛的第一棒，从这一刻起，就由它替你跑了。
先别急着跟着它跑，我们得先认清两个容易混淆的角色。
递归解析器：你的“跑腿小哥”
你的电脑上也有一个“解析器”，但它只是个传话前台，行话叫 stub resolver（存根解析器）。它的工作很简单：把域名打包成一个 DNS 查询，发给网络配置里指定的那台 DNS 服务器，然后等答案。
真正干活的是那台 DNS 服务器，叫 递归解析器（recursive resolver）。它通常是运营商下发的 DNS，也可能是你手动配置的公共 DNS，比如 8.8.8.8、223.5.5.5、1.1.1.1。
“递归”两个字是关键：你只要最终答案，跑腿的负责跑完全程。 你不需要告诉它先问谁、后问谁，它自己会从根开始，一路问到权威，最后把 IP 塞回给你。
当然，它出门前也会先翻自己的小本本——递归解析器也有缓存。这里先补一句容易忽略的：这本小本本不是你一个人的，而是所有用这台解析器的人共用的“白板”。谁问过，答案就写上去；下一个人来问，直接读白板，不用再跑一趟——这也是为什么有些你没查过的域名，有时也能秒回。
缓存里通常存两类东西：
- 最终答案：比如
www.example.com → 93.184.216.34； - 中间委派：
.com的 NS 在哪、example.com的 NS 在哪。
每条记录都带 TTL，过期才会重新查。所以标题里说的“一路问到权威”，是缓存没命中时的完整路线；命中的话，解析器连门都不用出，直接把答案还给你。
为什么不能一个服务器全包了？
你可能会问：既然最后都是问权威，为什么不让一台“总服务器”存下所有域名，直接查？这样多省事。
省事是省事，但互联网撑不住。全世界的域名数量是亿级的，而且每天都在变；如果所有记录都放在一台服务器上，它会被查询量压垮，任何一次故障都会让半个互联网“失联”。所以 DNS 从设计之初就是分布式、分层级的：
- 根服务器：只知道每个顶级域（
.com、.cn、.org……）的“办事处”在哪； - 顶级域（TLD）服务器：只知道它下面每个二级域（
example.com）的“办事处”在哪； - 权威服务器：才真正存着
www.example.com这类具体记录的“户口本”。
每一级只认识下一级，不越级、不包办。这就像你找人办户口：先去派出所，派出所说这个归分局管；分局说你去市局；市局说这个具体归某某窗口。每一级都只告诉你“下一站去哪”，没人能一口报出全国所有人的地址。
也正因为如此，根服务器才能扛住全世界的查询：它不需要认识 www.example.com，只需要知道 .com 这栋楼在哪。根服务器不是活字典，它是一张全国地图。
跟着跑一趟：根 → TLD → 权威
假设缓存全是空的，我们要解析 www.example.com。递归解析器会这样跑：
解析器：根哥，
.com的办事处在哪？根服务器：我不认识
example.com，但.com的 TLD 服务器地址给你，去问它。解析器：
.com哥，example.com的权威服务器在哪？TLD 服务器：我只管到
example.com这一级，它的 NS 地址给你，去问它。解析器：权威哥，
www.example.com的 A 记录是多少？权威服务器：
93.184.216.34，TTL 3600 秒，拿走不谢。
对应到真实报文，大概是这样：
- 解析器问根服务器：“谁负责
.com？”根服务器返回.com的 NS 记录（以及必要的 glue 地址）。 - 解析器问
.com的 TLD 服务器：“谁负责example.com？”TLD 返回example.com的 NS 记录。 - 解析器问
example.com的权威服务器：“www.example.com的 A 记录是什么？”权威服务器返回 IP 和 TTL。 - 解析器把 IP 返回给你的设备，同时按 TTL 缓存一份。
注意，根服务器和 TLD 服务器从头到尾都没给出最终 IP，它们只负责“指路”。真正把 IP 交出来的，只有权威服务器。
还有一个细节：解析器怎么知道根服务器的地址？答案是——根服务器的地址是写死在解析器里的（叫 root hints）。不然它得先解析根服务器的域名，就成了“先有鸡还是先有蛋”。
根、TLD、权威，各自知道什么？
| 角色 | 知道什么 | 不知道什么 |
|---|---|---|
| 根服务器 | 所有顶级域（.com、.cn……）的 NS 在哪 | example.com、www.example.com 的 IP |
| TLD 服务器 | 其下二级域（example.com）的 NS 在哪 | www.example.com 的 IP |
| 权威服务器 | 自己 zone 里的所有记录（A、AAAA、CNAME、MX……） | 别的 zone |
| 递归解析器 | 缓存 + 怎么逐级问路 | 冷启动时不知道答案 |
| 客户端 stub | 把问题交给递归解析器 | 不会自己跑全程 |
这张表就是标题里那个问题的答案：不是解析器想绕路，而是每一级只掌握下一跳的信息；想知道最终 IP，只能一路问到真正的“户口本”所在地。
递归查询 vs 迭代查询
这里还藏着一对很容易混淆的概念：
- 客户端 → 递归解析器：递归查询。客户端说“我只要最终答案，你负责搞定”。
- 递归解析器 → 根 / TLD / 权威：迭代查询。解析器每问一台服务器，对方只回答“我知道的”或“下一站去问谁”，不负责替你跑完全程。
打个比方：你让助理去办证（递归），助理自己跑各个窗口（迭代）。每个窗口只会说“这个不归我管，你去隔壁”——但助理会一直跑到办成为止。DNS 报文里也有个 RD 标志位，就是客户端在说：“我需要递归服务。”
彩蛋：权威的答案，不一定是“最终 IP”
严格来说，权威服务器返回的不一定是 A 记录。它可能返回一条 CNAME，把 www.example.com 指向另一个域名，解析器还得再跑一轮；如果是 CDN，权威服务器还可能根据你的出口 IP，返回离你最近的节点地址。
所以，“权威”指的是“对这个 zone 有最终解释权”，不代表它一定直接给你最终 IP。这也解释了你有时会看到同一个域名对应好几个 IP——不是 DNS 乱了，是它在做调度。
为什么你平时感觉不到这一路？
因为上面那块“白板”已经挡掉了大部分查询。而且就算最终答案没命中，根和 TLD 的委派通常也还在缓存里——解析器往往只需要再问一下权威服务器，就能把答案补齐。真正“根 → TLD → 权威”三步全走一遍的次数，比你想象得少得多。
这也引出了下一个问题：答案回来之后，到底被谁记住了？为什么下次就不用再跑一遍？下一节，我们就算算这笔“缓存账”。
四、解析结果最后被谁记住？为什么下次不用再跑一遍？
先给答案：不是被某一个“人”记住的，而是被一路上每个经手的人各抄了一份。
你问完 DNS，答案不会只留在权威服务器那里。递归解析器抄一份，操作系统抄一份，浏览器再抄一份；有些程序甚至会自己再抄一份。每一份都写着同一个东西：保质期（TTL）。过期了，就作废重问；没过期，下一位直接照着念。
所以“谁记住了答案”这个问题，答案是一串名字，而不是一个名字。
第一个抄答案的：递归解析器
上一节说过，递归解析器有一块共享的“白板”。你问到的最终答案，它会写上去；下次别人来问同一个域名，直接读白板就行。
它抄的可不只是最终答案，还有中间委派：
www.example.com → 93.184.216.34（最终答案）；.com的 NS 在哪、example.com的 NS 在哪（指路信息）。
这些记录都带 TTL。TTL 没到，它就不再去问根和 TLD；TTL 到了，才重新跑一趟。也就是说，递归解析器的缓存，是“下次不用跑全程”的第一大功臣。
而且这块白板是共享的：你没查过的域名，可能因为别人刚查过，白板上已经有了。这就是为什么有些域名第一次访问也很快——不是你的功劳，是邻居的。
回到本机：操作系统和浏览器也各抄一份
递归解析器把答案给你之后，事情还没完。答案会沿着原路被“抄”回你的设备：
- 操作系统有一本账，所有程序共用。上一节说的
ipconfig /displaydns、resolvectl这些小本本，就是它。 - 浏览器还有自己的小本本，专供自己用。
chrome://net-internals/#dns、about:networking#dns能看到。 - 有些程序（比如 Java 的 JVM，或者带连接池的 HTTP 客户端）会自己缓存解析结果；还有一些程序会直接复用已经建立的连接——连接复用不算 DNS 缓存，但效果一样：不用再查。
于是你下次访问同一个域名，顺序就变成了：
浏览器小本本 → 操作系统账本 → 递归解析器白板 → 根 / TLD / 权威
谁先有没过期的答案，谁就先回答。大多数时候，根本轮不到后面的选手出场。
TTL：DNS 世界的“保质期”
TTL（Time To Live）就是每条 DNS 记录的“保质期”，单位是秒。权威服务器在返回记录时，会顺便告诉全世界：“这条答案，你们最多信 3600 秒。”
- 3600 秒内，缓存可以直接拿它回答；
- 3600 秒后，缓存必须把它扔掉，重新去问。
这带来一个很现实的结果：你改了 DNS 记录，不会立刻全世界生效。 旧的 IP 会在各个缓存里继续“服役”，直到各自的 TTL 到期。就像你改了户口本上的地址，但各地复印的户籍证明还没过期，大家看到的还是旧地址。所以老手改记录前，会先把 TTL 调小，等旧缓存过期，再动 IP。
TTL 还是个权衡：
- TTL 长：查询少、响应快，但改记录后生效慢；
- TTL 短：改记录生效快，但查询多、解析器压力大。
另外，缓存不一定会“完全听话”。有些浏览器或系统会给 TTL 设个上限，比如权威说“信一天”，它自己只肯信几分钟。就像食品包装上写着保质期 7 天，你家冰箱可能只敢放 3 天。
顺便说一句，“查无此域名”（NXDOMAIN）也会被缓存，叫否定缓存。也就是说，缓存不光记对的，也记错的——打错一次域名，可能还得等一会儿才能“改邪归正”。
为什么下次不用再跑一遍？
把镜头拉远，一次域名访问可能命中四种“记忆”：
- 浏览器缓存命中：浏览器自己就知道 IP，连操作系统都不问；如果连接还活着，甚至一个 DNS 报文都不发。
- 操作系统缓存命中：浏览器问系统，系统直接给答案，没有 DNS 查询。
- 递归解析器缓存命中：系统问解析器，解析器直接答；只有一次很短的本机到解析器的往返，不用惊动根和 TLD。
- 只有部分缓存命中：最终答案过期了，但根和 TLD 的委派还在，解析器只需要再问一下权威服务器，就能把答案补齐。
四种都没命中，才会完整地跑一遍“根 → TLD → 权威”。所以“下次更快”不是玄学，而是答案被一层层抄近了：第一次要跑完全程，第二次可能只跑一层，第三次连门都不用出。
还有一个经常被忽略的“加速器”：连接复用。浏览器可能直接复用之前的连接（keep-alive、HTTP/2、HTTP/3），连 DNS 都不用查。你感觉“第二次打开快了”，有时不是 DNS 的功劳，而是连接根本就没断。
几个常见的“缓存坑”
理解了这套“抄答案”的机制，很多日常问题就都有解释了。缓存是性能功臣，也是“改完为什么没生效”的经典背锅侠：
- “我改了 DNS 记录，为什么还没生效？” —— 不是没生效，是旧答案还没过期。你清自己的缓存没用，别人家的缓存、运营商的共享白板，都得等 TTL 到期。
- “我清了浏览器缓存，为什么 DNS 还是旧的？” —— 你清的是网页缓存，DNS 小本本是另一本，得单独清。
- “我改了 hosts，怎么没反应？” —— 浏览器缓存、系统缓存、程序自己的缓存，甚至旧连接，都可能还在用老答案。hosts 本身不会过期，它要是不生效，通常是缓存挡在前面。
- “
ipconfig /flushdns了还是不行？” —— 本机清干净了，但路由器、运营商解析器的缓存还在；如果记录本身 TTL 很长，只能等。 - “为什么同一个域名，我和同事看到的 IP 不一样？” —— 可能是 CDN 按地区/线路调度，也可能是你们用的解析器和缓存副本不同。
小结：答案是一路“抄”回来的
所以，“解析结果最后被谁记住”这个问题，标准答案是：
递归解析器抄一份，操作系统抄一份，浏览器再抄一份；每一份都带保质期，谁离你近、谁没过期，谁就先回答。 权威服务器是户口本，缓存是各地复印件；复印件过期了，才需要回派出所重开。
到这里，DNS 解析的整条链路就串完了：本机自查 → 递归解析器 → 根 → TLD → 权威 → 原路返回并缓存。最后一节，我们把整条链路和这些“小抄”收个尾。
五、总结
好了，接力赛跑完了。让我们把镜头拉远，回放一遍整条路线。
你按下回车，浏览器需要 IP 才能发起 TCP 连接，于是 DNS 第一棒开跑：
- 本机三站：浏览器先翻自己的小本本；没有就问操作系统；操作系统再看 hosts 和系统缓存（谁先谁后，看系统配置）。hosts 是永久便利贴，缓存是有保质期的小抄。
- 递归解析器：本机都没有，问题交给“跑腿小哥”。它先翻共享白板；白板没有，才出门问路。它对你负责到底（递归查询），对根、TLD、权威只问下一跳（迭代查询）。
- 根 → TLD → 权威：根只知道
.com在哪，TLD 只知道example.com在哪，只有权威服务器手里有www.example.com的最终记录。每一级只回答“下一跳”，不越级、不包办。 - 答案回家：解析器把 IP 给你，顺便缓存；操作系统、浏览器也各抄一份。每份都带 TTL，谁离你近、谁没过期，下次谁先回答。
用一张表把这群角色记住：
| 角色 | 一句话职责 |
|---|---|
| 浏览器 | 最近的小抄，先翻自己的 |
| 操作系统 + hosts | 本机总账 + 永久便利贴 |
| 递归解析器 | 跑腿小哥，替你跑全程；缓存是共享白板 |
| 根服务器 | 全国地图，只知道顶级域在哪 |
| TLD 服务器 | 省级档案馆，只知道二级域在哪 |
| 权威服务器 | 户口本，最终答案在这 |
| 缓存 + TTL | 各地复印件 + 保质期 |
如果只记四句话，记这四句：
- 先本机，后外援。 浏览器、系统、hosts 都算“自己人”，查不到才出门。
- 根和 TLD 只指路，权威才发货。 它们从头到尾都不给最终 IP。
- 缓存是复印件，TTL 是保质期。 复印件没过期，大家看到的就还是旧地址。
- 改记录不生效，先想想哪本小抄还没翻篇。 浏览器、系统、解析器、运营商，一层层排。
最后再扫几个容易记错的雷：
- DNS 不在应用层和传输层之间，它自己就是应用层协议，主要跑在 UDP 53 上；
- 根服务器不知道
www.example.com的 IP，它只知道.com怎么走； - 清了浏览器缓存，不等于清了 DNS 缓存；
- 一个域名不一定只有一个 IP，CDN 时代更是如此。
说到底，DNS 并不神秘。它只是把“名字变地址”这件小事，拆成了一场分工明确的接力：每一棒只回答下一跳，每一层缓存都留一份带保质期的复印件。第一次跑要绕地球一圈，第二次可能只跑一层，第三次连门都不用出。
下次你按下回车，页面“唰”地打开时，可以想起这场接力——它安静、快速、几乎从不邀功，但每一次上网，都是它先跑完了第一棒。
DNS 就是一场从你电脑出发、绕地球一圈再回到浏览器的接力赛。
本期文章就到这里，感谢你的耐心阅读。
如果觉得这篇文章对你有帮助，欢迎点赞、关注，我们下期见！
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
11
0- 0
已为社区贡献1条内容
所有评论(0)