啊梨梨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要等生效时间，就顺理成章了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
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里静态写了一条记录。
2.2 递归查询与迭代查询：一次真实查询的完整路线
当本地缓存和hosts都没有命中时，客户端会把域名解析请求发送给配置的DNS服务器。这个服务器通常是递归解析服务器，它负责“帮到底”。递归服务器收到请求后，会向DNS系统的更上层发起一系列查询，这个过程叫迭代查询。举个例子，解析 www.example.com：
第一站是根域名服务器。递归服务器会问根服务器：“你知道 www.example.com 的IP吗？”根服务器不知道具体IP，但它知道 com 这个顶级域的服务器在哪，于是返回给递归服务器一批 com 顶级域服务器地址。
第二站，递归服务器带着问题去问 com 顶级域服务器，对方同样不直接给答案，但会返回 example.com 这个域的权威服务器地址。第三站，递归服务器再去问 example.com 的权威服务器，这次终于拿到了 www.example.com 对应的A记录或AAAA记录。然后递归服务器把这个结果返回给客户端，并按照TTL缓存一段时间。
这个过程中，客户端只发起了第一次请求，剩下的复杂迭代都是递归服务器完成的。明白了这一点，你就能理解为什么有时候换一个响应更快的公共DNS，会明显感觉到网页打开速度变快——因为它们在世界各地有大量节点和预取缓存，迭代查询链路更短。
2.3 关键DNS记录类型与TTL的作用
DNS记录类型是另一个必须掌握的知识点。网上很多配置教程直接让人加一条“A记录”，但实际工作中会碰到各种类型，搞混了很容易出问题。
A记录是最基础的，把域名解析到IPv4地址。AAAA记录对应IPv6地址。CNAME记录负责别名跳转，比如把 www.example.com 指向 example.com，这样在配置CDN时不用重复维护IP。MX记录指向邮件服务器，NS记录指定该域名的权威DNS服务器。TXT记录通常用来做域名验证、SPF邮箱反垃圾邮件验证等。SOA记录则提供该域名的管理信息，包含序列号、刷新时间等。
TTL的作用比很多人想象的重要。如果TTL设置得太短，比如30秒，所有访问者都频繁回源查询，会增加权威服务器压力；如果设置得太长，比如86400秒，你在迁移服务器IP后会很难受，因为全世界的递归服务器都在缓存旧IP，用户可能一整天访问不了。所以我的一般做法是：在准备迁移IP前，先提前几小时把TTL降到300秒，等迁移完成、确认解析稳定后，再把TTL调回正常的3600秒或86400秒。这个操作虽然简单，但能避免大量用户反馈“网站打不开”的问题。
3. 从配置实战到流程落地：修改DNS的正确姿势
3.1 Linux修改DNS后重启就还原？问题多半出在管理器
Linux下改DNS是个经典坑。很多新手编辑 /etc/resolv.conf，手动加上 nameserver 8.8.8.8，当时生效了，但一重启网络服务或重启系统，文件又变回了原来的内容。这不是系统坏了，而是现在主流Linux发行版都用NetworkManager或systemd-resolved接管网络配置，/etc/resolv.conf 往往是一个软链接，指向systemd-resolved或NetworkManager生成的文件。你直接改它，等于改了被统一管理的文件，等管理服务一刷新就会被还原。
正确做法之一是，如果你用的是NetworkManager，可以用命令行工具配置：
bash复制nmcli con mod "你的连接名" ipv4.dns "8.8.8.8 223.5.5.5"
nmcli con up "你的连接名"
如果用的是systemd-resolved，可以编辑 /etc/systemd/resolved.conf，设置DNS和FallbackDNS，然后重启systemd-resolved服务。另外要注意，如果机器上同时运行Docker或内网DNS服务，还可能出现resolv.conf被容器运行时修改的情况。判断方法很简单：在改动前先用 ls -l /etc/resolv.conf 看看它是不是软链接，是软链接就说明有上层管理服务，别硬改。
3.2 Windows Server与桌面端DNS设置细节
Windows桌面端设置DNS很容易：控制面板或设置里的网络适配器选项，双击IPv4，手动指定DNS服务器地址即可。但企业环境里更多人关心的是Windows Server上的DNS服务器角色。Windows Server安装DNS服务后，可以在DNS管理器里创建正向查找区域和反向查找区域，添加主机记录A/AAAA、别名CNAME、邮件交换器MX等。
这里有一个容易忽略的点：Windows Server的DNS服务器如果接入到已有企业内网，一般需要配置条件转发器或者根提示，否则它不知道如何解析外部域名。对于只在内网使用的区域，勾选“在区域中允许动态更新”可以配合AD域控自动注册客户端记录，但如果你不希望所有设备都能自动写入DNS记录，一定要谨慎开启。原因是AD域控服务器的DNS一旦配置错误，客户端可能无法找到域控，导致登录超时或组策略不更新。我遇到过vCenter 7.0环境下安装部署时因为DNS指向不对，导致服务注册和vSAN通信异常，因为vCenter对正反向解析非常敏感。所以无论在Windows还是Linux上，凡是涉及域控、虚拟化平台的DNS配置，都要先确保正向和反向解析都能通过。
3.3 桥接模式/路由器场景下改DNS的三个最简步骤
经常有人问，虚拟机用桥接模式或者家里路由器上网，明明改了宿主机DNS但虚拟机还是上不了网，是不是没生效。这里的关键在于“谁在给终端下发DNS”。如果是路由器拨号上网，默认会把运营商下发的DNS地址通过DHCP分给所有设备。如果你在路由器后台把DNS改成公共DNS，才不会出现设备手动改了、重启后又自动变回去的问题。
以桥接模式为例。所谓桥接模式，是指虚拟机和宿主机处于同一局域网，直接从路由器获取IP。你如果想改DNS，最简单的三个步骤是：第一，在虚拟机网卡配置里把TCP/IPv4的DNS改为手动，填入 223.5.5.5 或 119.29.29.29；第二，验证是否仍走DHCP，有些系统提供了“空默认网关但DNS手动”的选项，注意别把IP地址也改成手动，否则可能上不了网；第三，在虚拟机里执行 ipconfig /flushdns（Windows）或 systemd-resolve --flush-caches（Linux）清理缓存。做完这三步基本就能生效。如果还想让局域网所有设备统一改DNS，直接在路由器WAN口设置里把DNS改成手动即可，这样所有通过DHCP获取配置的设备都会自动用上新的DNS。
3.4 IPv6 DNS配置与双栈环境下隐藏的坑
现在很多网络已经启用IPv6，但系统DNS配置里往往只改了IPv4，IPv6的DNS还是自动获取的。这会导致一个诡异现象：域名解析部分记录正常，但某些只返回AAAA记录的网站打不开，或者时好时坏。原因是DNS解析同时查询A和AAAA记录，如果系统优先使用IPv6地址访问，但IPv6路由不通，连接就会超时。
配置IPv6 DNS和IPv4类似，在网卡设置里找到IPv6的DNS设置，填写IPv6地址格式如 2400:3200::1（阿里DNS）或 240C::6666（部分地区运营商DNS）。但我的建议是，如果没有特殊需求，可以优先把IPv6 DNS也设为公共DNS，并确保路由器的IPv6功能正常。排查技巧是用 ping -6 测试能否访问IPv6地址，如果ping不通，那就不只是DNS问题，而是IPv6路由或上游没有分配IPv6地址。另外，双栈环境下，如果应用连接总是变慢，可以临时在解析时只请求A记录或AAAA记录来定位问题，Linux下可以用 dig A 域名 和 dig AAAA 域名 分别测试。
4. DNS选型与工具链演进：到底该用谁的DNS
4.1 运营商DNS与大厂公共DNS，怎么选更合理
“DNS到底用本地运营商的还是大厂的”这个问题被问过太多次了。我的看法是：没有绝对的哪个好，关键看你的网络环境。运营商DNS最大的优势是离你近，解析速度快，而且对运营商内网资源（比如区域CDN节点）的调度最准确。但它的劣势也很明显，有时候会出现缓存污染、解析结果被劫持、部分域名因备案策略被特殊处理等情况。
大厂公共DNS的优势是稳定、防污染能力强、全国甚至全球节点多。比如阿里的 223.5.5.5、腾讯的 119.29.29.29、百度的 180.76.76.76，这些在国内都能获得不错的解析速度。但对某些本地化资源的调度可能不如运营商精确，尤其是访问使用地区性CDN的网站时，可能被解析到距离较远的IP。我个人的习惯是：日常办公和家庭主用公共DNS，备用运营商DNS；但在企业内网环境，必须保留运营商或内网DNS用于特殊解析，因为有些内部域名只能通过内网DNS解析。
4.2 公共DNS地址的隐私与可用性权衡
经常有人问，把DNS改成 8.8.8.8 有危险吗。这是个值得展开的话题。技术上来说，8.8.8.8是Google提供的公共DNS，服务本身是可靠的，但你要知道：所有的域名查询记录都会经过Google的服务器，相当于你访问了哪些网站，对方是能看到的。如果你所在网络本身访问国外DNS不稳定，还会导致解析超时。所以“危险”不是指被攻击，而是指隐私信任和可用性问题。
更稳妥的做法是根据自己的网络环境选择。国内访问 223.5.5.5、119.29.29.29 这类公共DNS通常延迟较低。想要隐私保护，也可以考虑支持DoH（DNS over HTTPS）的客户端，也就是把DNS查询内容加密传输，防止中间人窃听和篡改。因为你查询的域名本身是明文传输的，在某些网络环境下，这本就不是什么秘密。但既然涉及域名访问行为，能加密还是尽量加密。不过开启DoH后也要注意，企业内网经常需要解析内部域名，而内部DNS往往不支持DoH，这时候就必须做好分流规则，内网域名走普通DNS，外网域名走DoH。
4.3 从deprecated提示看DNS配置方式的变化趋势
我最近在更新一些开源网络工具时，命令行里出现了类似“DNS option is deprecated”的提示，意思是某个旧DNS配置参数在新版本里已经被弃用了。虽然只是warn级别，不影响运行，但背后反映出来的趋势值得关注：软件生态正在把DNS配置从“单一配置文件手动指定”往“结构化、动态发现、按规则分流”的方向迁移。
比如systemd-resolved、NetworkManager这类系统组件，已经逐渐把网络连接和DNS解析统一管理。以后我们在Linux下手动改 resolv.conf 的地方会越来越少，更多的会是通过 resolvectl、nmcli 这些命令来配置。对于用户来说，这意味着你需要了解更多的命令和概念，但好处是配置更规范化、不容易出缓存冲突。遇到这种deprecated提示，第一反应不是忽略，而是去看新版文档，弄清替代参数是什么，避免将来升级后服务起不来。
5. 常见DNS问题排查技巧与经验速查
5.1 DNS Client Events 1014后断网的常见原因
Windows事件查看器里有一条错误很典型：DNS Client Events 事件ID 1014，后面通常会跟着“无法解析此名称”或“名称解析配置没有正确响应”。很多人遇到这个日志后不久就断网了，以为是网卡坏了，其实最直接的原因是Windows DNS Client服务认为当前配置的DNS服务器没有及时响应，于是标记为不可用。
出现1014后的排查顺序我建议是：先确认网络能不能通，用 ping 223.5.5.5 测一下，如果IP能通但域名不通，那基本就是DNS解析问题。再看是不是某个特定的安全软件或代理工具修改了DNS设置，导致查询被拦截。接着执行 ipconfig /all 查看当前DNS服务器地址，确认没有指向无效地址。还可以用 nslookup 手动查询一个公共域名，看响应是否正常。如果DNS服务器本身没问题，但1014仍然反复出现，考虑重置Winsock目录：管理员身份运行 netsh winsock reset，然后重启系统。经验表明，这个问题十有八九是网卡驱动或第三方软件劫持了DNS解析，而不是运营商线路问题。
5.2 “DNS probe started”与无法找到DNS地址的定位思路
浏览器里出现“DNS probe started”或者“无法找到DNS地址，正在诊断该问题”时，很多人会直接重装浏览器，这没有必要。DNS probe是Chrome等浏览器在发起连接前会做一次诊断性域名解析查询。如果卡在“started”之后一直没结果，说明解析根本没完成。
优先检查防火墙：新版Windows防火墙有时会拦截浏览器的DNS查询流量。再看DNS服务器是否可达，命令行里 ping 8.8.8.8 和 nslookup www.qq.com 都测一遍。如果ping自己的网关正常但nslookup无响应，可能是路由器断开了上游DNS转发。还有一种情况，如果你连的是WiFi但提示没有识别到网络，那可能是WiFi网关下发的DNS后缀或租约异常。可以先把网卡禁用再启用，强制重新DHCP获取。若还不行，打开 网络和共享中心 -> 更改适配器设置，把网卡的DNS临时改成公共DNS再测试，这样可以快速排除是不是路由器DHCP下发的DNS有问题。
5.3 修改DNS被自动还原的隐藏原因
很多人改DNS后没多久发现又变回去了。除了前面说的systemd-resolved接管了resolv.conf之外，还有几个隐藏原因。
第一个是DHCP设置里勾选了“自动获取DNS服务器地址”，只要网卡重新续租，系统就会拿DHCP下发的DNS覆盖手动配置。所以一定要把网卡IPv4设置从“自动获得DNS”改为“使用自定义DNS地址”。
第二个是漫出偏好设置。笔记本上使用移动热点、WiFi和以太网切换时，Windows会有“按网络分配DNS”的特性，针对不同网络单独记忆DNS。你以为全局改了，实际上只是改了当前配置文件的DNS。
第三个是路由器或光猫里有DNS劫持/强制代理功能，不管终端怎么改DNS，只要流量经过它的NAT，它就会把DNS请求重定向到自己的内网地址。这种情况可以通过在电脑上用DoH隧道或指定非标准端口解析来规避，但更根本的是进入路由器后台关闭相关选项。
5.4 国产麒麟/欧拉等系统DNS配置的几个特殊注意点
银河麒麟、欧拉这些国产Linux发行版，底层很多操作逻辑和RHEL/CentOS类似，但细节上有所不同。比如银河麒麟桌面版默认使用NetworkManager管理网络，和Windows类似，可以在图形界面里改DNS。命令行下如果直接编辑 /etc/resolv.conf，同样面临重启后还原的问题。解决方法是：
bash复制nmcli connection show
nmcli connection modify "有线连接" ipv4.dns "223.5.5.5"
nmcli connection modify "有线连接" ipv4.method auto
systemctl restart NetworkManager
欧拉系统服务器版通常不装桌面，配置网卡时建议使用nmtui或编辑 /etc/sysconfig/network-scripts/ifcfg-eth0，在里面添加 DNS1=223.5.5.5，然后执行 systemctl restart network。这两类系统还有一个共性坑：安全加固软件可能会监控并禁止修改DNS配置。如果你改了之后立即被还原，先确认有没有安装类似安全管控的agent。
5.5 一套通用的DNS排查顺序
最后分享一套我自己用了很多年的DNS排查顺序，遇到任何域名打不开的情况，按这个顺序走一遍，基本能定位80%的问题。
第一步，看本地缓存。Windows执行 ipconfig /flushdns，Linux执行 systemd-resolve --flush-caches 或 resolvectl flush-caches。第二步，确认系统配置的DNS服务器是谁。ipconfig /all 或 cat /etc/resolv.conf。第三步，用 nslookup 域名 DNS服务器 把“客户端设置”和“服务器可用性”分开测试。比如 nslookup www.baidu.com 223.5.5.5 能返回结果，说明网络没问题，问题在DNS服务器选择；如果所有DNS都解析不了，再查上游链路。第四步，测安全软件。临时关闭或退出一条安全软件再试解析，很多安全软件会把DNS查询拉入自己的处理流程。
这套顺序看起来简单，但能避免你在一堆热门“解决方案”里乱试，真正的问题往往就在某一层缓存或配置文件里。
说实话，DNS这块内容看起来不起眼，但每次网络出问题，最后绕不开它。我在实际项目里踩过的坑太多了，从Linux重启还原到Windows事件1014，从IPv6双栈到国产系统兼容，没有哪一次是单纯靠重启解决彻底的。把这些记录整理出来，就是希望你再遇到类似问题，不用像我当年一样把系统配置翻个底朝天。如果你手头现在正卡在某个解析错误上，试着按我上面的排查顺序走一遍，多半能少走不少弯路。