★ FEATURED ARTICLE DNS 这个东西做运维的、写后端的、备考软考高级架构师的几乎天天挂在嘴边但真要把它讲透很多人脑子里只有一句“把域名变成 IP”。我当年第一次系统梳理 DNS 是在准备架构师考试的时候那会儿才发现平时用得顺手的解析背后藏着一整套分层、缓存、递归迭代的设计哲学而这些恰恰是架构师考试爱考、实际工作也最容易踩坑的地方。这篇内容就是把我自己复习 DNS 概念和查询方式时的笔记、踩过的坑、以及考试里反复出现的考点揉在一起讲清楚 DNS 到底是什么、查询方式有哪几种、递归和迭代到底怎么区分、缓存和 TTL 在架构层面意味着什么。不管你是正在备考软考高级架构师还是日常要排查解析故障看完都能对 DNS 有一套能落地、能讲明白的认知。1. DNS 在架构师知识体系里的定位与核心概念拆解1.1 为什么架构师考试绕不开 DNS很多人觉得 DNS 就是个基础设施属于网络管理员的事跟架构师有什么关系。我一开始也这么想直到做题时发现DNS 相关的题目往往不是单独考“域名转 IP”而是嵌在系统可用性、负载均衡、跨地域部署、故障排查这些综合场景里。比如一道题描述某系统在多地部署问如何通过 DNS 实现流量调度选项里就涉及权威服务器、TTL 设置、CNAME 记录这些概念。你要是只记住“DNS 是域名解析”这种题根本没法下手。从架构视角看DNS 本质是一个全球分布式的、分层授权的命名与寻址系统。它解决的核心问题是在一个人人用名字、机器用地址的世界里如何高效、可靠、可扩展地把名字映射到地址并且允许各个组织自己管理自己那部分名字空间。这个“分层授权”的思想跟微服务里的服务发现、配置中心的分区管理其实是同一套逻辑。理解了 DNS 的设计动机你再看那些架构题会发现考的是你对“分布式命名系统”这个抽象的理解而不是死记硬背记录类型。所以我在复习时给自己定的目标是不光要知道 DNS 怎么查还要能说清楚它为什么这么设计、每一层为什么存在、缓存为什么必须有、TTL 为什么是个权衡参数。这些“为什么”才是架构师考试真正想筛的东西也是实际做系统设计时能迁移的能力。1.2 域名空间的分层结构与命名规则DNS 的域名空间是一棵倒挂的树根在最上面下面是顶级域再往下是二级域、子域一层层往下分。这个结构不是随便定的它直接决定了查询的走向。根域用点表示顶级域就是 com、net、org、cn 这些二级域比如 example.com再往下还可以有 mail.example.com、api.example.com 这样的子域。这里有个容易被忽略的细节域名是从右往左读的越往右层级越高。www.example.com 里com 是顶级域example 是二级域www 是主机名。考试里偶尔会拿这个做文章比如问某个域名的父域是谁你要是从左往右理解就错了。我复习时专门在纸上画过这棵树把常见域名一个个标上去画完一遍基本就不会再搞混层级关系。命名规则上每一级标签最长 63 个字符整个域名最长 253 个字符标签里可以用字母、数字和连字符但不区分大小写。这些数字看着琐碎但考试选择题里真出现过“下列哪个域名合法”这种题靠的就是这些边界。实际工作中虽然很少碰到超长域名但知道这个限制在生成子域名、做多租户隔离时心里有数不至于设计出违反规范的命名方案。还有一点值得强调域名空间的授权是逐级下放的。根服务器只管顶级域com 的服务器只管 com 下面的二级域example.com 的权威服务器只管自己这一摊。这种“谁的地盘谁负责”的授权模式是 DNS 能扩展到全球规模的根本原因。任何一个组织想加子域只需要在自己的权威服务器上加记录不用惊动上层这就是分布式系统的精髓。1.3 资源记录类型架构师必须分清的那几种DNS 里存的东西叫资源记录简称 RR。记录类型很多但架构师考试和实际工作里高频的就那么几种我把它们整理成一张表方便对照记忆。记录类型作用典型场景架构含义A域名映射到 IPv4 地址普通网站、服务入口最基础的寻址记录AAAA域名映射到 IPv6 地址支持 IPv6 的服务双栈部署必备CNAME域名别名指向另一个域名CDN 接入、多域名统一入口解耦便于切换后端MX邮件交换记录邮件系统带优先级支持多邮件服务器NS指定该域的权威服务器域委托分层授权的落地方式PTR反向解析IP 到域名日志分析、安全校验与 A 记录方向相反SOA起始授权记录含域的管理信息每个域必须有且仅有一条含序列号、刷新间隔等参数TXT文本记录域名验证、SPF 等灵活常被用作扩展载体这张表里CNAME 和 NS 是架构题的高频考点。CNAME 的价值在于解耦你对外暴露一个稳定域名内部指向随时可变的另一个域名后端换 IP、换机房外部完全无感。CDN 接入就是典型用法你把 www 指向 CDN 厂商给的域名厂商在背后调度你什么都不用改。NS 记录则是分层授权的具体体现父域通过 NS 记录告诉全世界“这个子域归那几台服务器管”查询才能继续往下走。SOA 记录容易被忽视但它里面的参数很有讲究。序列号用于主从服务器同步判断新旧刷新间隔、重试间隔、过期时间、最小 TTL 这几个字段直接决定了域数据在主从之间同步的节奏。做高可用架构时如果 SOA 参数配得不合理主服务器挂了从服务器可能还拿着旧数据或者同步过于频繁造成压力。这些细节考试不一定直接考但理解了对设计权威 DNS 架构很有帮助。2. 查询方式的核心原理递归与迭代到底怎么区分2.1 从一次完整解析看查询的全过程要讲清楚查询方式最好的办法是跟着一次真实解析走一遍。假设你在浏览器里输入一个域名本机先查自己的 hosts 文件和本地 DNS 缓存没有的话就发给配置的本地域名服务器也就是常说的递归服务器。这台服务器通常由运营商或者公司内网提供它接到请求后先看自己的缓存有就直接返回没有就开始替你去问。它先问根服务器根服务器不会直接给答案而是告诉你“com 这个顶级域归这几台服务器管你去问它们”。递归服务器再去问 com 的服务器com 的服务器同样不给最终答案而是说“example.com 归这几台权威服务器管”。递归服务器继续问 example.com 的权威服务器这次终于拿到了最终的 A 记录。递归服务器把结果返回给你同时按 TTL 缓存起来下次别人再问同一个域名它直接从缓存里给。这个过程里你只跟本地递归服务器打了一次交道剩下的活全是它替你干的这就是递归查询的含义——你委托它它负责把最终结果拿回来。而递归服务器跟根、跟 com、跟权威服务器之间的那几次问答每次都是“你告诉我下一步该问谁”这就是迭代查询。理解这个分工递归和迭代就不会再混。2.2 递归查询委托到底结果必达递归查询的核心特征是结果要么是最终答案要么是明确的错误中间过程不甩锅。客户端发出递归请求后就等着收最终结果不需要自己再去追问。这个模式对客户端极其友好因为客户端往往能力有限比如一个嵌入式设备、一个简单的应用它没能力也没必要去遍历整个域名树。本地域名服务器对客户端提供的通常就是递归服务。你在自己电脑上配的 DNS 地址指向的那台服务器默认就是给你做递归的。它承担了所有的查询工作包括缓存、重试、跟随 CNAME 链等等。这也是为什么递归服务器压力大、容易被滥用实际部署时通常只对可信客户端开放递归否则就成了被人利用来放大攻击的跳板。从架构角度看递归查询体现的是责任集中把复杂性收敛到少数有能力的节点上让大量简单客户端保持轻量。这个思路跟 API 网关把鉴权、限流、路由都收拢起来让后端服务专注业务是一个道理。考试里问“递归查询的特点”答案往往落在“服务器代为完成全部查询、返回最终结果”这个点上。2.3 迭代查询指路为主逐级推进迭代查询的特征是每次只告诉你下一步去哪问不替你跑腿。根服务器收到迭代请求返回的是 com 的 NS 记录和对应的地址com 服务器返回的是 example.com 的 NS 记录权威服务器才给出最终答案。每一方只负责自己这一层的信息把下一跳指清楚就算完成任务。这种模式的好处是每台服务器只承担自己那部分职责负载分散扩展性好。根服务器全球就那么些如果它要对每个查询都做递归、把最终结果拿回来早就撑不住了。迭代让根服务器只需要回答“com 归谁管”这种极轻量的问题把重活分散到各级服务器和递归服务器身上。实际中递归服务器对上游用的是迭代客户端对递归服务器用的是递归两者配合才构成了完整的解析链路。我复习时总结了一句话递归是“你帮我办到底”迭代是“你告诉我找谁办”。这句话在考试里判断题型特别管用看到“返回下一级服务器地址”就选迭代看到“返回最终结果”就选递归。2.4 一张表把两种查询方式彻底分清光靠文字容易记混我把递归和迭代的关键差异整理成对照表复习时扫一眼就能回忆起来。对比维度递归查询迭代查询谁承担查询工作被请求的服务器全程负责请求方自己逐级去问返回内容最终结果或错误下一级服务器地址NS 记录典型使用方客户端对本地 DNS 服务器本地 DNS 服务器对上级服务器服务器压力集中在递归服务器分散到各级服务器缓存位置递归服务器缓存最终结果各级服务器缓存下级授权信息架构思想责任集中客户端轻量职责分散扩展性好这张表里我特意加了“架构思想”一行因为架构师考试喜欢从设计理念角度出题。你把这两种模式和“集中式 vs 分布式”的取舍联系起来遇到综合题就能往这个方向靠。比如题目问某大型系统如何设计解析架构以支撑海量请求思路就是前端用递归服务器做缓存收敛后端靠迭代逐级授权保证可扩展两者结合。3. 缓存、TTL 与解析链路中的架构权衡3.1 缓存为什么是 DNS 性能的命脉DNS 如果没有缓存每一次解析都要从根一路问到权威全球的查询量会把根和顶级域服务器压垮延迟也高得没法用。缓存的存在让绝大多数查询在本地递归服务器就能命中只有少量未命中的才真正走完整链路。可以说缓存是 DNS 能撑起今天这个规模的根本前提。缓存分布在多个层级浏览器有自己的缓存操作系统有 DNS 缓存本地递归服务器有缓存甚至有些应用框架自己也会缓存解析结果。每一层缓存都在减少下一层的压力。我排查过一次线上问题应用侧改了域名指向但部分用户还是访问到旧地址最后发现是某一层缓存没到期。这件事让我深刻体会到缓存带来性能的同时也带来了一致性延迟这是架构上必须接受的权衡。从架构师视角缓存的设计要考虑命中率、过期策略、容量、以及缓存穿透和缓存雪崩的应对。DNS 缓存虽然由协议和服务器实现但你在设计系统时选择 TTL 长短、是否在应用层再加一层缓存、缓存失效时如何降级这些都是实打实的架构决策。考试里如果出现“如何降低 DNS 解析延迟”这类题答案往往围绕增加缓存层级、合理设置 TTL 展开。3.2 TTL一个数字背后的可用性与一致性博弈TTL 是资源记录里的生存时间单位是秒它决定了这条记录能被缓存多久。这个数字看着简单背后却是一场可用性与一致性的博弈。TTL 设得长缓存命中率高解析快上游服务器压力小但记录变更后旧值会在缓存里存活很久切换不灵敏。TTL 设得短变更传播快切换灵活但缓存命中率下降查询量上升解析延迟增加上游压力变大。没有绝对最优只有场景适配。我总结了一套实际可用的取值思路稳定不变的基础设施记录TTL 可以设长比如几小时甚至一天可能频繁调整的业务入口TTL 设短比如几分钟到十几分钟做重大切换前提前把 TTL 调短等旧缓存自然过期后再切切完稳定了再调回来。这套“预热调短、切换、恢复”的操作是很多团队做域名迁移时的标准动作考试里也常以场景题形式出现。提示做域名切换前务必提前至少一个原 TTL 周期把 TTL 调短否则旧记录还在缓存里切换后会有相当一部分用户仍然访问旧地址。这个提前量经常被忽略导致切换“看起来生效了实际没完全生效”。3.3 解析链路中的故障点与降级思路一条完整的解析链路涉及客户端、本地递归服务器、根、顶级域、权威服务器多个环节任何一环出问题都可能导致解析失败。实际排查时我习惯按链路顺序逐段验证先看本机 hosts 和缓存再看本地递归服务器是否可达、是否能正常递归然后看权威服务器是否正常响应、记录是否配置正确。常见的故障点有这么几类本地 DNS 配置错误或不可达表现为所有域名都解析不了递归服务器缓存了错误记录表现为个别域名异常且持续时间与 TTL 吻合权威服务器故障或记录配错表现为该域下所有解析都出问题域名过期或被暂停表现为解析直接返回不存在。针对不同环节降级思路也不同比如本地递归不可用时切换到备用 DNS权威故障时靠多台权威服务器和从服务器兜底。架构设计上权威服务器要多地多台部署NS 记录里配置多个这样单点故障不至于让整个域失联。递归层面客户端配置主备两个 DNS 地址主不可用自动切备。这些措施看着基础但真正出事时就是救命稻草。我在复习时把这些故障点和对应现象整理成了一张速查表做题时看到“某域解析全部失败”就能快速定位到权威或域名状态层面。4. 实操排查与常见问题实录4.1 用命令行工具验证解析链路理论讲再多不如动手查一遍。我平时排查 DNS 问题最常用的就是几个命令行工具这里把用法和判读方法说清楚都是可以直接抄作业的。先看本机配置的 DNS 服务器和本地缓存情况。Windows 下用ipconfig /all看 DNS 配置ipconfig /displaydns看本地缓存Linux 下看/etc/resolv.conf里的 nameserver用systemd-resolve --statistics或resolvectl status看解析器状态。这一步能快速确认“是不是本机 DNS 配错了”。然后是核心的查询工具。nslookup和dig是最常用的两个dig信息更全我一般优先用它。# 查询 A 记录看最终解析结果 dig www.example.com A # 指定向某个 DNS 服务器查询用于对比不同服务器的结果 dig 8.8.8.8 www.example.com A # 跟踪完整解析链路看每一级返回了什么 dig trace www.example.com # 查询 NS 记录确认权威服务器配置 dig example.com NS # 查询 SOA 记录看序列号和各类时间参数 dig example.com SOAdig trace这个用法特别值得掌握它会把从根开始的迭代过程一步步打印出来你能清楚看到根返回了哪些顶级域服务器、com 返回了哪些权威服务器、最后权威服务器给了什么答案。复习迭代查询时我对着这个输出看一遍比看十页书都直观。判读输出时重点看status字段NOERROR是正常NXDOMAIN是域名不存在SERVFAIL通常是服务器故障或配置问题。4.2 典型问题速查与排查思路实际工作中遇到的 DNS 问题翻来覆去就那么几类。我把高频问题和排查思路整理成表出问题时对着走一遍基本能定位到根因。现象可能原因排查动作所有域名都解析不了本地 DNS 配置错误或网络不通检查 resolv.conf 或网卡 DNS 设置ping 一下 DNS 服务器个别域名解析失败该域权威服务器故障或记录配错dig 指定权威服务器直接查看是否响应解析到旧地址缓存未过期TTL 未到dig 看 TTL 剩余对比不同递归服务器结果解析时好时坏多台权威服务器中有一台异常逐个查 NS 记录里的服务器看哪台不响应返回 NXDOMAIN域名不存在、过期或拼写错误核对域名拼写查域名状态和 NS 配置解析慢但能成功递归链路长、缓存命中率低看 TTL 设置考虑增加本地缓存这张表里“解析时好时坏”是最容易被误判的。很多人第一反应是网络抖动实际往往是 NS 里配了多台权威服务器其中一台挂了或者记录不一致查询随机落到不同服务器上表现就是时好时坏。排查方法就是逐个去查 NS 里列出的每一台看是不是有一台不响应或者返回不同结果。这个坑我踩过当时查了半天网络最后发现是某台权威服务器同步出了问题。4.3 备考与实操中的经验心得备考软考高级架构师这段时间我最大的体会是DNS 的考点几乎都藏在“为什么”里而不是“是什么”里。单纯记记录类型、记递归迭代定义做题时稍微换个场景就懵。但如果你理解了分层授权是为了可扩展、缓存是为了性能、TTL 是可用性与一致性的权衡、递归迭代是责任集中与分散的取舍那些综合题、场景题就有了分析的抓手。实操上我建议把dig trace当成日常习惯遇到任何解析相关的疑惑先 trace 一遍看链路在哪一环断了或者慢了。这个动作花不了几秒钟但能省下大量猜测时间。另外做任何域名变更前先想清楚 TTL 的提前量把“调短 TTL、等待过期、执行变更、验证、恢复 TTL”当成一个固定流程别图省事直接改否则出了问题排查成本远高于提前准备的成本。还有个小技巧排查解析问题时多用几个不同的公共递归服务器对比结果比如分别向几个知名的公共 DNS 查询同一域名如果结果不一致基本可以确定是缓存或同步问题而不是记录本身配错。这个对比法能快速缩小问题范围比盯着一个服务器反复查有效得多。最后再分享一个我在复习时用的方法把 DNS 的整个解析过程画成一张时序图标出每一步是谁问谁、返回什么、缓存在哪。画完之后递归和迭代的区别、缓存的位置、TTL 的作用全都在图上了。考试前扫一眼这张图比翻笔记快得多。这个方法对理解其他分布式协议同样适用本质上是把抽象流程可视化逼着自己把每个环节都想清楚。
阅读完成 · 觉得有帮助？
