1. 从一个让人抓狂的故障说起为什么DNS值得单独拎出来讲刚入行那会儿我遇到过一个至今印象深刻的故障。一台服务器上的Web服务跑得好好的本地用IP访问一切正常但换成域名就时通时不通重启服务、检查防火墙、翻看日志折腾了大半天毫无头绪。最后一位老同事过来敲了两条命令问题定位了——域名解析结果指向了一个早已下线的旧IP。整个过程里服务本身没有任何毛病坏的是名字到地址这条翻译链路。这件事让我意识到DNSDomain Name System域名系统虽然平时默默无闻却是整个网络世界里最不能出问题的基础设施之一。它就像电话簿你记得住张三这个名字但拨号需要的是那串号码DNS干的就是把名字翻译成号码的活。一旦这本电话簿出错、过期或者查不到后面所有的通信都无从谈起。这篇内容我想聊的不是教科书上那种DNS是什么的科普而是从实际运维和配置的角度把DNS的工作原理、常见记录类型、服务端配置、客户端排查这几件事讲透。适合谁看如果你是需要自己搭DNS服务的运维、被域名解析问题折磨过的开发、或者想搞明白为什么改了域名要等一会儿才生效的普通用户这篇都能给你一些能直接上手的东西。我会尽量把每个配置项背后的为什么讲清楚而不是甩一堆参数让你照抄。2. DNS到底在背后做了什么一次解析的完整旅程2.1 递归查询与迭代查询两种角色的分工很多人对DNS的理解停留在输入域名返回IP这一层但真正理解它的工作方式得先分清两个概念递归查询和迭代查询。打个比方。你要找某个陌生人的电话号码但你不知道。你可以去问一个万事通朋友递归解析器你说帮我查一下这个人的号码他要么直接告诉你要么自己去一层层问别人最后把结果给你。你只问了一次这就是递归查询——你委托对方帮你把结果拿到手。而万事通朋友自己是怎么查的呢他先问根服务器这个域名谁管根服务器说你去问某个顶级域服务器他再去问顶级域服务器对方说你去问某个权威服务器最后问到权威服务器才拿到真正的号码。这一层层问过去、每次只拿到下一步该问谁的过程就是迭代查询——每次只得到线索需要自己继续追。理解这个分工很关键。你本机配置的DNS服务器比如运营商给的、或者公司内网的通常扮演递归解析器的角色它负责替你跑完整个迭代过程然后把最终答案缓存下来。这也是为什么第二次访问同一个域名会快很多——答案被缓存了。2.2 缓存与TTL为什么改了记录不能立刻生效这是被问得最多的问题之一我把域名指向改了为什么过了半天还没生效答案就在TTLTime To Live生存时间这个参数上。每条DNS记录都有一个TTL值单位是秒表示这条记录可以被缓存多久。当递归解析器拿到一条记录后它会在本地缓存TTL指定的时间。在这段时间内再有用户来查同一个域名解析器直接返回缓存里的旧结果根本不会去问权威服务器。所以当你修改记录时那些已经缓存了旧记录的解析器要等缓存过期才会去拿新结果。这就是生效延迟的来源。常见的TTL设置从300秒5分钟到86400秒24小时不等。提示如果你计划做一次重要的域名迁移提前把TTL调小比如改成300秒等旧TTL过期后再切换切换完确认无误再调回较大值。这个预热操作能大幅缩短切换期间的混乱窗口。2.3 解析链路中的每一环都可能出问题一次完整的解析涉及本机缓存、hosts文件、本地DNS服务器、递归解析器、根服务器、顶级域服务器、权威服务器等多个环节。任何一环出问题表现都是域名打不开但根因可能天差地别。我习惯按这个顺序排查先看本机缓存和hosts文件最容易忽略再看本地配置的DNS服务器是否可达然后看解析结果是否正确最后才怀疑权威服务器。这个顺序是从近到远、从简单到复杂能帮你快速排除掉大部分低级问题。3. 那些必须搞清楚的记录类型不只是A记录3.1 A、AAAA与CNAME最常用的三兄弟A记录是最基础的把域名指向一个IPv4地址。AAAA记录读作quad-A对应IPv6地址格式上就是多了一倍的位数。这两个是名字到地址的直接映射。CNAME记录Canonical Name别名记录则不同它把一个域名指向另一个域名而不是IP。比如你把www.example.com设成example.com的CNAME那么访问前者时解析器会先找到后者的A记录再返回IP。CNAME的价值在于解耦。假设你有一堆子域名都指向同一台服务器如果直接写A记录服务器换IP时你得改一堆地方用CNAME指向一个主域名只改主域名的A记录就够了。但CNAME有个硬性限制一个域名不能同时存在CNAME和其他记录比如MX因为CNAME会接管整个域名的解析其他记录就没法共存了。这个坑我踩过当时想给一个已经设了CNAME的域名加邮件记录怎么都不生效后来才明白是这个规则在作祟。3.2 MX、TXT、NS、SOA各有各的战场MX记录Mail Exchange指定邮件服务器它带一个优先级数值数值越小优先级越高。发邮件时发送方会按优先级依次尝试。配置邮件服务时MX记录写错或者优先级搞反是邮件发不出去的常见原因。TXT记录最初是用来放任意文本的现在最常见的用途是域名所有权验证和邮件安全策略比如SPF、DKIM这些反垃圾邮件机制。很多云服务商让你加一条TXT记录来证明这个域名是你的就是利用了这个机制。NS记录Name Server指定这个域名由哪些DNS服务器负责解析它决定了权威在哪里。SOA记录Start of Authority则包含了一个区域的核心管理信息比如主服务器、管理员邮箱、序列号、各种刷新和过期时间。SOA里的序列号特别重要——从服务器靠它判断主服务器的数据有没有更新序列号没涨从服务器就不会同步。3.3 记录类型速查与常见误用记录类型作用典型场景常见坑A域名到IPv4网站、服务器忘改导致指向旧IPAAAA域名到IPv6支持IPv6的服务环境不支持IPv6时反而变慢CNAME域名到域名CDN、多子域统一管理与MX等其他记录冲突MX邮件路由企业邮箱优先级数值搞反TXT文本信息验证、邮件策略内容超长需分段NS权威服务器域名托管改NS后需等待传播SOA区域管理信息主从同步序列号忘记递增这张表我建议存下来配置时对照着看能避开不少低级错误。4. 亲手搭一个DNS服务从选型到跑通4.1 为什么选这个方案几种常见DNS服务端对比自己搭DNS常见的选择有几种。BIND是元老级的功能全、资料多但配置文件语法有点反人类dnsmasq轻量适合做本地缓存和简单转发配置极简CoreDNS是较新的选择插件化设计配置用类似配置文件的语法很适合容器化环境PowerDNS则在数据库后端支持上做得很好适合大规模场景。如果你的需求只是给内网做缓存加速少量自定义解析dnsmasq基本够用几十行配置就能跑起来。如果要做权威解析、管理大量区域BIND或PowerDNS更合适。我下面以BIND为例讲配置因为它的概念最完整学会了再迁移到其他工具会轻松很多。4.2 主配置文件与区域文件两个核心概念BIND的配置分两层主配置文件通常是named.conf定义我管理哪些区域、去哪里找区域文件区域文件zone file则具体描述这个区域里有哪些记录。主配置文件里一个典型的区域定义长这样zone example.com IN { type master; file /etc/bind/db.example.com; allow-transfer { 192.0.2.2; }; };这里type master表示这是主服务器file指向区域文件路径allow-transfer限制哪些从服务器可以来同步数据——这个限制很重要不设的话任何人都能拉走你整个区域的记录等于把内网结构暴露了。区域文件则是记录的实际存放地一个简化版本$TTL 3600 IN SOA ns1.example.com. admin.example.com. ( 2024010101 ; 序列号 3600 ; 刷新 1800 ; 重试 604800 ; 过期 86400 ) ; 最小TTL IN NS ns1.example.com. IN A 192.0.2.10 www IN CNAME mail IN A 192.0.2.20 IN MX 10 mail.example.com.几个细节值得说。第一行的$TTL是默认TTL没单独指定的记录都用它。SOA记录里那个2024010101是序列号每次改完区域文件必须递增它否则从服务器不会同步——这是新手最容易忘的一步。符号代表当前区域名本身省得你到处写全称。4.3 配置完必须做的验证动作配置写完不代表能用。我习惯按这几步验证语法检查named-checkconf检查主配置named-checkzone example.com /etc/bind/db.example.com检查区域文件。这两条命令能在重启服务前就发现大部分语法错误省得服务起不来还找不到原因。重启或重载服务改完配置用rndc reload重载比直接重启更平滑。本地查询验证用dig 127.0.0.1 www.example.com直接问本机DNS看返回是否符合预期。序列号确认dig 127.0.0.1 example.com SOA看序列号是不是你刚改的值。注意区域文件里每条记录的域名结尾那个点.千万别漏。ns1.example.com和ns1.example.com.在DNS里是两个完全不同的东西——前者会被自动补上当前区域名变成ns1.example.com.example.com这个错误极其隐蔽我第一次配的时候就被它坑了半天。5. 客户端这边解析配置与排查手法5.1 resolv.conf与解析顺序客户端这边Linux系统主要看/etc/resolv.conf里面用nameserver指定DNS服务器地址可以写多个按顺序尝试。还有个search选项指定搜索域让你输入短名字时自动补全后缀。但要注意很多系统上这个文件是被网络管理工具动态生成的你手动改了重启网络或者重连之后可能被覆盖。要持久化配置得改对应的网络管理配置而不是直接编辑这个文件。这个坑我见过太多次了——有人改完当时好用第二天重启就失效了其实是被覆盖回去了。解析顺序上系统一般先查本机缓存再查/etc/hosts最后才去问DNS服务器。/etc/hosts的优先级很高有时候域名解析异常就是因为这里有一条陈旧的静态映射在捣乱。5.2 dig、nslookup、host三把排查利器排查DNS问题dig是最强大的工具。dig example.com会返回完整的应答包括状态码、标志位、答案段、权威段等。重点看几个地方status是不是NOERRORANSWER SECTION里有没有你要的记录flags里有没有aa权威应答。nslookup更老派但交互式用起来方便host则最简洁适合快速看一眼。我个人的习惯是快速确认用host深入分析用dig交互式反复查用nslookup。一个实用技巧是指定DNS服务器查询dig 8.8.8.8 example.com直接问某个公共DNS用来对比是本地DNS的问题还是权威服务器的问题。如果问公共DNS正常、问本地DNS异常那问题就在本地DNS这一环。5.3 缓存清理不同系统的不同做法改了记录想立刻验证得先清缓存。但DNS缓存是分层的你清了本机的递归解析器那边可能还缓存着。本机层面Linux上如果用了systemd-resolved用resolvectl flush-caches用了nscd的重启nscd服务。Windows上用ipconfig /flushdns。macOS上稍复杂较新版本用sudo dscacheutil -flushcache配合sudo killall -HUP mDNSResponder。但递归解析器的缓存你控制不了只能等TTL过期。所以验证时最可靠的办法是直接问权威服务器dig ns1.example.com example.com绕过所有缓存看权威数据到底是什么。如果权威数据是对的那问题就只是缓存还没过期等着就行。6. 踩过的坑与实战心得6.1 序列号忘记递增从服务器死活不同步前面提过序列号这里展开说一个真实场景。有次我在主服务器上加了条记录本地查询一切正常但从服务器上怎么查都查不到新记录。检查网络、检查allow-transfer、检查防火墙全都没问题。最后盯着区域文件看了半天才发现序列号还是老值。从服务器的同步逻辑是定期去问主服务器你的SOA序列号是多少如果比自己手里的大才发起同步。序列号没变从服务器就认为数据没更新压根不会去拉。所以每次修改区域文件递增序列号是铁律。我现在养成的习惯是改完文件第一件事就是改序列号用日期加序号的方式比如2024010101改成2024010102既直观又不会重复。6.2 正向解析通了反向解析没配正向解析是域名到IP反向解析是IP到域名用的是PTR记录而且它挂在特殊的in-addr.arpa区域下。很多人只配了正向忘了反向。反向解析什么时候重要邮件服务器做反垃圾检查时经常会查发信IP的反向记录没有或者不匹配的邮件容易被判为垃圾。还有一些日志分析、访问统计工具也依赖反向解析把IP翻译成可读的域名。所以如果你的服务涉及邮件或者需要对外提供可识别的身份反向记录别落下。配置反向区域时IP地址是倒着写的。比如192.0.2.10对应的反向区域名是10.2.0.192.in-addr.arpa。这个倒序规则第一次见会觉得别扭记住就好。6.3 TTL设太长的代价TTL设长有好处——减少查询次数、降低权威服务器压力、加快客户端响应。但代价是变更不灵活。我曾经把一个不常变的域名TTL设成了24小时结果后来需要紧急切换IP硬生生等了一整天才全网生效那24小时里一部分用户访问的是旧地址体验很差。现在的做法是稳定期用较大TTL比如几小时到一天计划变更前提前调小。这个提前要留足时间至少是旧TTL的一倍以上确保所有缓存都过期了再动手。变更完成后观察一段时间确认稳定了再调回去。6.4 内网DNS与外网DNS的边界很多公司内网有自己的DNS用来解析内部系统。这里有个常见误区把内网DNS配成只解析内网、其他一律不响应结果员工访问外网时解析不了。正确做法是配置转发——内网域名自己解析其他域名转发给上游的公共DNS。BIND里用forwarders配置转发目标dnsmasq里用server指令。这样既保证了内网解析的私密性和可控性又不影响正常上网。转发配置里还可以设forward first或forward only前者是先问转发目标不行再自己迭代后者是只问转发目标。内网环境一般用forward only把外部解析完全交给上游管理更简单。7. 把DNS当成一门需要持续打理的活DNS这东西配好之后可以很久不出问题但一旦出问题往往表现得很玄学——时好时坏、部分用户受影响、换个网络就正常。这些表象背后几乎都能归结到缓存、TTL、记录配置或者解析链路这几个点上。我的经验是与其等出问题再救火不如平时就把几件事做扎实区域文件改完必查语法、必递增序列号重要变更前先调小TTL正向反向都配齐内网外网用转发划清边界。这些动作花不了多少时间但能挡掉绝大多数故障。最后分享一个我常用的排查口诀先本机、再本地、后权威先缓存、再记录、后链路。按这个顺序走大部分DNS问题都能在几分钟内定位到根因而不是像我最开始那样对着一个域名打不开干着急。DNS不难难的是它太基础基础到大家平时都不愿意花时间真正搞懂它——而恰恰是这种不愿意让它在出问题时显得格外棘手。
1. 从一个让人抓狂的故障说起为什么DNS值得单独拎出来讲刚入行那会儿我遇到过一个至今印象深刻的故障。一台服务器上的Web服务跑得好好的本地用IP访问一切正常但换成域名就时通时不通重启服务、检查防火墙、翻看日志折腾了大半天毫无头绪。最后一位老同事过来敲了两条命令问题定位了——域名解析结果指向了一个早已下线的旧IP。整个过程里服务本身没有任何毛病坏的是名字到地址这条翻译链路。这件事让我意识到DNSDomain Name System域名系统虽然平时默默无闻却是整个网络世界里最不能出问题的基础设施之一。它就像电话簿你记得住张三这个名字但拨号需要的是那串号码DNS干的就是把名字翻译成号码的活。一旦这本电话簿出错、过期或者查不到后面所有的通信都无从谈起。这篇内容我想聊的不是教科书上那种DNS是什么的科普而是从实际运维和配置的角度把DNS的工作原理、常见记录类型、服务端配置、客户端排查这几件事讲透。适合谁看如果你是需要自己搭DNS服务的运维、被域名解析问题折磨过的开发、或者想搞明白为什么改了域名要等一会儿才生效的普通用户这篇都能给你一些能直接上手的东西。我会尽量把每个配置项背后的为什么讲清楚而不是甩一堆参数让你照抄。2. DNS到底在背后做了什么一次解析的完整旅程2.1 递归查询与迭代查询两种角色的分工很多人对DNS的理解停留在输入域名返回IP这一层但真正理解它的工作方式得先分清两个概念递归查询和迭代查询。打个比方。你要找某个陌生人的电话号码但你不知道。你可以去问一个万事通朋友递归解析器你说帮我查一下这个人的号码他要么直接告诉你要么自己去一层层问别人最后把结果给你。你只问了一次这就是递归查询——你委托对方帮你把结果拿到手。而万事通朋友自己是怎么查的呢他先问根服务器这个域名谁管根服务器说你去问某个顶级域服务器他再去问顶级域服务器对方说你去问某个权威服务器最后问到权威服务器才拿到真正的号码。这一层层问过去、每次只拿到下一步该问谁的过程就是迭代查询——每次只得到线索需要自己继续追。理解这个分工很关键。你本机配置的DNS服务器比如运营商给的、或者公司内网的通常扮演递归解析器的角色它负责替你跑完整个迭代过程然后把最终答案缓存下来。这也是为什么第二次访问同一个域名会快很多——答案被缓存了。2.2 缓存与TTL为什么改了记录不能立刻生效这是被问得最多的问题之一我把域名指向改了为什么过了半天还没生效答案就在TTLTime To Live生存时间这个参数上。每条DNS记录都有一个TTL值单位是秒表示这条记录可以被缓存多久。当递归解析器拿到一条记录后它会在本地缓存TTL指定的时间。在这段时间内再有用户来查同一个域名解析器直接返回缓存里的旧结果根本不会去问权威服务器。所以当你修改记录时那些已经缓存了旧记录的解析器要等缓存过期才会去拿新结果。这就是生效延迟的来源。常见的TTL设置从300秒5分钟到86400秒24小时不等。提示如果你计划做一次重要的域名迁移提前把TTL调小比如改成300秒等旧TTL过期后再切换切换完确认无误再调回较大值。这个预热操作能大幅缩短切换期间的混乱窗口。2.3 解析链路中的每一环都可能出问题一次完整的解析涉及本机缓存、hosts文件、本地DNS服务器、递归解析器、根服务器、顶级域服务器、权威服务器等多个环节。任何一环出问题表现都是域名打不开但根因可能天差地别。我习惯按这个顺序排查先看本机缓存和hosts文件最容易忽略再看本地配置的DNS服务器是否可达然后看解析结果是否正确最后才怀疑权威服务器。这个顺序是从近到远、从简单到复杂能帮你快速排除掉大部分低级问题。3. 那些必须搞清楚的记录类型不只是A记录3.1 A、AAAA与CNAME最常用的三兄弟A记录是最基础的把域名指向一个IPv4地址。AAAA记录读作quad-A对应IPv6地址格式上就是多了一倍的位数。这两个是名字到地址的直接映射。CNAME记录Canonical Name别名记录则不同它把一个域名指向另一个域名而不是IP。比如你把www.example.com设成example.com的CNAME那么访问前者时解析器会先找到后者的A记录再返回IP。CNAME的价值在于解耦。假设你有一堆子域名都指向同一台服务器如果直接写A记录服务器换IP时你得改一堆地方用CNAME指向一个主域名只改主域名的A记录就够了。但CNAME有个硬性限制一个域名不能同时存在CNAME和其他记录比如MX因为CNAME会接管整个域名的解析其他记录就没法共存了。这个坑我踩过当时想给一个已经设了CNAME的域名加邮件记录怎么都不生效后来才明白是这个规则在作祟。3.2 MX、TXT、NS、SOA各有各的战场MX记录Mail Exchange指定邮件服务器它带一个优先级数值数值越小优先级越高。发邮件时发送方会按优先级依次尝试。配置邮件服务时MX记录写错或者优先级搞反是邮件发不出去的常见原因。TXT记录最初是用来放任意文本的现在最常见的用途是域名所有权验证和邮件安全策略比如SPF、DKIM这些反垃圾邮件机制。很多云服务商让你加一条TXT记录来证明这个域名是你的就是利用了这个机制。NS记录Name Server指定这个域名由哪些DNS服务器负责解析它决定了权威在哪里。SOA记录Start of Authority则包含了一个区域的核心管理信息比如主服务器、管理员邮箱、序列号、各种刷新和过期时间。SOA里的序列号特别重要——从服务器靠它判断主服务器的数据有没有更新序列号没涨从服务器就不会同步。3.3 记录类型速查与常见误用记录类型作用典型场景常见坑A域名到IPv4网站、服务器忘改导致指向旧IPAAAA域名到IPv6支持IPv6的服务环境不支持IPv6时反而变慢CNAME域名到域名CDN、多子域统一管理与MX等其他记录冲突MX邮件路由企业邮箱优先级数值搞反TXT文本信息验证、邮件策略内容超长需分段NS权威服务器域名托管改NS后需等待传播SOA区域管理信息主从同步序列号忘记递增这张表我建议存下来配置时对照着看能避开不少低级错误。4. 亲手搭一个DNS服务从选型到跑通4.1 为什么选这个方案几种常见DNS服务端对比自己搭DNS常见的选择有几种。BIND是元老级的功能全、资料多但配置文件语法有点反人类dnsmasq轻量适合做本地缓存和简单转发配置极简CoreDNS是较新的选择插件化设计配置用类似配置文件的语法很适合容器化环境PowerDNS则在数据库后端支持上做得很好适合大规模场景。如果你的需求只是给内网做缓存加速少量自定义解析dnsmasq基本够用几十行配置就能跑起来。如果要做权威解析、管理大量区域BIND或PowerDNS更合适。我下面以BIND为例讲配置因为它的概念最完整学会了再迁移到其他工具会轻松很多。4.2 主配置文件与区域文件两个核心概念BIND的配置分两层主配置文件通常是named.conf定义我管理哪些区域、去哪里找区域文件区域文件zone file则具体描述这个区域里有哪些记录。主配置文件里一个典型的区域定义长这样zone example.com IN { type master; file /etc/bind/db.example.com; allow-transfer { 192.0.2.2; }; };这里type master表示这是主服务器file指向区域文件路径allow-transfer限制哪些从服务器可以来同步数据——这个限制很重要不设的话任何人都能拉走你整个区域的记录等于把内网结构暴露了。区域文件则是记录的实际存放地一个简化版本$TTL 3600 IN SOA ns1.example.com. admin.example.com. ( 2024010101 ; 序列号 3600 ; 刷新 1800 ; 重试 604800 ; 过期 86400 ) ; 最小TTL IN NS ns1.example.com. IN A 192.0.2.10 www IN CNAME mail IN A 192.0.2.20 IN MX 10 mail.example.com.几个细节值得说。第一行的$TTL是默认TTL没单独指定的记录都用它。SOA记录里那个2024010101是序列号每次改完区域文件必须递增它否则从服务器不会同步——这是新手最容易忘的一步。符号代表当前区域名本身省得你到处写全称。4.3 配置完必须做的验证动作配置写完不代表能用。我习惯按这几步验证语法检查named-checkconf检查主配置named-checkzone example.com /etc/bind/db.example.com检查区域文件。这两条命令能在重启服务前就发现大部分语法错误省得服务起不来还找不到原因。重启或重载服务改完配置用rndc reload重载比直接重启更平滑。本地查询验证用dig 127.0.0.1 www.example.com直接问本机DNS看返回是否符合预期。序列号确认dig 127.0.0.1 example.com SOA看序列号是不是你刚改的值。注意区域文件里每条记录的域名结尾那个点.千万别漏。ns1.example.com和ns1.example.com.在DNS里是两个完全不同的东西——前者会被自动补上当前区域名变成ns1.example.com.example.com这个错误极其隐蔽我第一次配的时候就被它坑了半天。5. 客户端这边解析配置与排查手法5.1 resolv.conf与解析顺序客户端这边Linux系统主要看/etc/resolv.conf里面用nameserver指定DNS服务器地址可以写多个按顺序尝试。还有个search选项指定搜索域让你输入短名字时自动补全后缀。但要注意很多系统上这个文件是被网络管理工具动态生成的你手动改了重启网络或者重连之后可能被覆盖。要持久化配置得改对应的网络管理配置而不是直接编辑这个文件。这个坑我见过太多次了——有人改完当时好用第二天重启就失效了其实是被覆盖回去了。解析顺序上系统一般先查本机缓存再查/etc/hosts最后才去问DNS服务器。/etc/hosts的优先级很高有时候域名解析异常就是因为这里有一条陈旧的静态映射在捣乱。5.2 dig、nslookup、host三把排查利器排查DNS问题dig是最强大的工具。dig example.com会返回完整的应答包括状态码、标志位、答案段、权威段等。重点看几个地方status是不是NOERRORANSWER SECTION里有没有你要的记录flags里有没有aa权威应答。nslookup更老派但交互式用起来方便host则最简洁适合快速看一眼。我个人的习惯是快速确认用host深入分析用dig交互式反复查用nslookup。一个实用技巧是指定DNS服务器查询dig 8.8.8.8 example.com直接问某个公共DNS用来对比是本地DNS的问题还是权威服务器的问题。如果问公共DNS正常、问本地DNS异常那问题就在本地DNS这一环。5.3 缓存清理不同系统的不同做法改了记录想立刻验证得先清缓存。但DNS缓存是分层的你清了本机的递归解析器那边可能还缓存着。本机层面Linux上如果用了systemd-resolved用resolvectl flush-caches用了nscd的重启nscd服务。Windows上用ipconfig /flushdns。macOS上稍复杂较新版本用sudo dscacheutil -flushcache配合sudo killall -HUP mDNSResponder。但递归解析器的缓存你控制不了只能等TTL过期。所以验证时最可靠的办法是直接问权威服务器dig ns1.example.com example.com绕过所有缓存看权威数据到底是什么。如果权威数据是对的那问题就只是缓存还没过期等着就行。6. 踩过的坑与实战心得6.1 序列号忘记递增从服务器死活不同步前面提过序列号这里展开说一个真实场景。有次我在主服务器上加了条记录本地查询一切正常但从服务器上怎么查都查不到新记录。检查网络、检查allow-transfer、检查防火墙全都没问题。最后盯着区域文件看了半天才发现序列号还是老值。从服务器的同步逻辑是定期去问主服务器你的SOA序列号是多少如果比自己手里的大才发起同步。序列号没变从服务器就认为数据没更新压根不会去拉。所以每次修改区域文件递增序列号是铁律。我现在养成的习惯是改完文件第一件事就是改序列号用日期加序号的方式比如2024010101改成2024010102既直观又不会重复。6.2 正向解析通了反向解析没配正向解析是域名到IP反向解析是IP到域名用的是PTR记录而且它挂在特殊的in-addr.arpa区域下。很多人只配了正向忘了反向。反向解析什么时候重要邮件服务器做反垃圾检查时经常会查发信IP的反向记录没有或者不匹配的邮件容易被判为垃圾。还有一些日志分析、访问统计工具也依赖反向解析把IP翻译成可读的域名。所以如果你的服务涉及邮件或者需要对外提供可识别的身份反向记录别落下。配置反向区域时IP地址是倒着写的。比如192.0.2.10对应的反向区域名是10.2.0.192.in-addr.arpa。这个倒序规则第一次见会觉得别扭记住就好。6.3 TTL设太长的代价TTL设长有好处——减少查询次数、降低权威服务器压力、加快客户端响应。但代价是变更不灵活。我曾经把一个不常变的域名TTL设成了24小时结果后来需要紧急切换IP硬生生等了一整天才全网生效那24小时里一部分用户访问的是旧地址体验很差。现在的做法是稳定期用较大TTL比如几小时到一天计划变更前提前调小。这个提前要留足时间至少是旧TTL的一倍以上确保所有缓存都过期了再动手。变更完成后观察一段时间确认稳定了再调回去。6.4 内网DNS与外网DNS的边界很多公司内网有自己的DNS用来解析内部系统。这里有个常见误区把内网DNS配成只解析内网、其他一律不响应结果员工访问外网时解析不了。正确做法是配置转发——内网域名自己解析其他域名转发给上游的公共DNS。BIND里用forwarders配置转发目标dnsmasq里用server指令。这样既保证了内网解析的私密性和可控性又不影响正常上网。转发配置里还可以设forward first或forward only前者是先问转发目标不行再自己迭代后者是只问转发目标。内网环境一般用forward only把外部解析完全交给上游管理更简单。7. 把DNS当成一门需要持续打理的活DNS这东西配好之后可以很久不出问题但一旦出问题往往表现得很玄学——时好时坏、部分用户受影响、换个网络就正常。这些表象背后几乎都能归结到缓存、TTL、记录配置或者解析链路这几个点上。我的经验是与其等出问题再救火不如平时就把几件事做扎实区域文件改完必查语法、必递增序列号重要变更前先调小TTL正向反向都配齐内网外网用转发划清边界。这些动作花不了多少时间但能挡掉绝大多数故障。最后分享一个我常用的排查口诀先本机、再本地、后权威先缓存、再记录、后链路。按这个顺序走大部分DNS问题都能在几分钟内定位到根因而不是像我最开始那样对着一个域名打不开干着急。DNS不难难的是它太基础基础到大家平时都不愿意花时间真正搞懂它——而恰恰是这种不愿意让它在出问题时显得格外棘手。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
