前端面试必问：DNS解析原理与实战排查全指南

1. 为什么前端面试总要碰DNS

1.1 前端岗位和DNS有什么关系

前几天帮朋友的公司做前端模拟面试，一天面了四个人，三个都挂在同一个问题上：说一下DNS解析过程。给我的感觉是，不少人把DNS当成"网络基础题"划过去了，觉得这是后端或者运维该操心的事，前端背个大概就行。结果一深问就露馅。

但拆开想一下，前端跟DNS的关系其实非常紧密。用户在浏览器地址栏输入域名，到页面出现第一个字节，这中间DNS承担的是"指路"角色。页面加载慢、图标不显示、接口偶尔超时，很多时候不是服务器的问题，而是DNS解析链路出了问题。更实际的是，前端工程化里涉及CDN、资源部署、多域名收敛、HTTP缓存，这些东西全部建立在DNS正常工作之上。

面试官问DNS，不完全是为了考八股，而是想通过这个话题判断你写代码的时候有没有"全局视野"。一个只说"DNS就是把域名解析成IP"的候选人，和一上来就按"浏览器缓存、系统缓存、路由器缓存、运营商递归服务器、根域名服务器、权威服务器"这条链路逐层分析的人，对网络体系的理解深度完全不一样。

1.2 面试官在这个问题上希望听到什么层次

我把面试官的心理拆一下。初级要求：能说清楚DNS是"域名转IP"的服务，知道典型的A记录和CNAME记录。中级要求：能完整描述一次域名解析请求的流转过程，能区分递归查询和迭代查询，知道常见的缓存层级和TTL。高级要求：能结合前端性能优化讲清楚DNS预解析、域名收敛、DNS-over-HTTPS带来的变化，甚至能说出工作中实际排查DNS问题的手段。

后两个层次是拉开差距的地方。大多数候选人能把前两层背出来，但一问到"为什么浏览器要缓存DNS记录""为什么CDN厂商喜欢让你使用CNAME而不直接给A记录IP""DevTools的Network面板里能不能看到DNS耗时"这类问题，就开始含糊了。

这篇文章我按自己平时准备面试题、也带新人排查线上问题的思路来写，覆盖从基础概念到实战排查的完整内容。说白了，这不仅是八股文备考材料，也是工作中真正用得到的东西。

2. DNS的世界观：从域名到IP的映射体系

2.1 域名不是给人看的，是给层级结构设计的

互联网上每一台服务器都有IP地址，但一串数字（比如23.45.12.34）没人记得住。域名的出现是为了解决"人类友好命名"的问题。这里的关键在于，域名不是一个扁平的字符串，而是一个分层的树状结构。

以www.example.com为例，从右往左看：

• .（根域名）：所有域名的起点，全球有13组根服务器，注意是"13组"而不是"13台"，每组背后有多台物理机做冗余。
• .com（顶级域）：由ICANN授权给Verisign等注册局管理，负责com域下的所有域名注册。
• example.com（二级域）：这个就是你自己注册的域名，可以配置子域、解析记录。
• www（主机记录）：指向具体提供服务的主机，但它其实只是example.com下的一条A记录或者CNAME记录，从技术上讲叫"www"还是"api"还是"static"完全取决于你注册时的配置。

这个树状结构最大的好处是支持"委派管理"。上层的DNS服务器不需要知道下层所有主机的IP，只需要知道怎么把请求转发给下一层。这种设计跟现实中的行政层级有点像：你查一个外地公司的电话，不需要先打听到每一个员工的分机号，只需要知道总机在哪，再让总机帮你转。

面试题里经常出现的「根域名服务器」这个概念，实际上承担的角色就是"总机的总机"。它不存储普通网站域名的解析记录，只存储顶级域（比如.com、.cn、.net）的DNS服务器地址。一旦顶级域服务器挂掉，整个.com域名体系都会受影响，所以根服务器和顶级域服务器都做了大量冗余部署。

2.2 DNS记录类型：别只知道A记录

域名解析靠的是一系列"资源记录"（Resource Record），常见的有这些：

前端最容易接触的是A、CNAME和TXT。CDN加速的原理就是通过CNAME把你的域名指到CDN服务商提供的域名上，CDN再根据请求来源的IP地理位置、节点负载等因素，动态返回一个最优节点的IP。这也是为什么CNAME记录的分发天然比A记录更灵活——因为你可以随时修改CDN服务商那边的解析策略，而不需要改动你自己域名下的记录。

不过CNAME也有一些限制。最重要的一条是：如果一个域名本身承担了MX记录角色（也就是收发邮件），那它就不要设置CNAME，这会导致某些邮件服务异常。另外CNAME记录在DNS解析过程中多了一层"别名追查"的逻辑，理论上会比直接命中A记录多一次查询。

2.3 理解"解析系统"而不是"解析步骤"

很多八股文教程喜欢一上来就甩步骤：第一步查浏览器缓存，第二步查操作系统缓存……这样背起来很快，但一旦面试官换个问法就懵了。我觉得更好的理解方式是：DNS本质上是一套"分布式数据库"，数据分散在全世界成千上万台DNS服务器上，任何一台服务器都不可能保存全部域名记录。解析过程，就是客户端通过"从下往上问、从上往下找"的方式，在这个分布式数据库里定位到具体那一条记录。

这套系统的核心设计哲学是"缓存优先，查询兜底"。如果每个请求都从根服务器开始问，根服务器的压力会大到你无法想象，所以每一层的解析结果都会在各级节点做缓存。缓存策略的好坏，直接影响用户访问网站的速度和稳定性。

3. 一次完整DNS解析过程拆解

3.1 递归查询和迭代查询：面试高频区分点

问DNS解析过程的时候，面试官几乎必问"递归查询和迭代查询有什么区别"。区分这两个概念其实不难，核心在于"谁替你跑腿"。

递归查询：客户端向本地DNS服务器发起查询，本地DNS服务器告诉客户端结果。中间不管本地DNS服务器去问了谁、问了几次，客户端都只管这一个请求。

迭代查询：本地DNS服务器去问根DNS服务器："请告诉我example.com的地址。"根服务器说："我不知道example.com的地址，但我知道.com顶级域服务器的地址是xxx，你去问它吧。"本地DNS服务器又去问.com服务器，得到答复："我不知道example.com的地址，但我知道example.com的权威服务器是ns1.example.com。"最后再去问权威服务器，才能拿到真正的A记录。

浏览器发起的请求通常只是递归查询的起点。真正的递归查询者一般是你的本地DNS服务器（比如运营商分配的那个DNS IP，或者阿里223.5.5.5、114.114.114.114这类公共DNS）。浏览器不直接参与迭代查询，它把需求抛给本地DNS服务器就完事了。

有一个很容易混淆的点：我们平时调试时用的dig命令，默认其实用的是迭代查询模式，dig命令会把每一步查询过程都展示出来。这跟普通用户访问网站时浏览器走的递归查询路径不一样。理解这个区别，面试的时候就能讲得更精确。

3.2 从地址栏到出页面：完整链路

我把一次完整的解析过程按顺序捋一遍，这里的每一步都对应着可以追问的知识点。

第一步，浏览器解析用户输入的URL，提取主机名部分。比如https://www.example.com/products?id=1，浏览器先分出协议是https、主机名是www.example.com、路径是/products、查询参数是id=1。解析URL的时候，浏览器会先判断它是个合法域名还是用户直接输入的IP地址。如果是IP地址，就跳过DNS解析，直接建立连接。

第二步，查浏览器自身的DNS缓存。Chrome里通过chrome://net-internals/#dns可以看到当前的缓存记录。现代浏览器的DNS缓存时间和系统DNS缓存不太一样，Chrome默认采用的TTL上限通常在60秒到300秒之间（不同版本策略有差异），不是直接沿用DNS响应里的TTL值。

第三步，如果浏览器缓存没有命中，就查操作系统层面的hosts文件。macOS和Linux是/etc/hosts，Windows是C:\Windows\System32\drivers\etc\hosts。hosts文件的优先级高于所有DNS服务器，所以本地调试、内网环境映射、甚至屏蔽某些域名广告都在这一层做。

第四步，查操作系统DNS缓存。Windows可以用ipconfig /displaydns查看，macOS可以用sudo killall -HUP mDNSResponder清理缓存。操作系统缓存命中的概率在局域网环境里比公网环境高得多，因为不少路由器或代理工具会做DNS层面的拦截和改写。

第五步，系统把请求发给配置好的本地DNS服务器。这个"本地DNS服务器"可能是：运营商自动分配的地址、你在路由器设置里填写的公共DNS（比如8.8.8.8、1.1.1.1）、或者公司内网自建的DNS服务。如果这个DNS服务器上恰好有缓存，就直接返回结果；如果没有，它就代替客户端去执行迭代查询。

第六步，迭代查询正式开始。先访问根DNS服务器，拿到顶级域的服务器地址；再访问顶级域服务器，拿到二级域的权威服务器地址；最后访问权威服务器，拿到具体的A记录、CNAME记录等。注意，CNAME处理在权威服务器返回后还可能出现额外情况：如果返回的是CNAME，则解析程序需要继续解析CNAME指向的目标域名，直到拿到A/AAAA记录为止。

第七步，本地DNS服务器拿到最终结果后，把结果缓存下来，按照TTL设置一个过期时间，同时把结果返回给操作系统。

第八步，操作系统把结果再缓存一层，返回给浏览器。浏览器拿到IP后，开始发起TCP连接、TLS握手、发送HTTP请求。

这套链路里每一步都有各自的TTL和缓存策略，面试官追问得比较深的时候会问"如果浏览器缓存和系统缓存都没有命中，但是本地DNS服务器的缓存命中了，TTL会不会刷新？"答案是不会，因为本地DNS服务器返回给操作系统时带的是它自己缓存里剩余的TTL值，不会重置。所以TTL本质上是个"倒计时"而不是"保底时间"。

3.3 用dig命令把解析过程看得明明白白

理论讲完，最好还是落到工具上。很多人做前端开发不太用dig，其实这个命令排查问题非常方便。

# 查询A记录 dig example.com A # 追踪完整解析链路 dig +trace example.com # 指定DNS服务器查询 dig @223.5.5.5 example.com # 只返回结果，不返回附加信息 dig +short example.com

dig +trace的输出尤其值得细看。它会按顺序打印出根服务器、顶级域服务器、权威服务器的响应过程。第一次看到的时候，你会发现DNS解析不是一步跳到结果，而是真的层层转包。这比任何文字描述都直观。

我这里给一个实际输出的简化示意：

; <<>> DiG 9.10.6 <<>> +trace example.com ;; Received 12 bytes from 8.8.8.8#53(8.8.8.8) in 42 ms . 518400 IN NS a.root-servers.net. . 518400 IN NS b.root-servers.net. ;; Received 228 bytes from 198.41.0.4#53(198.41.0.4) in 27 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. ;; Received 197 bytes from 192.5.6.30#53(192.5.6.30) in 15 ms example.com. 172800 IN NS a.iana-servers.net. ;; Received 191 bytes from 192.42.93.30#53(192.42.93.30) in 15 ms example.com. 3600 IN A 93.184.216.34

每一步的缩进代表一次迭代查询，实际耗时可以在in XX ms里看到。如果哪一步耗时异常高，基本能锁定问题出在哪个级别的DNS服务器上。

4. 各级缓存与TTL：面试里最常见的追问点

4.1 缓存层级不是越多越好

缓存的作用是减少查询耗时、降低上游服务器压力，但缓存层级过多也会带来问题：域名解析变更生效慢。你修改了一条DNS记录，理论上最长可能需要等所有层级的缓存全部过期之后才能生效，这个时间被称为"DNS传播延迟"。

前端遇到的一个经典场景就是上线前改了DNS记录，结果有些用户访问的还是旧IP。排查的时候第一时间是猜CDN问题，实际上往往就是TTL设太长。如果旧记录没有紧急下掉的需求，建议提前把TTL调低（比如从24小时调到5分钟），等变更确认稳定后再调回正常值。

各层缓存的顺序和策略总结如下：

浏览器和系统的缓存清空之后，本地DNS服务器的缓存往往还指望着你"等一段时间"。这也是为什么改完DNS解析记录之后，验证时常要在不同网络环境（手机流量、公司网络、家庭网络）下分别测试。

4.2 TTL是怎么影响解析时长的

TTL（Time To Live）是DNS响应里携带的一个字段，单位是秒，表示这条记录可以被缓存多长时间。比如3600表示缓存1小时，60表示缓存1分钟。

计算方式比较简单：A服务器返回一条记录说"TTL=300"，B服务器缓存了这条记录，那么在B身上它就保留300秒。300秒后B再次收到对同一域名的请求时，会向上游重新发起查询。注意，B不会在缓存过期那一刻主动去刷新，而是等到有请求进来了才去重新查。所以"缓存过期"和"重新查询"之间不一定完全同步，取决于有没有流量触发。

面试官经常在这个位置问一道衍生题："把TTL设得越短越好吗？"答案是否定的。TTL过短会导致权威服务器的查询压力呈指数级上升，因为每一级缓存的存续时间都被压缩了；TTL过长又会导致解析变更生效慢。合理做法是分场景：

• CDN加速域名：通常由CDN服务商管理，TTL不建议手动改，他们内部有专门的调度逻辑。
• 自己的业务域名：默认1小时是一个非常稳妥的起点。
• 即将做迁移、切IP、切换服务商的域名：提前1-2天调低到300秒，变更完成观察稳定后再调回3600。

4.3 缓存命中与缓存穿透的边界

前端八股如果考到"缓存穿透"，一般说的是HTTP缓存里请求打到源站的情况，但在DNS体系下也有对应的概念。

DNS层面的缓存穿透就是指一个域名的记录在任何一层缓存里都不存在，所以每次请求都需要一路查到权威服务器。高并发场景下，如果有一个尚未被缓存的新域名突然被大量访问，会导致本地DNS服务器和权威服务器承担瞬时高压。这种场景在抢购、秒杀、新系统上线第一天容易遇到。

DNS缓存污染（DNS Spoofing / Cache Poisoning）则是更危险的问题。攻击者通过虚假的DNS响应，让DNS服务器缓存了一条错误的IP映射。之后所有访问该域名的用户都会被引导到恶意服务器上。传统防御手段是随机化UDP源端口和Query ID，更多场景下建议直接使用支持DNSSEC的解析服务，以及DoH（DNS over HTTPS）来防止中间链路窃听篡改。

这里有一个前端实践层面的延伸：如果公司自研了公共服务SDK，SDK内部如果自己做了DNS解析、然后又做了一层业务级缓存，那么"改域名、切环境、灰度"这类操作的生效时间就会多一个不可控变量。有几个项目遇到"配置改了但流量没切换"的问题，排查到最后发现就是SDK里有一层独立DNS缓存，TTL直接抢在系统缓存前面。

5. 前端实战里的DNS：优化手段与坑点

5.1 DNS预解析：省掉"第一个请求"的时间

浏览器拿到HTML之后，开始解析DOM、加载CSS和JS。如果页面里引用了外部域名下的资源，浏览器在遇到<link>或<script>标签时，需要先做域名解析才能发起请求。这个解析时间在高延迟网络环境（比如移动网络、海外节点）下可以达到几十毫秒甚至上百毫秒，对首屏渲染的影响不可忽视。

DNS预解析就是提前把这些域名解析掉。HTML里的写法是：

<link rel="dns-prefetch" href="//cdn.example.com"> <link rel="dns-prefetch" href="//api.example.com">

浏览器的解析器一旦读到这个link标签，就会在后台启动DNS查询流程，把对应域名的缓存预填到浏览器缓存里。等到真正需要加载cdn.example.com上的资源时，解析结果已经就绪，省掉了"解析等待"。

对于HTTP/2或HTTP/3的多路复用站点，还有个更强的优化手段是preconnect。它不光做DNS预解析，还会提前完成TCP握手（以及TLS握手，如果配置了crossorigin属性）。如果某个第三方域名的资源是首屏关键依赖，preconnect比dns-prefetch效果更明显。但注意别滥用，每个preconnect都会占用浏览器的连接配额，连接数开太多反而拖慢页面。

5.2 域名收敛：少一个域名就少一次解析

很多前端性能优化清单里都写到"减少DNS查询次数"，但"域名收敛"这个词值得单独拿出来说。它指的是控制页面中实际使用的域名数量，尽量把静态资源收敛到一个或两个CDN域名下。

为什么域名要收敛？每次访问一个新域名，就多一次DNS解析、多一次TCP握手（HTTP/1.1场景下还多一个连接）。HTTP/1.1时代浏览器对同一个域名的并发连接数有限制（通常是6个），所以很多站点用多个子域名来绕过这个限制，把资源"摊"到不同域名上从而提高并发加载能力。这种做法在HTTP/1.1年代是合理的。

但进入HTTP/2时代之后，多路复用让"所有资源走同一个域名"成为了更优解。因为HTTP/2是单连接多路复用，多个请求可以在同一条TCP连接上并行传输，域名多了反而增加握手和解析开销。页面资源全部收敛到一个域名下，DNS只需要解析一次，连接只需要建立一次，大幅降低首屏加载的网络耗时。

面试时如果聊到域名收敛，可以顺带提一下团队内部做过的数据验证：某个活动页原来用了四个域名（主站域名、图片CDN域名、接口域名、统计域名），收敛成两个之后，弱网环境下首屏加载时间有比较明显的提升。这种经验比单纯的"背结论"有说服力得多。

5.3 前端排查DNS问题的完整思路

工作中遇到"为什么这个页面在我这儿加载慢，在别人那儿正常"这类问题，DNS是优先级较高的排查对象。这里有一个我自己常用的排查顺序。

第一步，看浏览器自带的信息。Chrome DevTools的Network面板选中一个请求，在Timing选项卡里能看到"Stalled"和"DNS Lookup"两个阶段。"DNS Lookup"就是域名解析耗时，理想状态下这个值应该在几毫秒到几十毫秒之间。如果这个值异常大（几百毫秒甚至秒级），说明DNS解析链路本身出了状况。

第二步，换DNS服务器测试。在系统网络设置里临时把DNS改成公共DNS（比如阿里DNS 223.5.5.5、腾讯DNS 119.29.29.29、Cloudflare 1.1.1.1），然后刷新页面对比加载速度。如果换完之后明显变快，问题大概率出在原来的DNS服务器上。常见原因是运营商DNS调度异常或者缓存污染。

第三步，使用dig命令测试权威服务器的响应质量：

dig @223.5.5.5 yourdomain.com dig @你的权威DNS地址 yourdomain.com

对比两个命令的解析耗时。如果权威服务器本身响应慢，那问题可能出在域名服务商的解析性能上，要考虑切换DNS服务商。

第四步，检查CNAME链路是否有多层跳转。有些域名服务商配置不当，会出现"域名A -> 域名B -> 域名C -> CDN域名"这样的多层CNAME链路，每多一层就多一次额外解析。用dig +trace可以看清整条链。

第五步，确认是否有DNS劫持。移动网络下偶尔会出现特定域名被解析到错误IP的情况，典型表现是浏览器弹出广告或安全警告。用dig查询到的结果如果跟权威服务器的记录不一致，基本可以判断为链路劫持。解决办法是启用DoH或DoT，浏览器层面可以在Chrome的隐私设置里开启"安全DNS"。

5.4 面试高频追问的应对思路

面试里DNS问题通常不会停在"会解析过程"就结束，这里列出几个我实际遇到过的追问，以及建议的应答思路。

追问一："为什么DNS用的是UDP而不是TCP？"因为大多数DNS响应报文非常小，一个包就能装下，UDP更加轻量高效。但是如果响应报文超过512字节，就得靠EDNS0扩展机制，或者改用TCP来保证完整性。所以不能简单说"DNS只用UDP"，准确说法是"首选UDP，大包或可靠性要求高时切换TCP"。

追问二："DNS查询的源IP是浏览器所在终端的IP吗？"不是。浏览器把请求发给本地DNS服务器，本地DNS服务器去迭代查询时，对外发出请求的源IP是本地DNS服务器的IP，而不是用户终端的IP。这也是为什么CDN调度有时会出现"解析到就近节点不准确"的问题——CDN厂商看到的是DNS服务器的IP位置，而不是用户的实际位置。公共DNS和运营商DNS的IP地理位置跟用户位置通常一致，但如果你在办公室用云厂商自建DNS，解析结果可能就调度到离机房近的节点而不是离你近的节点。

追问三："CNAME有什么缺陷？"前面提到了CNAME不能和MX记录共存，另外CNAME在任何场景下都保持"别名"语义，所以不能在CNAME节点下再挂其他类型的记录，比如你想在www.example.com上既做CNAME又做TXT记录是不行的。很多DNS服务商在配置时也会直接限制这类组合。

追问四："你怎么理解DoH？"DoH把DNS查询封装在HTTPS请求里，用443端口传输，好处是外部无法窃听你查了哪些域名，也无法轻易篡改结果，对防劫持很有价值。代价是需要额外的HTTPS请求开销。

6. 从八股到实战：一些值得长期记住的经验

最后分享几个我这些年踩过、也带人排查过的真实问题。它们都跟DNS相关，但都是"背了八股也不一定知道"的细节。

第一个经验是改DNS记录之后一定要验证CNAME链路是否完整。有一次做CDN切换，只改了A记录，漏掉了CNAME链路上的中间域名，结果新节点怎么也上不了线。排查了好几个小时，最后用dig +trace一看才发现中间域的解析还是指向旧CDN。改DNS不只是改一条记录，而是要把整条链路核对清楚。

第二个经验是配置hosts调试完记得清理。开发环境经常要改hosts来指向测试服务器，改完就忘、忘了就出大问题。我碰到过最离谱的一次，有个线上故障是因为某位同事在服务器上改hosts时写错IP，导致该服务器访问公司的鉴权服务一直打不到正确地址。排查半天最后发现hosts里有条脏记录。所以我在团队里定了一个小规矩：涉及hosts的变更，必须带日期和目的写注释，改完及时清理。

第三个经验是别把DNS超时当成接口超时。前端排查接口请求超时，先看Network面板里"DNS Lookup"阶段是否红色。很多接口超时问题的根因是DNS解析失败，但错误上报系统里显示的只是"请求超时"，容易误导排查方向。前端上报错误的时候，如果浏览器支持PerformanceResourceTiming，可以进一步确认domainLookupStart和domainLookupEnd这两个时间点，用这两个字段能直接算出DNS耗时。

第四个经验是谨慎使用"浏览器无痕模式"作为DNS问题的验证环境。无痕模式下的缓存策略跟正常模式差异很大，有些浏览器在无痕模式反而更激进地使用系统DNS缓存，导致你测出来的结果跟用户实际体验不一致。更可靠的验证方式是换一个没访问过该站点的浏览器，或者直接用手机流量进行对比测试。

DNS这块知识，面试的时候是一条"八股链"，从域名的树状结构到递归与迭代查询，再到缓存和TTL，能顺着讲下来就是一个完整的知识体系闭环。而在实际工作中，它又是一个排障工具链的入口，很多页面加载问题、接口超时问题、资源加载失败问题，追根溯源都会撞到DNS上。把这套东西弄明白，一通百通。