1. 为什么要把DNS这件事彻底搞懂

1.1 DNS是互联网的“通讯录”

很多人觉得DNS域名解析是个“配好了就不用管”的黑盒。但实际上，我这些年排查网络问题下来，至少有三分之一的问题根源都出在DNS上，而不是路由器、防火墙或者服务器本身。DNS的全称是Domain Name System，中文叫域名系统，它承担的工作就是把人类易记的域名翻译成机器能理解的IP地址。没有它，你访问一个网站就得记一串类似172.217.16.196的数字，这在现实中根本不可行。

把DNS理解为手机通讯录最贴切：你想给张三打电话，不需要记住他的手机号，只需要在通讯录里找到“张三”这个名字，系统会自动拨出对应号码。域名解析就是这套“通讯录查询”的过程。只不过这个通讯录不是存在某一个人手机里，而是分布在全球无数台DNS服务器上，层级分明、缓存众多、机制灵活。也正因为分布式的设计，才有了后面那么多可配置、可优化、可排查的空间。

1.2 从输入域名到打开网站：一次完整的链路预览

为了让你对“域名解析全流程”有个整体概念，我先快速过一遍从浏览器输入地址到页面打开之间发生了什么。这个过程比大多数人想象的要长，但每一步都不难理解。

浏览器地址栏输入 www.example.com 后，第一步不是去找外部服务器，而是先问自己：我有没有在本地缓存里见过这个域名？如果没有，再去问操作系统；操作系统如果没有，再去查hosts文件；hosts没有，才会把请求交给配置好的DNS服务器。这台DNS服务器可能是你路由器的地址，可能是运营商分配的地址，也可能是你手动设置的大厂公共DNS。它会代替你去完成后续的“找人”动作，找到最终IP后返回，浏览器拿到IP后才发起HTTP请求，与目标服务器建立TCP连接。这里还只是最基础的一条线，实际过程中会碰到CNAME跳转、不同线路解析、IPv4和IPv6双栈解析等情况。后面我会一点点拆解。

1.3 这套解析流程设计的三个关键理由

理解DNS解析流程，最大的价值不是背概念，而是明白为什么它被设计成分层、缓存、递归和迭代并存的形式。我总结有三个关键理由。

第一，抗单点故障。如果全世界只有一台DNS服务器，它一旦宕机整个互联网就瘫痪了。所以DNS采用树形结构，根域、顶级域、权威域层层授权，每层都有冗余。

第二，降低根服务器压力。如果每次查询都要从根域开始走一遍，根服务器的流量会爆炸。于是DNS引入了缓存机制，从浏览器到操作系统到递归服务器，每一层都能缓存结果。第三，支持灵活的解析策略。因为解析请求最终要落到域名的权威服务器上，域名所有者可以在权威服务器上配置多条记录，按来源、按线路、按权重返回不同IP，这对CDN加速和负载均衡很关键。理解了这三点，再去看到底是谁在解析、缓存多久、为什么换DNS要等生效时间，就顺理成章了。

2. 域名解析全流程的核心环节拆解

2.1 浏览器缓存、系统缓存与hosts文件：第一梯队

先说客户端本地这一层。每次DNS解析结果返回后，浏览器和操作系统都会把“域名->IP”的对应关系放进缓存。但这个缓存不是永久有效的，它由DNS响应里的TTL（Time to Live，生存时间）字段控制，单位是秒。比如TTL是600，代表这个记录可以在本地缓存10分钟，10分钟之内再访问同一个域名不会发新的DNS请求。

浏览器缓存只在当前浏览器进程内有效，不同浏览器、不同版本处理策略略有差异。系统缓存则是操作系统层面的，例如Windows的DNS Client服务会缓存解析结果，Linux下的systemd-resolved或nscd也会做类似事情。问题往往出在这：当你手动改了DNS服务器，但本地缓存还留着旧结果，这时候不管怎么刷新页面，访问的还是旧IP。遇到这种“改了没生效”的情况，先别怀疑配置错误，大概率该清缓存。

hosts文件是另一个容易被忽视的地方。在Windows下路径是 C:\Windows\System32\drivers\etc\hosts，在Linux和macOS下是 /etc/hosts。这个文件的优先级非常高，一般会先于DNS服务器被查询。很多开发者在本地调试时会往里面写测试域名，但如果写错了或者忘了删，线上环境就可能被这个文件“劫持”。我遇到过一次线上环境访问接口一直指向旧服务器的案例，查了半天才发现是运维在hosts里静态写了一条记录。