DNS 这个东西平时写业务代码的人很少主动去碰但一到软考高级架构师的考场上它就成了绕不开的硬骨头。我当年备考的时候翻遍了各种资料发现大部分材料要么把 DNS 讲成一本协议手册要么直接甩一张递归查询的流程图就完事真正能把“为什么这么设计”“考试到底考哪几个点”讲透的少之又少。这篇内容就是把我自己啃 DNS 这块的经历整理出来从概念本质到查询方式的每一个细节结合架构师考试的实际考法把这块知识彻底拆开揉碎。不管你是刚开始准备软考的小白还是已经做过几年开发、想系统梳理网络基础的老手看完应该都能对 DNS 有一个跟以前不太一样的理解。1. 先搞清楚 DNS 在架构师知识体系里到底占什么位置很多人备考软考高级架构师的时候会把大量精力砸在架构风格、设计模式、分布式这些“看起来更高级”的内容上对 DNS 这种“基础网络知识”下意识地降低优先级。我一开始也是这个心态觉得 DNS 不就是个域名解析嘛能有多难。结果做真题的时候发现DNS 相关的题目出得相当刁钻不是简单问你“DNS 是什么”而是嵌在系统设计、性能优化、高可用方案这些场景里考。1.1 为什么架构师考试对 DNS 情有独钟站在出题人的角度想一想就明白了。DNS 是整个互联网基础设施里最典型的一个“分布式系统”案例它同时涉及分层设计、缓存策略、负载均衡、容灾切换、安全防护这几个架构师必须掌握的核心能力。换句话说DNS 本身就是一个天然的架构设计样本考 DNS 其实是在考你对分布式系统设计思想的理解。举个具体的例子。软考里经常出现这样的场景题某系统需要支撑海量用户访问问你在域名解析层面可以做哪些优化。标准答案里会涉及 DNS 轮询、智能解析、CDN 调度这些内容。如果你只把 DNS 当成“把域名翻译成 IP”的工具这道题基本就废了。但如果你理解 DNS 的分布式本质知道它天然支持多级缓存和多记录返回就能顺着这个思路展开。我在复盘真题的时候做过一个统计DNS 相关知识点在架构师考试中的出现形式大致有这么几类一是概念辨析题考递归查询和迭代查询的区别二是记录类型题考 A、CNAME、MX、NS 这些记录各自的作用三是场景设计题把 DNS 和负载均衡、高可用结合起来考四是故障分析题给你一个解析异常的案例让你排查。这四类题目覆盖了 DNS 知识的各个层面也正好对应了我在后面几个章节要展开的内容。1.2 把 DNS 当成一个分布式数据库来理解我后来找到一个特别好用的理解角度把 DNS 看成一个全球分布式的、超大规模的键值数据库。键就是域名值就是各种资源记录。这个数据库的特点是读多写少、分层管理、多级缓存。你用这个视角去看 DNS 的很多设计会发现一切都顺理成章。为什么 DNS 要设计成树状层级结构因为集中式管理一个全球数据库根本不可能数据量太大、更新太频繁、单点故障风险太高。分层之后每个层级只管自己那一块根服务器管顶级域顶级域服务器管二级域逐级下放管理权限这就是典型的分布式治理思路。为什么 DNS 要有缓存因为每次解析都从根开始走一遍完整链路延迟太高、根服务器压力太大。缓存本质上是用空间换时间把解析结果暂存在离用户更近的地方下次直接命中。这个思路跟我们在系统设计里加 Redis 缓存是一个道理。为什么 DNS 默认用 UDP 而不是 TCP因为解析请求本身很小一个包就能装下用 UDP 省掉了三次握手的开销响应更快。当然现在也有 DNS over TCP、DNS over HTTPS 这些方案那是为了解决 UDP 传输的安全性和可靠性问题属于进阶内容考试里偶尔会提一嘴。用“分布式键值数据库”这个类比去打底后面再学具体的查询流程和记录类型就不会觉得是在死记硬背了而是能理解每一步设计背后的动机。2. 域名空间的分层结构从根到叶的完整拆解要真正搞懂 DNS 的查询方式必须先弄清楚域名空间是怎么组织的。这块内容看起来简单但里面的细节特别多考试也爱在这些细节上做文章。2.1 根域、顶级域、二级域到底怎么划分DNS 的域名空间是一棵倒挂的树最顶端是根域用一个点“.”表示。根域下面是顶级域再往下是二级域、三级域一直往下延伸。我们平时看到的域名比如 www.example.com完整写法其实是 www.example.com.最后那个点就是根域只是平时省略不写。顶级域分两类。一类是通用顶级域比如 .com、.org、.net、.edu 这些按用途划分另一类是国家或地区顶级域比如 .cn、.jp、.uk 这些按地理区域划分。软考里有时候会考你某个域名属于哪一类顶级域这种题属于送分题但前提是你得知道分类规则。二级域就是我们平时注册的那个主体部分比如 example.com 里的 example。二级域下面可以继续划分子域比如 mail.example.com、blog.example.com这些子域的管理权归二级域的持有者所有想怎么划就怎么划。这一点很重要它体现了 DNS 分层管理的核心思想每一层只负责自己管辖范围内的解析上级不关心下级内部怎么组织。我在理解这块的时候用了一个公司组织架构的类比。根域相当于集团总部顶级域相当于各个事业部二级域相当于事业部下面的具体业务线子域相当于业务线下面的小组。总部只告诉你找哪个事业部事业部只告诉你找哪条业务线业务线再告诉你具体找谁。每一层只知道自己下一层的信息不需要知道全貌。这个类比帮我记住了整个层级关系也理解了为什么 DNS 查询要逐级进行。2.2 区域和域不是一回事这是很多人容易混淆的一个点也是考试里经常挖坑的地方。域是一个逻辑概念指的是域名空间里的一棵子树区域是一个物理概念指的是某台 DNS 服务器实际管理的那部分数据。举个例子。example.com 这个域可能被划分成两个区域一个区域管 example.com 本身和它下面的主机记录另一个区域管 sub.example.com 这个子域。这两个区域可以放在同一台服务器上也可以放在不同的服务器上。域是“应该管什么”区域是“实际由谁管、管哪些”。为什么要把域和区域区分开因为实际部署中一个域的数据可能分散在多台服务器上也可能多台服务器互为备份管理同一个区域。区域是 DNS 数据复制和同步的基本单位主服务器和辅助服务器之间同步的就是区域数据。考试里如果问你“主从 DNS 服务器同步的是什么”答案就是区域数据不是整个域的数据。2.3 域名服务器的四种角色DNS 体系里的服务器按角色分主要有四类这个分类在考试里出现的频率很高必须记牢。服务器类型核心职责数据来源典型场景根域名服务器返回顶级域服务器的地址内置根区文件解析链路的起点顶级域名服务器返回二级域服务器的地址管理对应顶级域解析 .com、.cn 等权威域名服务器返回域名最终的解析结果管理具体区域数据域名持有者自己维护本地域名服务器代理用户发起查询并缓存结果缓存加转发运营商或企业内网这四类服务器里前三类是层级关系逐级下放本地域名服务器比较特殊它不在层级结构里而是用户和层级结构之间的代理。你电脑上配置的那个 DNS 地址指向的就是本地域名服务器也叫递归服务器或缓存服务器。权威服务器和本地服务器的区别是考试重点。权威服务器是数据的“源头”它给出的答案具有权威性不带缓存本地服务器是“二传手”它从权威服务器那里拿到答案后缓存起来下次有人问直接给缓存。判断一道题里某台服务器是权威还是本地关键看它管理的数据是不是自己维护的原始数据。3. 递归查询和迭代查询把这两个概念彻底掰开递归查询和迭代查询是 DNS 这块最核心的考点没有之一。我见过的真题里十道 DNS 题至少有六道跟这个有关。但很多人学的时候只是背了“递归是帮你查到底迭代是告诉你下一步找谁”这句话真到做题或者实际排查问题的时候就懵了。这一章我把这两个概念从原理到实际表现彻底讲清楚。3.1 递归查询客户端当甩手掌柜递归查询的本质是“你问我我负责给你最终答案”。客户端把请求发给本地域名服务器然后就等着中间本地服务器去根服务器、顶级服务器、权威服务器转了一大圈最后把结果返回给客户端。对客户端来说它只发了一次请求只收了一次响应中间的曲折它完全不知道。用生活场景类比一下。你去一家大公司办事前台本地域名服务器跟你说“你坐着等我帮你跑”。前台先打电话问总部根服务器该找哪个部门总部说找事业部顶级服务器前台又打电话问事业部该找哪个科室事业部说找具体业务线权威服务器前台再打电话问业务线要具体信息最后把结果拿回来告诉你。整个过程你只跟前台打了一次交道。递归查询的关键特征是查询的负担全部压在接收请求的那台服务器上。本地域名服务器要负责把整条链路走完任何一环出问题它都得处理。这也是为什么本地域名服务器通常由运营商或大型企业来维护因为它的负载很重需要足够的资源和带宽。在实际网络里客户端到本地域名服务器这一段用的就是递归查询。你电脑上配的那个 DNS 地址你向它发请求它就必须给你最终结果不能跟你说“你去问别人”。这是 DNS 协议规定的行为。3.2 迭代查询每台服务器只指路不带路迭代查询的本质是“你问我我告诉你下一步该问谁你自己去问”。本地域名服务器在迭代查询模式下先问根服务器根服务器说“我不知道具体答案但 .com 的服务器地址是某某你去问它”本地服务器再去问 .com 服务器对方说“我也不知道但 example.com 的服务器地址是某某你去问它”本地服务器再问 example.com 的权威服务器这次终于拿到了最终答案。还是用公司办事的类比。这次前台不帮你跑了而是告诉你“这事归事业部管你自己去事业部问”。你跑到事业部对方说“这事归业务线管你自己去业务线问”。你一层层自己跑最后在业务线那里拿到结果。每一层只告诉你下一层在哪不替你跑腿。迭代查询的关键特征是查询的负担分散在各台服务器上每台只负责指路。根服务器每天要处理海量查询如果每个查询都要它帮忙跑到底早就崩了。迭代查询让根服务器只需要回答“下一个该找谁”这种简单问题大大降低了它的负载。这也是 DNS 能支撑全球规模查询的重要原因。3.3 两种查询方式的完整链路对比把两种方式放在一起对比链路走向是这样的递归查询链路客户端视角客户端向本地域名服务器发起递归查询请求本地域名服务器检查缓存未命中则代为查询本地服务器依次向根、顶级、权威服务器发起迭代查询本地服务器拿到结果缓存后返回给客户端客户端收到最终答案迭代查询链路本地服务器视角本地服务器向根服务器发起迭代查询根服务器返回顶级域服务器地址本地服务器向顶级域服务器发起迭代查询顶级域服务器返回权威服务器地址本地服务器向权威服务器发起迭代查询权威服务器返回最终解析结果这里有个特别容易搞混的点客户端到本地服务器是递归本地服务器到层级服务器是迭代。这是实际网络中的标准做法也是考试最爱考的组合。很多人背的时候把这两个搞反了做题就全错。为什么这么设计因为客户端通常资源有限、能力有限让它自己去逐级查询不现实所以交给本地服务器代劳递归。而本地服务器如果对每一级都用递归那根服务器就要承担海量的递归查询压力太大所以层级之间用迭代每台服务器只指路迭代。这个设计逻辑理解了就不会记混。3.4 一道典型真题的拆解思路我拿一道常见的真题类型来演示怎么用上面的知识解题。题目大意是某主机向本地域名服务器查询某域名的 IP 地址本地域名服务器缓存中没有该记录请描述完整的查询过程。解题的时候要分两段写。第一段写客户端到本地服务器客户端发起递归查询本地服务器收到后检查缓存未命中则开始代为查询。第二段写本地服务器到层级结构本地服务器先向根服务器发起迭代查询根服务器返回对应的顶级域服务器地址本地服务器再向顶级域服务器发起迭代查询得到权威服务器地址最后向权威服务器查询拿到最终 IP 地址缓存后返回给客户端。答题的时候有几个细节要注意。一是要明确说出“递归”和“迭代”这两个词分别用在哪一段不能含糊二是要提到缓存检查这个步骤很多人漏掉三是要说清楚每一级返回的是什么地址还是最终结果根和顶级返回的是下一级服务器地址权威返回的是最终解析结果。这三点写全了这道题基本满分。4. 资源记录类型DNS 数据库里到底存了什么DNS 服务器返回的每一条解析结果本质上都是一条资源记录。不同的记录类型承载不同的信息考试里经常考你某个场景该用哪种记录。这一章把常见的记录类型逐个讲清楚重点讲每种记录的使用场景和容易踩的坑。4.1 A 记录和 AAAA 记录最基础的地址映射A 记录是把域名映射到 IPv4 地址AAAA 记录是把域名映射到 IPv6 地址。这两个是最基础、最常用的记录类型几乎所有域名都至少有一条 A 记录或 AAAA 记录。A 记录的一个域名可以对应多条记录这就是 DNS 轮询实现负载均衡的基础。比如 www.example.com 配置三条 A 记录分别指向三台服务器DNS 服务器返回时会轮换顺序客户端通常取第一条这样请求就分散到三台服务器上了。这种负载均衡方式成本极低但有个明显缺陷它不感知后端服务器的实际状态某台服务器挂了DNS 照样把请求往那台指。所以生产环境里通常要配合健康检查来动态调整记录。考试里关于 A 记录的坑主要在 TTL 上。TTL 是记录的生存时间决定了缓存多久失效。TTL 设得太长服务器 IP 变了之后客户端还在用旧地址切换慢TTL 设得太短缓存命中率低解析请求都打到权威服务器上压力大。这个权衡在系统设计题里经常出现答题时要体现出你对这个矛盾的理解。4.2 CNAME 记录别名背后的灵活性CNAME 记录把一个域名指向另一个域名相当于给域名起了个别名。比如把 www.example.com 指向 example.com或者把 blog.example.com 指向某个托管平台的域名。CNAME 最大的价值是解耦。假设你的服务部署在某个云平台上平台给你分配了一个域名你用 CNAME 把自己的域名指过去。将来换平台了只需要改 CNAME 的目标自己的域名不用动用户无感知。这种灵活性在架构设计里非常重要。但 CNAME 有几个硬性限制必须记住。第一CNAME 记录不能和同名的其他记录共存一个域名配了 CNAME就不能再配 A 记录、MX 记录等。第二根域名也就是裸域比如 example.com 不带 www通常不建议配 CNAME因为根域名往往还要配 MX 记录和 NS 记录会冲突。第三CNAME 链不宜过长每多一层就多一次解析延迟增加。考试里常考的一个场景是某公司要把网站迁移到新平台要求迁移过程中用户访问不受影响问怎么配置。标准思路就是用 CNAME 做过渡先把域名 CNAME 到新平台验证没问题后再逐步切换。这个思路体现的就是 CNAME 的解耦价值。4.3 MX、NS、PTR各有专长的记录类型MX 记录指定邮件服务器的地址可以配多条并带优先级数字越小优先级越高。邮件系统发信时会先查目标域名的 MX 记录按优先级依次尝试。这个优先级机制保证了邮件服务器的主备切换。NS 记录指定某个域由哪台域名服务器来管理是域名委派的核心。你在注册商那里注册域名时填的就是 NS 记录告诉全世界“这个域归这几台服务器管”。NS 记录直接决定了权威服务器是谁是 DNS 层级结构能够运转的关键。PTR 记录是反向解析记录把 IP 地址映射回域名跟 A 记录正好相反。它的用途主要是邮件服务器的反垃圾验证和日志分析。很多邮件服务商收到邮件时会查发信 IP 的 PTR 记录如果 PTR 记录跟发信域名对不上就可能被判为垃圾邮件。这个点在系统设计题里偶尔会涉及属于加分项知识。4.4 记录类型的选型对照表把常见记录类型的使用场景整理成表方便对照记忆记录类型作用典型场景注意事项A域名到 IPv4 地址网站、API 服务可配多条做轮询AAAA域名到 IPv6 地址IPv6 环境与 A 记录配合使用CNAME域名到域名别名迁移、托管、CDN不能与其他记录共存MX指定邮件服务器企业邮箱带优先级可配多条NS指定权威服务器域名委派决定解析链路走向PTRIP 到域名反向解析邮件验证、日志需要向 IP 持有方申请TXT文本说明信息域名验证、安全策略内容灵活用途广泛TXT 记录虽然不在传统四大记录里但实际使用越来越广泛域名所有权验证、邮件安全策略配置都靠它。考试里如果出现“如何验证域名所有权”这类题答案往往就是配一条特定的 TXT 记录。5. 缓存机制DNS 性能的命脉所在DNS 能支撑全球规模的查询量缓存功不可没。没有缓存的话每次访问网站都要从根服务器开始走完整链路互联网早就瘫痪了。缓存这块在考试里考得不算最多但一旦考到就是区分度很高的题因为它涉及 TTL、缓存位置、缓存更新这些有深度的内容。5.1 缓存分布在哪些环节DNS 缓存不是只有一层而是分布在整条链路的多个环节。从近到远大致有这么几层浏览器缓存、操作系统缓存、本地域名服务器缓存、上级缓存服务器缓存。浏览器缓存是最靠近用户的Chrome、Firefox 这些浏览器都会缓存解析结果有效期通常比较短。操作系统缓存是系统级别的Windows 和 Linux 都有自己的 DNS 缓存机制。本地域名服务器缓存是最大的一层运营商或企业的递归服务器会缓存大量解析结果命中率很高。这个多层缓存结构带来的一个直接后果是域名解析变更后生效不是瞬间的而是要等各级缓存过期。这就是为什么改 DNS 记录后经常要等一段时间才生效业内叫“DNS 传播”其实不是传播是各级缓存陆续过期。理解这一点在系统设计题里讨论变更方案时就能体现出深度。5.2 TTL 的权衡艺术TTL 是缓存控制的核心参数它的设置是一门权衡艺术。TTL 长缓存命中率高解析快权威服务器压力小但变更生效慢TTL 短变更生效快但缓存命中率低解析请求多权威服务器压力大。实际生产中的常见做法是分场景设置。稳定的服务用较长的 TTL比如几小时甚至一天需要频繁切换的服务用较短的 TTL比如几分钟。还有一种做法是变更前临时调短 TTL等变更完成、缓存都过期后再调回长 TTL这样兼顾了平时的性能和变更时的灵活性。考试里如果出现“如何缩短 DNS 变更生效时间”这类题标准答案就是调短 TTL同时配合提前操作。答题时如果能提到“变更前先调短 TTL 等待旧缓存过期变更后再恢复”这个完整流程就是高分答案。5.3 缓存带来的典型故障场景缓存机制虽然好但也带来了一些典型故障。最常见的是“缓存污染”也就是缓存里存了错误的解析结果导致用户访问到错误的地址。这种情况可能是配置错误、也可能是恶意攻击导致的。排查这类问题的思路是逐层验证。先在客户端用 nslookup 或 dig 查看返回什么再直接向权威服务器查看权威数据是什么两者对比如果权威数据正确而客户端拿到的是错的说明中间某层缓存有问题。定位到具体哪层缓存后要么等 TTL 过期要么手动清理缓存。还有一个常见故障是“缓存雪崩”的变种大量域名的 TTL 同时到期解析请求瞬间涌向权威服务器把服务器打挂。避免的方法是对 TTL 做随机化处理不要让大量记录在同一时刻过期。这个思路跟我们在系统设计里给缓存加随机过期时间是一个道理考试里如果能把这个类比说出来会显得很有架构思维。6. DNS 在架构设计中的实战应用前面几章讲的都是 DNS 的基础原理这一章换个角度讲讲 DNS 在实际架构设计里怎么用。软考高级架构师的考试越来越偏向场景化光懂原理不够还得知道怎么用。这部分内容在教材里往往比较散我把它归拢一下。6.1 用 DNS 做负载均衡的几种姿势DNS 做负载均衡是最简单、成本最低的方案但不同姿势的效果差别很大。最基础的是轮询一个域名配多条 A 记录DNS 服务器轮流返回。这种方式实现简单但有两个明显问题一是它不感知后端状态服务器挂了照样分配请求二是客户端和中间缓存会打乱轮询效果实际分布可能不均匀。进阶一点的是加权轮询给不同记录配不同的权重性能好的服务器分配更多请求。这需要 DNS 服务器支持权重配置普通 DNS 服务不一定有这功能。再进一步是智能解析根据请求来源的地理位置、运营商线路返回不同的 IP。比如南方用户返回南方机房的地址北方用户返回北方机房的地址这就是所谓的“分线路解析”。CDN 的调度很大程度上就依赖这种智能解析能力。考试里如果问“DNS 负载均衡的优缺点”答题思路是优点是实现简单、成本低、天然支持地理调度缺点是不感知后端健康状态、缓存影响调度精度、故障切换依赖 TTL 生效时间。把这几个点答全基本就是标准答案。6.2 多活架构下的 DNS 调度策略多活架构里DNS 承担着流量调度的第一道关口。用户请求先到 DNSDNS 根据策略决定把用户导向哪个机房。这个环节的设计直接影响到多活架构的容灾能力。常见的调度策略有几种。主备模式是平时全部流量走主机房主机房故障时 DNS 切换到备机房这种模式简单但备机房平时闲置资源利用率低。双活模式是两个机房同时承载流量DNS 按比例分配这种模式资源利用率高但对数据同步要求高。还有按用户归属调度的模式让用户就近接入降低延迟。DNS 调度在多活架构里有个绕不开的短板切换速度受 TTL 制约。主机房挂了你改 DNS 记录指向备机房但客户端缓存里的旧记录还没过期这部分用户还是会往挂掉的机房跑。所以真正的高可用架构不能只靠 DNS 切换还要配合负载均衡器、健康检查、应用层的容灾机制。考试里如果出多活架构的设计题只答 DNS 切换是不够的要体现出多层容灾的思路。6.3 DNS 安全那些考试爱考的攻击类型DNS 的安全问题在架构师考试里出现得越来越多主要考几种典型攻击方式和对应的防护手段。DNS 缓存投毒是攻击者往缓存服务器里注入虚假记录让用户访问到恶意地址。防护手段包括使用随机化查询 ID、启用 DNSSEC 验证等。DNS 劫持是攻击者篡改解析结果把用户导向钓鱼网站防护上要靠 HTTPS、证书校验这些应用层手段配合。DDoS 攻击是攻击者用海量请求打垮 DNS 服务器防护手段包括流量清洗、anycast 部署、多线冗余等。DNSSEC 是考试里经常提到的一个概念它通过数字签名保证解析结果的真实性和完整性。但 DNSSEC 只保证“结果没被篡改”不保证“结果不泄露”所以它跟加密传输是两回事。这个区分点考试里考过很多人把 DNSSEC 和加密混淆答题就偏了。7. 备考实操DNS 这块怎么学怎么练讲完原理和应用最后说说我自己的备考方法。DNS 这块知识的特点是“入门容易精通难”概念看着简单但细节特别多考试又爱在细节上做文章。光看书不够得动手练。7.1 用工具把抽象概念变成看得见的过程学 DNS 最有效的方法是用工具实际查一遍把书上的流程图变成自己亲眼看到的过程。常用的工具是 nslookup 和 digWindows 和 Linux 上都能用。用 dig 查一个域名加上 trace 参数可以看到完整的迭代查询过程dig www.example.com trace这条命令会从根服务器开始逐级显示查询过程你能清楚看到本地服务器先问哪个根服务器、根服务器返回哪个顶级服务器、顶级服务器又返回哪个权威服务器。把书上的迭代查询流程跟这个实际输出对照着看理解会深刻得多。查特定记录类型用 -t 参数dig example.com -t MX dig example.com -t NS dig example.com -t TXT分别查邮件服务器、权威服务器、文本记录对照第 4 章讲的记录类型印象会特别深。查缓存情况可以看返回结果里的 TTL 字段每次查询 TTL 会递减递减到 0 就重新向权威服务器查。这个观察能帮你直观理解 TTL 和缓存的关系。7.2 真题演练的正确打开方式DNS 的真题我建议分两轮做。第一轮按知识点分类做把递归迭代、记录类型、缓存、安全这几类的题目分别集中做一遍目的是查漏补缺看看哪个知识点还有盲区。第二轮按套卷做目的是练答题节奏和综合运用能力。做题的时候有个习惯要养成每道题做完后不管对错都把涉及的知识点在脑子里过一遍想想这个知识点还能怎么考。比如做了一道递归查询的题就顺便想想如果题目改成“本地服务器缓存命中”会怎么答改成“权威服务器直接响应”又会怎么答。这种发散式复盘比单纯刷题效率高得多。错题要单独整理重点记“为什么错”而不是“正确答案是什么”。DNS 的题错往往是因为概念混淆比如把递归和迭代搞反、把权威和本地搞混。把混淆点记下来考前重点看这些比重新看一遍教材管用。7.3 几个容易失分的细节提醒最后分享几个我踩过或者见别人踩过的坑都是考试里容易失分的地方。第一个坑是把“本地域名服务器”和“权威域名服务器”的职责搞混。本地服务器是代理负责帮客户端查权威服务器是数据源负责提供自己管理区域的权威答案。答题时如果把这个搞反整道题的逻辑就崩了。第二个坑是忽略缓存检查这一步。完整的解析流程里本地服务器收到请求后第一件事是查缓存命中就直接返回未命中才发起查询。很多人答题时直接从“向根服务器查询”开始写漏掉了缓存检查会被扣分。第三个坑是搞不清根服务器返回的是什么。根服务器不返回最终 IP只返回顶级域服务器的地址。同样顶级域服务器也只返回权威服务器地址。只有权威服务器才返回最终解析结果。这个层级关系答题时必须写清楚。第四个坑是 TTL 的单位和含义。TTL 的单位是秒表示缓存的有效期。有些题会给你 TTL 值让你算缓存什么时候过期或者问变更后多久生效这时候要能准确理解 TTL 的作用范围。第五个坑是 DNSSEC 的作用边界。DNSSEC 保证的是数据完整性和来源真实性不提供加密功能。如果题目问“如何保证 DNS 查询内容的机密性”答案不是 DNSSEC而是加密传输方案。这个区分点一定要记牢。我在实际备考中最大的体会是DNS 这块知识不能孤立地学要把它跟分布式系统、缓存设计、负载均衡、安全防护这些内容串起来。软考高级架构师考的是架构思维DNS 只是载体真正要展现的是你透过 DNS 看到的那些通用设计原则。把这一层想通了不光 DNS 的题能拿分其他相关的场景题也能触类旁通。
DNS 这个东西平时写业务代码的人很少主动去碰但一到软考高级架构师的考场上它就成了绕不开的硬骨头。我当年备考的时候翻遍了各种资料发现大部分材料要么把 DNS 讲成一本协议手册要么直接甩一张递归查询的流程图就完事真正能把“为什么这么设计”“考试到底考哪几个点”讲透的少之又少。这篇内容就是把我自己啃 DNS 这块的经历整理出来从概念本质到查询方式的每一个细节结合架构师考试的实际考法把这块知识彻底拆开揉碎。不管你是刚开始准备软考的小白还是已经做过几年开发、想系统梳理网络基础的老手看完应该都能对 DNS 有一个跟以前不太一样的理解。1. 先搞清楚 DNS 在架构师知识体系里到底占什么位置很多人备考软考高级架构师的时候会把大量精力砸在架构风格、设计模式、分布式这些“看起来更高级”的内容上对 DNS 这种“基础网络知识”下意识地降低优先级。我一开始也是这个心态觉得 DNS 不就是个域名解析嘛能有多难。结果做真题的时候发现DNS 相关的题目出得相当刁钻不是简单问你“DNS 是什么”而是嵌在系统设计、性能优化、高可用方案这些场景里考。1.1 为什么架构师考试对 DNS 情有独钟站在出题人的角度想一想就明白了。DNS 是整个互联网基础设施里最典型的一个“分布式系统”案例它同时涉及分层设计、缓存策略、负载均衡、容灾切换、安全防护这几个架构师必须掌握的核心能力。换句话说DNS 本身就是一个天然的架构设计样本考 DNS 其实是在考你对分布式系统设计思想的理解。举个具体的例子。软考里经常出现这样的场景题某系统需要支撑海量用户访问问你在域名解析层面可以做哪些优化。标准答案里会涉及 DNS 轮询、智能解析、CDN 调度这些内容。如果你只把 DNS 当成“把域名翻译成 IP”的工具这道题基本就废了。但如果你理解 DNS 的分布式本质知道它天然支持多级缓存和多记录返回就能顺着这个思路展开。我在复盘真题的时候做过一个统计DNS 相关知识点在架构师考试中的出现形式大致有这么几类一是概念辨析题考递归查询和迭代查询的区别二是记录类型题考 A、CNAME、MX、NS 这些记录各自的作用三是场景设计题把 DNS 和负载均衡、高可用结合起来考四是故障分析题给你一个解析异常的案例让你排查。这四类题目覆盖了 DNS 知识的各个层面也正好对应了我在后面几个章节要展开的内容。1.2 把 DNS 当成一个分布式数据库来理解我后来找到一个特别好用的理解角度把 DNS 看成一个全球分布式的、超大规模的键值数据库。键就是域名值就是各种资源记录。这个数据库的特点是读多写少、分层管理、多级缓存。你用这个视角去看 DNS 的很多设计会发现一切都顺理成章。为什么 DNS 要设计成树状层级结构因为集中式管理一个全球数据库根本不可能数据量太大、更新太频繁、单点故障风险太高。分层之后每个层级只管自己那一块根服务器管顶级域顶级域服务器管二级域逐级下放管理权限这就是典型的分布式治理思路。为什么 DNS 要有缓存因为每次解析都从根开始走一遍完整链路延迟太高、根服务器压力太大。缓存本质上是用空间换时间把解析结果暂存在离用户更近的地方下次直接命中。这个思路跟我们在系统设计里加 Redis 缓存是一个道理。为什么 DNS 默认用 UDP 而不是 TCP因为解析请求本身很小一个包就能装下用 UDP 省掉了三次握手的开销响应更快。当然现在也有 DNS over TCP、DNS over HTTPS 这些方案那是为了解决 UDP 传输的安全性和可靠性问题属于进阶内容考试里偶尔会提一嘴。用“分布式键值数据库”这个类比去打底后面再学具体的查询流程和记录类型就不会觉得是在死记硬背了而是能理解每一步设计背后的动机。2. 域名空间的分层结构从根到叶的完整拆解要真正搞懂 DNS 的查询方式必须先弄清楚域名空间是怎么组织的。这块内容看起来简单但里面的细节特别多考试也爱在这些细节上做文章。2.1 根域、顶级域、二级域到底怎么划分DNS 的域名空间是一棵倒挂的树最顶端是根域用一个点“.”表示。根域下面是顶级域再往下是二级域、三级域一直往下延伸。我们平时看到的域名比如 www.example.com完整写法其实是 www.example.com.最后那个点就是根域只是平时省略不写。顶级域分两类。一类是通用顶级域比如 .com、.org、.net、.edu 这些按用途划分另一类是国家或地区顶级域比如 .cn、.jp、.uk 这些按地理区域划分。软考里有时候会考你某个域名属于哪一类顶级域这种题属于送分题但前提是你得知道分类规则。二级域就是我们平时注册的那个主体部分比如 example.com 里的 example。二级域下面可以继续划分子域比如 mail.example.com、blog.example.com这些子域的管理权归二级域的持有者所有想怎么划就怎么划。这一点很重要它体现了 DNS 分层管理的核心思想每一层只负责自己管辖范围内的解析上级不关心下级内部怎么组织。我在理解这块的时候用了一个公司组织架构的类比。根域相当于集团总部顶级域相当于各个事业部二级域相当于事业部下面的具体业务线子域相当于业务线下面的小组。总部只告诉你找哪个事业部事业部只告诉你找哪条业务线业务线再告诉你具体找谁。每一层只知道自己下一层的信息不需要知道全貌。这个类比帮我记住了整个层级关系也理解了为什么 DNS 查询要逐级进行。2.2 区域和域不是一回事这是很多人容易混淆的一个点也是考试里经常挖坑的地方。域是一个逻辑概念指的是域名空间里的一棵子树区域是一个物理概念指的是某台 DNS 服务器实际管理的那部分数据。举个例子。example.com 这个域可能被划分成两个区域一个区域管 example.com 本身和它下面的主机记录另一个区域管 sub.example.com 这个子域。这两个区域可以放在同一台服务器上也可以放在不同的服务器上。域是“应该管什么”区域是“实际由谁管、管哪些”。为什么要把域和区域区分开因为实际部署中一个域的数据可能分散在多台服务器上也可能多台服务器互为备份管理同一个区域。区域是 DNS 数据复制和同步的基本单位主服务器和辅助服务器之间同步的就是区域数据。考试里如果问你“主从 DNS 服务器同步的是什么”答案就是区域数据不是整个域的数据。2.3 域名服务器的四种角色DNS 体系里的服务器按角色分主要有四类这个分类在考试里出现的频率很高必须记牢。服务器类型核心职责数据来源典型场景根域名服务器返回顶级域服务器的地址内置根区文件解析链路的起点顶级域名服务器返回二级域服务器的地址管理对应顶级域解析 .com、.cn 等权威域名服务器返回域名最终的解析结果管理具体区域数据域名持有者自己维护本地域名服务器代理用户发起查询并缓存结果缓存加转发运营商或企业内网这四类服务器里前三类是层级关系逐级下放本地域名服务器比较特殊它不在层级结构里而是用户和层级结构之间的代理。你电脑上配置的那个 DNS 地址指向的就是本地域名服务器也叫递归服务器或缓存服务器。权威服务器和本地服务器的区别是考试重点。权威服务器是数据的“源头”它给出的答案具有权威性不带缓存本地服务器是“二传手”它从权威服务器那里拿到答案后缓存起来下次有人问直接给缓存。判断一道题里某台服务器是权威还是本地关键看它管理的数据是不是自己维护的原始数据。3. 递归查询和迭代查询把这两个概念彻底掰开递归查询和迭代查询是 DNS 这块最核心的考点没有之一。我见过的真题里十道 DNS 题至少有六道跟这个有关。但很多人学的时候只是背了“递归是帮你查到底迭代是告诉你下一步找谁”这句话真到做题或者实际排查问题的时候就懵了。这一章我把这两个概念从原理到实际表现彻底讲清楚。3.1 递归查询客户端当甩手掌柜递归查询的本质是“你问我我负责给你最终答案”。客户端把请求发给本地域名服务器然后就等着中间本地服务器去根服务器、顶级服务器、权威服务器转了一大圈最后把结果返回给客户端。对客户端来说它只发了一次请求只收了一次响应中间的曲折它完全不知道。用生活场景类比一下。你去一家大公司办事前台本地域名服务器跟你说“你坐着等我帮你跑”。前台先打电话问总部根服务器该找哪个部门总部说找事业部顶级服务器前台又打电话问事业部该找哪个科室事业部说找具体业务线权威服务器前台再打电话问业务线要具体信息最后把结果拿回来告诉你。整个过程你只跟前台打了一次交道。递归查询的关键特征是查询的负担全部压在接收请求的那台服务器上。本地域名服务器要负责把整条链路走完任何一环出问题它都得处理。这也是为什么本地域名服务器通常由运营商或大型企业来维护因为它的负载很重需要足够的资源和带宽。在实际网络里客户端到本地域名服务器这一段用的就是递归查询。你电脑上配的那个 DNS 地址你向它发请求它就必须给你最终结果不能跟你说“你去问别人”。这是 DNS 协议规定的行为。3.2 迭代查询每台服务器只指路不带路迭代查询的本质是“你问我我告诉你下一步该问谁你自己去问”。本地域名服务器在迭代查询模式下先问根服务器根服务器说“我不知道具体答案但 .com 的服务器地址是某某你去问它”本地服务器再去问 .com 服务器对方说“我也不知道但 example.com 的服务器地址是某某你去问它”本地服务器再问 example.com 的权威服务器这次终于拿到了最终答案。还是用公司办事的类比。这次前台不帮你跑了而是告诉你“这事归事业部管你自己去事业部问”。你跑到事业部对方说“这事归业务线管你自己去业务线问”。你一层层自己跑最后在业务线那里拿到结果。每一层只告诉你下一层在哪不替你跑腿。迭代查询的关键特征是查询的负担分散在各台服务器上每台只负责指路。根服务器每天要处理海量查询如果每个查询都要它帮忙跑到底早就崩了。迭代查询让根服务器只需要回答“下一个该找谁”这种简单问题大大降低了它的负载。这也是 DNS 能支撑全球规模查询的重要原因。3.3 两种查询方式的完整链路对比把两种方式放在一起对比链路走向是这样的递归查询链路客户端视角客户端向本地域名服务器发起递归查询请求本地域名服务器检查缓存未命中则代为查询本地服务器依次向根、顶级、权威服务器发起迭代查询本地服务器拿到结果缓存后返回给客户端客户端收到最终答案迭代查询链路本地服务器视角本地服务器向根服务器发起迭代查询根服务器返回顶级域服务器地址本地服务器向顶级域服务器发起迭代查询顶级域服务器返回权威服务器地址本地服务器向权威服务器发起迭代查询权威服务器返回最终解析结果这里有个特别容易搞混的点客户端到本地服务器是递归本地服务器到层级服务器是迭代。这是实际网络中的标准做法也是考试最爱考的组合。很多人背的时候把这两个搞反了做题就全错。为什么这么设计因为客户端通常资源有限、能力有限让它自己去逐级查询不现实所以交给本地服务器代劳递归。而本地服务器如果对每一级都用递归那根服务器就要承担海量的递归查询压力太大所以层级之间用迭代每台服务器只指路迭代。这个设计逻辑理解了就不会记混。3.4 一道典型真题的拆解思路我拿一道常见的真题类型来演示怎么用上面的知识解题。题目大意是某主机向本地域名服务器查询某域名的 IP 地址本地域名服务器缓存中没有该记录请描述完整的查询过程。解题的时候要分两段写。第一段写客户端到本地服务器客户端发起递归查询本地服务器收到后检查缓存未命中则开始代为查询。第二段写本地服务器到层级结构本地服务器先向根服务器发起迭代查询根服务器返回对应的顶级域服务器地址本地服务器再向顶级域服务器发起迭代查询得到权威服务器地址最后向权威服务器查询拿到最终 IP 地址缓存后返回给客户端。答题的时候有几个细节要注意。一是要明确说出“递归”和“迭代”这两个词分别用在哪一段不能含糊二是要提到缓存检查这个步骤很多人漏掉三是要说清楚每一级返回的是什么地址还是最终结果根和顶级返回的是下一级服务器地址权威返回的是最终解析结果。这三点写全了这道题基本满分。4. 资源记录类型DNS 数据库里到底存了什么DNS 服务器返回的每一条解析结果本质上都是一条资源记录。不同的记录类型承载不同的信息考试里经常考你某个场景该用哪种记录。这一章把常见的记录类型逐个讲清楚重点讲每种记录的使用场景和容易踩的坑。4.1 A 记录和 AAAA 记录最基础的地址映射A 记录是把域名映射到 IPv4 地址AAAA 记录是把域名映射到 IPv6 地址。这两个是最基础、最常用的记录类型几乎所有域名都至少有一条 A 记录或 AAAA 记录。A 记录的一个域名可以对应多条记录这就是 DNS 轮询实现负载均衡的基础。比如 www.example.com 配置三条 A 记录分别指向三台服务器DNS 服务器返回时会轮换顺序客户端通常取第一条这样请求就分散到三台服务器上了。这种负载均衡方式成本极低但有个明显缺陷它不感知后端服务器的实际状态某台服务器挂了DNS 照样把请求往那台指。所以生产环境里通常要配合健康检查来动态调整记录。考试里关于 A 记录的坑主要在 TTL 上。TTL 是记录的生存时间决定了缓存多久失效。TTL 设得太长服务器 IP 变了之后客户端还在用旧地址切换慢TTL 设得太短缓存命中率低解析请求都打到权威服务器上压力大。这个权衡在系统设计题里经常出现答题时要体现出你对这个矛盾的理解。4.2 CNAME 记录别名背后的灵活性CNAME 记录把一个域名指向另一个域名相当于给域名起了个别名。比如把 www.example.com 指向 example.com或者把 blog.example.com 指向某个托管平台的域名。CNAME 最大的价值是解耦。假设你的服务部署在某个云平台上平台给你分配了一个域名你用 CNAME 把自己的域名指过去。将来换平台了只需要改 CNAME 的目标自己的域名不用动用户无感知。这种灵活性在架构设计里非常重要。但 CNAME 有几个硬性限制必须记住。第一CNAME 记录不能和同名的其他记录共存一个域名配了 CNAME就不能再配 A 记录、MX 记录等。第二根域名也就是裸域比如 example.com 不带 www通常不建议配 CNAME因为根域名往往还要配 MX 记录和 NS 记录会冲突。第三CNAME 链不宜过长每多一层就多一次解析延迟增加。考试里常考的一个场景是某公司要把网站迁移到新平台要求迁移过程中用户访问不受影响问怎么配置。标准思路就是用 CNAME 做过渡先把域名 CNAME 到新平台验证没问题后再逐步切换。这个思路体现的就是 CNAME 的解耦价值。4.3 MX、NS、PTR各有专长的记录类型MX 记录指定邮件服务器的地址可以配多条并带优先级数字越小优先级越高。邮件系统发信时会先查目标域名的 MX 记录按优先级依次尝试。这个优先级机制保证了邮件服务器的主备切换。NS 记录指定某个域由哪台域名服务器来管理是域名委派的核心。你在注册商那里注册域名时填的就是 NS 记录告诉全世界“这个域归这几台服务器管”。NS 记录直接决定了权威服务器是谁是 DNS 层级结构能够运转的关键。PTR 记录是反向解析记录把 IP 地址映射回域名跟 A 记录正好相反。它的用途主要是邮件服务器的反垃圾验证和日志分析。很多邮件服务商收到邮件时会查发信 IP 的 PTR 记录如果 PTR 记录跟发信域名对不上就可能被判为垃圾邮件。这个点在系统设计题里偶尔会涉及属于加分项知识。4.4 记录类型的选型对照表把常见记录类型的使用场景整理成表方便对照记忆记录类型作用典型场景注意事项A域名到 IPv4 地址网站、API 服务可配多条做轮询AAAA域名到 IPv6 地址IPv6 环境与 A 记录配合使用CNAME域名到域名别名迁移、托管、CDN不能与其他记录共存MX指定邮件服务器企业邮箱带优先级可配多条NS指定权威服务器域名委派决定解析链路走向PTRIP 到域名反向解析邮件验证、日志需要向 IP 持有方申请TXT文本说明信息域名验证、安全策略内容灵活用途广泛TXT 记录虽然不在传统四大记录里但实际使用越来越广泛域名所有权验证、邮件安全策略配置都靠它。考试里如果出现“如何验证域名所有权”这类题答案往往就是配一条特定的 TXT 记录。5. 缓存机制DNS 性能的命脉所在DNS 能支撑全球规模的查询量缓存功不可没。没有缓存的话每次访问网站都要从根服务器开始走完整链路互联网早就瘫痪了。缓存这块在考试里考得不算最多但一旦考到就是区分度很高的题因为它涉及 TTL、缓存位置、缓存更新这些有深度的内容。5.1 缓存分布在哪些环节DNS 缓存不是只有一层而是分布在整条链路的多个环节。从近到远大致有这么几层浏览器缓存、操作系统缓存、本地域名服务器缓存、上级缓存服务器缓存。浏览器缓存是最靠近用户的Chrome、Firefox 这些浏览器都会缓存解析结果有效期通常比较短。操作系统缓存是系统级别的Windows 和 Linux 都有自己的 DNS 缓存机制。本地域名服务器缓存是最大的一层运营商或企业的递归服务器会缓存大量解析结果命中率很高。这个多层缓存结构带来的一个直接后果是域名解析变更后生效不是瞬间的而是要等各级缓存过期。这就是为什么改 DNS 记录后经常要等一段时间才生效业内叫“DNS 传播”其实不是传播是各级缓存陆续过期。理解这一点在系统设计题里讨论变更方案时就能体现出深度。5.2 TTL 的权衡艺术TTL 是缓存控制的核心参数它的设置是一门权衡艺术。TTL 长缓存命中率高解析快权威服务器压力小但变更生效慢TTL 短变更生效快但缓存命中率低解析请求多权威服务器压力大。实际生产中的常见做法是分场景设置。稳定的服务用较长的 TTL比如几小时甚至一天需要频繁切换的服务用较短的 TTL比如几分钟。还有一种做法是变更前临时调短 TTL等变更完成、缓存都过期后再调回长 TTL这样兼顾了平时的性能和变更时的灵活性。考试里如果出现“如何缩短 DNS 变更生效时间”这类题标准答案就是调短 TTL同时配合提前操作。答题时如果能提到“变更前先调短 TTL 等待旧缓存过期变更后再恢复”这个完整流程就是高分答案。5.3 缓存带来的典型故障场景缓存机制虽然好但也带来了一些典型故障。最常见的是“缓存污染”也就是缓存里存了错误的解析结果导致用户访问到错误的地址。这种情况可能是配置错误、也可能是恶意攻击导致的。排查这类问题的思路是逐层验证。先在客户端用 nslookup 或 dig 查看返回什么再直接向权威服务器查看权威数据是什么两者对比如果权威数据正确而客户端拿到的是错的说明中间某层缓存有问题。定位到具体哪层缓存后要么等 TTL 过期要么手动清理缓存。还有一个常见故障是“缓存雪崩”的变种大量域名的 TTL 同时到期解析请求瞬间涌向权威服务器把服务器打挂。避免的方法是对 TTL 做随机化处理不要让大量记录在同一时刻过期。这个思路跟我们在系统设计里给缓存加随机过期时间是一个道理考试里如果能把这个类比说出来会显得很有架构思维。6. DNS 在架构设计中的实战应用前面几章讲的都是 DNS 的基础原理这一章换个角度讲讲 DNS 在实际架构设计里怎么用。软考高级架构师的考试越来越偏向场景化光懂原理不够还得知道怎么用。这部分内容在教材里往往比较散我把它归拢一下。6.1 用 DNS 做负载均衡的几种姿势DNS 做负载均衡是最简单、成本最低的方案但不同姿势的效果差别很大。最基础的是轮询一个域名配多条 A 记录DNS 服务器轮流返回。这种方式实现简单但有两个明显问题一是它不感知后端状态服务器挂了照样分配请求二是客户端和中间缓存会打乱轮询效果实际分布可能不均匀。进阶一点的是加权轮询给不同记录配不同的权重性能好的服务器分配更多请求。这需要 DNS 服务器支持权重配置普通 DNS 服务不一定有这功能。再进一步是智能解析根据请求来源的地理位置、运营商线路返回不同的 IP。比如南方用户返回南方机房的地址北方用户返回北方机房的地址这就是所谓的“分线路解析”。CDN 的调度很大程度上就依赖这种智能解析能力。考试里如果问“DNS 负载均衡的优缺点”答题思路是优点是实现简单、成本低、天然支持地理调度缺点是不感知后端健康状态、缓存影响调度精度、故障切换依赖 TTL 生效时间。把这几个点答全基本就是标准答案。6.2 多活架构下的 DNS 调度策略多活架构里DNS 承担着流量调度的第一道关口。用户请求先到 DNSDNS 根据策略决定把用户导向哪个机房。这个环节的设计直接影响到多活架构的容灾能力。常见的调度策略有几种。主备模式是平时全部流量走主机房主机房故障时 DNS 切换到备机房这种模式简单但备机房平时闲置资源利用率低。双活模式是两个机房同时承载流量DNS 按比例分配这种模式资源利用率高但对数据同步要求高。还有按用户归属调度的模式让用户就近接入降低延迟。DNS 调度在多活架构里有个绕不开的短板切换速度受 TTL 制约。主机房挂了你改 DNS 记录指向备机房但客户端缓存里的旧记录还没过期这部分用户还是会往挂掉的机房跑。所以真正的高可用架构不能只靠 DNS 切换还要配合负载均衡器、健康检查、应用层的容灾机制。考试里如果出多活架构的设计题只答 DNS 切换是不够的要体现出多层容灾的思路。6.3 DNS 安全那些考试爱考的攻击类型DNS 的安全问题在架构师考试里出现得越来越多主要考几种典型攻击方式和对应的防护手段。DNS 缓存投毒是攻击者往缓存服务器里注入虚假记录让用户访问到恶意地址。防护手段包括使用随机化查询 ID、启用 DNSSEC 验证等。DNS 劫持是攻击者篡改解析结果把用户导向钓鱼网站防护上要靠 HTTPS、证书校验这些应用层手段配合。DDoS 攻击是攻击者用海量请求打垮 DNS 服务器防护手段包括流量清洗、anycast 部署、多线冗余等。DNSSEC 是考试里经常提到的一个概念它通过数字签名保证解析结果的真实性和完整性。但 DNSSEC 只保证“结果没被篡改”不保证“结果不泄露”所以它跟加密传输是两回事。这个区分点考试里考过很多人把 DNSSEC 和加密混淆答题就偏了。7. 备考实操DNS 这块怎么学怎么练讲完原理和应用最后说说我自己的备考方法。DNS 这块知识的特点是“入门容易精通难”概念看着简单但细节特别多考试又爱在细节上做文章。光看书不够得动手练。7.1 用工具把抽象概念变成看得见的过程学 DNS 最有效的方法是用工具实际查一遍把书上的流程图变成自己亲眼看到的过程。常用的工具是 nslookup 和 digWindows 和 Linux 上都能用。用 dig 查一个域名加上 trace 参数可以看到完整的迭代查询过程dig www.example.com trace这条命令会从根服务器开始逐级显示查询过程你能清楚看到本地服务器先问哪个根服务器、根服务器返回哪个顶级服务器、顶级服务器又返回哪个权威服务器。把书上的迭代查询流程跟这个实际输出对照着看理解会深刻得多。查特定记录类型用 -t 参数dig example.com -t MX dig example.com -t NS dig example.com -t TXT分别查邮件服务器、权威服务器、文本记录对照第 4 章讲的记录类型印象会特别深。查缓存情况可以看返回结果里的 TTL 字段每次查询 TTL 会递减递减到 0 就重新向权威服务器查。这个观察能帮你直观理解 TTL 和缓存的关系。7.2 真题演练的正确打开方式DNS 的真题我建议分两轮做。第一轮按知识点分类做把递归迭代、记录类型、缓存、安全这几类的题目分别集中做一遍目的是查漏补缺看看哪个知识点还有盲区。第二轮按套卷做目的是练答题节奏和综合运用能力。做题的时候有个习惯要养成每道题做完后不管对错都把涉及的知识点在脑子里过一遍想想这个知识点还能怎么考。比如做了一道递归查询的题就顺便想想如果题目改成“本地服务器缓存命中”会怎么答改成“权威服务器直接响应”又会怎么答。这种发散式复盘比单纯刷题效率高得多。错题要单独整理重点记“为什么错”而不是“正确答案是什么”。DNS 的题错往往是因为概念混淆比如把递归和迭代搞反、把权威和本地搞混。把混淆点记下来考前重点看这些比重新看一遍教材管用。7.3 几个容易失分的细节提醒最后分享几个我踩过或者见别人踩过的坑都是考试里容易失分的地方。第一个坑是把“本地域名服务器”和“权威域名服务器”的职责搞混。本地服务器是代理负责帮客户端查权威服务器是数据源负责提供自己管理区域的权威答案。答题时如果把这个搞反整道题的逻辑就崩了。第二个坑是忽略缓存检查这一步。完整的解析流程里本地服务器收到请求后第一件事是查缓存命中就直接返回未命中才发起查询。很多人答题时直接从“向根服务器查询”开始写漏掉了缓存检查会被扣分。第三个坑是搞不清根服务器返回的是什么。根服务器不返回最终 IP只返回顶级域服务器的地址。同样顶级域服务器也只返回权威服务器地址。只有权威服务器才返回最终解析结果。这个层级关系答题时必须写清楚。第四个坑是 TTL 的单位和含义。TTL 的单位是秒表示缓存的有效期。有些题会给你 TTL 值让你算缓存什么时候过期或者问变更后多久生效这时候要能准确理解 TTL 的作用范围。第五个坑是 DNSSEC 的作用边界。DNSSEC 保证的是数据完整性和来源真实性不提供加密功能。如果题目问“如何保证 DNS 查询内容的机密性”答案不是 DNSSEC而是加密传输方案。这个区分点一定要记牢。我在实际备考中最大的体会是DNS 这块知识不能孤立地学要把它跟分布式系统、缓存设计、负载均衡、安全防护这些内容串起来。软考高级架构师考的是架构思维DNS 只是载体真正要展现的是你透过 DNS 看到的那些通用设计原则。把这一层想通了不光 DNS 的题能拿分其他相关的场景题也能触类旁通。
