域名解析的完整流程：从输入网址到显示网页发生了什么

　　在浏览器地址栏里敲下www.example.com，按下回车，网页内容出现在屏幕上——这个过程快得让人几乎感觉不到延迟。但在这几百毫秒里，互联网上一大堆设备协同工作，完成了一系列精密的操作。域名解析就是其中最关键的一环，没有它，浏览器根本不知道要去哪找你要的数据。

　　为什么需要域名解析

　　网络通信的底层依赖IP地址，IPv4是32位的数字，比如203.0.113.5，IPv6更长，写出来一串字母数字混排。人是记不住这些东西的，尤其你要访问几十个不同网站的时候。域名系统(DNS)就是为了解决这个矛盾而生的一套分布式数据库——它负责把人类可读的域名，翻译成机器可读的IP地址。

　　这个过程叫域名解析，也叫DNS查询。

　　浏览器首先查自己的缓存

　　按下回车之后，浏览器做的第一件事不是发网络请求，而是翻自己的本地缓存。现代浏览器都内置了DNS缓存模块，会记录之前查询过的域名和对应的IP地址，以及这条记录还能存活多久——这个存活时间由域名的TTL值决定。

　　如果在缓存里找到了记录，并且TTL还没过期，浏览器就直接拿着这个IP去建TCP连接了，整个解析过程到此结束。这一步发生在内存里，速度极快，微秒级别就能完成。

　　假如缓存里没有，或者记录已过期，浏览器就会把查询任务交给操作系统。

　　操作系统的Hosts文件与缓存

　　操作系统收到查询请求后，同样先查自己的本地缓存，Linux和Windows都有系统级的DNS缓存服务。如果缓存命中，就直接把结果返回给浏览器。

　　如果系统缓存也没命中，操作系统会去查找本地的hosts文件。这个文件在不同的系统里路径不一样，Linux和macOS在/etc/hosts，Windows在C:\Windows\System32\drivers\etc\hosts。

　　hosts文件是一个本地的静态映射表，优先级非常高。很多开发者在本地测试时会往这个文件里写一些临时映射，比如把www.example.com指向127.0.0.1。如果hosts文件里有匹配的记录，操作系统就直接返回结果，不会再往外发任何网络请求。

　　递归查询：向本地DNS服务器发起请求

　　如果以上三层缓存都没命中，操作系统就会向网络配置里指定的本地DNS服务器发起查询请求。这个本地DNS服务器一般是由你的网络服务商提供的，也可以手动改成公共DNS。

　　从这一步开始，真正的网络请求就发生了。操作系统发出的这个DNS查询报文，走的是UDP协议，目标端口是53。

　　这里有一个重要的概念叫递归查询。操作系统发给本地DNS服务器的请求，是要求对方必须给出最终的查询结果，如果它自己不知道答案，它就得替你去问其他的DNS服务器，直到拿到结果再返回给你。

　　迭代查询：本地DNS服务器层层追问

　　本地DNS服务器收到查询请求后，它自己也有缓存，会先查一遍。如果没有，它就开始执行迭代查询——挨个去问根服务器、顶级域服务器和权威服务器，一层一层往下找。

　　第一步：问根服务器

　　本地DNS服务器首先向13组根服务器中的任意一组发起查询。根服务器是全球DNS体系的最高层级，它不存储具体的域名记录，但它知道所有顶级域服务器的地址。

　　当根服务器收到www.example.com的查询时，它会根据域名的后缀返回对应顶级域的服务器地址——.com对应的顶级域服务器列表。

　　第二步：问顶级域服务器

　　本地DNS服务器拿到根服务器返回的地址后，再去访问.com的顶级域服务器。顶级域服务器也不存储具体的域名记录，但它知道每个一级域名背后的权威服务器是谁。它会返回example.com对应的权威DNS服务器的地址。

　　第三步：问权威DNS服务器

　　本地DNS服务器拿到权威服务器的地址后，最后一步就是向它发起查询。example.com的权威服务器里存放着这个域名下所有记录的真实数据，包括www.example.com对应的A记录或者CNAME记录。

　　权威服务器收到查询后，会在自己的区域文件里查找，找到www.example.com对应的IP地址，然后把这个结果返回给本地DNS服务器。

　　缓存与返回

　　本地DNS服务器拿到最终IP地址后，会先把这个结果存进自己的缓存里，同时根据这条记录的TTL值设定过期时间。然后把IP地址返回给操作系统，操作系统再返回给浏览器。

　　浏览器拿到IP地址之后，DNS查询流程就结束了，接着开始建立TCP连接、发送HTTP请求、接收响应数据、渲染页面。

　　迭代查询和递归查询的区别

　　整个流程里涉及两种查询模式。客户端到本地DNS服务器之间是递归查询——客户端只管问一次，等着拿结果就行了。本地DNS服务器到根服务器、顶级域服务器、权威服务器之间是迭代查询——每次都只得到下一跳的地址，自己去追问。

　　这种设计是有意为之的。如果把迭代的压力都放在根服务器上，根服务器早就被压垮了。迭代查询把工作量分摊到了各个层级的服务器上，每一层只负责自己的那一小片区域。

　　DNS记录类型

　　刚才提到的A记录只是DNS记录类型里的一个基础类别。除了A记录之外，还有几个常见类型：

　　AAAA记录：把域名解析成IPv6地址，功能和A记录一样，只是针对IPv6

　　CNAME记录：把域名解析到另一个域名，比如www.example.com可能CNAME指向cdn.example.net，最终由后面的域名提供IP

　　MX记录：指定邮件服务器的地址，收发邮件时用

　　NS记录：指定域名的权威DNS服务器是谁

　　一个典型查询的完整报文路径

　　把上面的流程用实际路径串起来就是：

　　浏览器缓存 → 操作系统缓存 → hosts文件 → 本地DNS服务器缓存 → 根服务器 → 顶级域服务器 → 权威服务器 → 本地DNS服务器缓存 → 操作系统缓存 → 浏览器缓存

　　每一层缓存的存在都是为了加速。根服务器和顶级域服务器基本不直接承受普通用户的查询压力，绝大部分查询在本地DNS服务器那一层就已经有缓存命中了。

　　解析过程中可能遇到的问题

　　域名解析不是百分百成功的，比较常见的问题有这么几类：

　　本地DNS服务器故障或响应超时。如果运营商提供的DNS服务器宕机或者响应慢，整个解析过程就会卡住。这时候把本地DNS改成8.8.8.8或114.114.114.114往往能绕过去。

　　权威服务器配置错误。比如域名的NS记录指向了错误的服务器地址，或者权威服务器上的A记录写错了，本地DNS服务器拿到的就是错误IP。

　　缓存污染或DNS劫持。某些网络环境下，运营商的DNS服务器会返回错误的IP地址，把用户引导到广告页面。这时候用DNS over HTTPS或DNSSEC可以起到保护作用。

　　TTL值设置不合理。如果TTL设得太短，权威服务器的访问压力会增加，用户端的解析延迟也会变大。如果设得太长，域名切换IP时会面临很长的生效等待时间。

　　小结：域名解析的完整流程，从输入网址到拿到IP地址，涉及浏览器、操作系统、本地DNS服务器、根服务器、顶级域服务器、权威服务器等多个节点。每一层都靠缓存来加速，每一层都有各自负责的查询范围。这个体系从上世纪80年代设计出来，一直运行到今天，支撑了整个互联网的寻址需求。下次你在浏览器里输入一个网址，看到页面瞬间加载出来的时候，可以想一想——背后这6层节点已经在几百毫秒内替你完成了一次全球范围内的分布式查询。