把“看的懂协议”变成“真的会分析”往往就差一次报文拆解的距离。最近在做头歌平台“DNS协议分析”实训的第3关“DNS报文分析”时我花了整个下午跟Wireshark里的DNS报文死磕从最初的一头雾水到后面能对着十六进制流逐字节说出含义这个过程比想象中的更有意思也踩了几个教科书上不会明说的坑。这篇就把我完整走通这条链路的过程、方法还有容易卡住的地方都写出来给你当一份可直接参考的实操笔记。1. 为什么DNS报文分析是协议学习里最值得较真的一关很多人在学网络协议时有个误区总觉得“报文格式”这种东西背下来就行了。但头歌把这一关安排为DNS协议分析的第三关而且专门命名为“DNS报文分析”说明它的目的不是让你背格式而是逼你真正理解“DNS在网络上到底长什么样子”。先理顺一个基本概念DNS是应用层协议但它的报文结构跟HTTP这种纯文本协议完全不一样。HTTP报文里是肉眼可读的GET、POSTDNS报文是二进制格式所有的字段都要按偏移量和位去解析。你抓到一个DNS报文之后直接看是看不出“这个查询在问www.example.com的A记录”的需要自己按协议规范把字节拆开才能知道里面藏了什么信息。之所以说这一关值得较真还有一个实际原因DNS报文格式几乎是所有网络协议里“复用性”最强的模板。它的头部结构事务ID、标志位、计数字段直接影响了你后面学DHCP、NTP这些基于UDP的协议时的理解速度。也就是说这一关拆明白了后面很多协议的报文分析都顺了这一关混过去的后面总会回来补课。这个实训关卡的核心要求说直白一点就是给你一个真实的DNS报文让你通过分析获取这些信息——事务ID是多少、是查询还是响应、有没有递归请求、问的是什么域名、返回的是什么IP地址。这些恰恰是排查网络问题时最常参考的字段。我在处理这一关时给自己定了一个比较“笨”但非常有效的方法不看现成的解析结果强制自己先对着原始十六进制流手动拆字段拆完再打开Wireshark对照验证。这个方法推荐给所有想真正把这关吃透的人。2. 搭建一个干净的抓包环境别在第一公里翻车报文分析的前提是能拿到一份“干净”的报文样本。头歌平台上有些关卡的报文是直接提供的但在实际练习里最好还是自己动手抓一份真实的DNS报文。整个过程要注意的地方不少。2.1 工具的选型与准备这一题最顺手的工具毫无疑问是Wireshark两个理由一是它能自动解析DNS协议层并展示字段含义方便做“标准答案”对照二是它自带强大的显示过滤器可以只保留DNS流量避免被无关的网络包淹没。安装Wireshark时有个提醒值得注意Windows下安装包会附带Npcap/WinPcap这个是抓包必需的底层驱动安装时务必勾选否则工具装好了也听不到网卡上的流量。另外如果只是看报文分析题里给出的固定报文也可以直接用Wireshark打开保存好的.pcapng文件不一定非要实时抓包。2.2 抓包时的网卡选择和过滤如果你决定自己抓包选对网卡比什么都重要。这里有个新手最常犯的错误笔记本开着Wi-Fi却选的是以太网卡抓了半天什么都抓不到。解决办法很简单——在Wireshark主界面看网卡列表后的实时流量条哪个在跳就选哪个。抓包开始后默认的capture filter建议直接写明udp port 53DNS默认走UDP 53端口只抓这个过滤条件就能让绝大多数流量不进入缓存。显示过滤器是抓到之后用的dns一条显示过滤器既能看到DNS查询Queries也能看到DNS响应Responses比抓包过滤器更灵活建议两个filter配合使用。2.3 最容易忽略的DNS缓存的坑很多人自己练习时遇到的问题不是抓不到包而是“想抓的包压根没发出去”。因为操作系统和浏览器都有DNS缓存同一个域名如果你之前访问过再次请求时直接命中缓存根本不会有DNS报文经过网卡。我在实训时就是反复刷新同一个域名等了几分钟一条DNS包都没有一度以为Wireshark装错了。后来才意识到是本地DNS缓存在作祟。清理缓存的命令很简单在Windows的命令提示符或PowerShell下执行ipconfig /flushdnsLinux/macOS下则用sudo systemd-resolve --flush-caches # 或 sudo killall -HUP mDNSResponder清完缓存之后再来一次nslookup或者浏览器访问DNS报文就乖乖出现在抓包列表里了。2.4 不依赖平台限制的备选方案有些实训环境的浏览器可能限制你安装软件或者你不想在自己电脑上装抓包工具这个不碍事。用在线DNS查询工具的“递推过程”展示功能也能看出查询报文的请求链路和最终的结果记录。但我个人的建议是如果条件允许还是尽量用Wireshark走一遍。因为这一关的核心目标是看懂二进制报文结构Wireshark的双排视图上排树状解析、下排十六进制是全世界最容易建立“字段和字节”对应关系的工具没有之一。3. 按字节拆开DNS报文头每一个标志位都在说什么拿到一个DNS报文后正常情况下你应该先看头部。DNS头部永远固定是12字节这也是整个DNS报文里最容易固定下来的标识。这一部分如果啃下来后面看问题部分和回答部分就只是“体力活”了。3.1 头部结构的核心字段为了方便说明我先给出一份常见的DNS报文十六进制数据我们后面都拿它来分析。这是一个权威DNS服务器解析example.com时截获的查询请求0x24 0x49 0x01 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x07 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x03 0x63 0x6f 0x6d 0x00 0x00 0x01 0x00 0x01从偏移0开始前12个字节是DNS头部。逐个字段看偏移字节数字段本例值含义0-12字节Transaction ID事务ID0x2449 9289对应查询和响应的匹配编号2-32字节Flags标志字段0x0100见下文逐位拆解4-52字节QDCOUNT问题数0x0001 1报文中包含1个问题6-72字节ANCOUNT回答数0x0000 0查询报文中没有回答8-92字节NSCOUNT权威记录数0x0000 0没有权威记录10-112字节ARCOUNT附加记录数0x0000 0没有附加记录写这段的时候我想多提醒一句计数字段的四个值之间不是对等关系。QDCOUNT代表“问题部分有几条”ANCOUNT代表“回答部分有几条”NSCOUNT和ARCOUNT分别对应权威和附加。判断一个报文是查询还是响应最直接的办法反而是看Flags而不是计数——因为响应报文的ANCOUNT通常不为零但并不是所有响应都一定有回答记录比如NXDOMAIN的错误响应。3.2 Flags标志字段的位级拆分这是DNS头部里最难懂、也是这一关最爱出考题的部分。Flags字段一共16位每一位或每几位都有明确含义。我们拿0x0100来拆。先把十六进制转成二进制0x0100 0000 0001 0000 0000逐位分配一下Bit 150x8000QR位0代表查询1代表响应。0x0100的最高位是0说明这是一个查询报文。Bit 14-110x7800Opcode4位0000表示标准查询。Bit 100x0400AA位Authoritative Answer权威回答查询请求中为0。Bit 90x0200TC位TrunCation截断标志0表示未截断。Bit 80x0100RD位Recursion Desired期望递归本例二进制恰好是1说明客户端希望DNS服务器帮忙递归解析。Bit 70x0080RA位Recursion Available允许递归查询中为0。Bit 60x0040Z位保留位必须为0。Bit 5-40x0020和0x0010AD位和CD位分别表示“应答是否经过DNSSEC验证”和“是否忽略验证结果”。现代DNS报文里越来越常见老教材不提它们但抓真实流量时经常会看到。比如CD位在客户端禁用DNSSEC校验时会置1这一点容易被忽略。Bit 3-0RCODE应答码0000表示无错误。也就是说0x0100这个标志字段的含义是标准查询、期望递归。加上前面的Transaction ID 9289就够凑成一次完整查询的头部特征了。对比一下如果是一个递归成功的响应报文它的Flags很可能长成0x8180二进制的拆法是0x8180 1000 0001 1000 0000从高到低QR1响应Opcode0000标准查询AA0非权威TC0未截断RD1期望递归RA1递归可用Z000RCODE0000无错误。把这两个状态记熟以后看Wireshark里的Flags那一行你能完全对上号就不需要在线上到处搜“0x8180代表什么意思”了。3.3 为何教科书写的是“两字节标志位”而不是“一个整数”初学者很容易被Wireshark里显示的那种“Flags: 0x0100 (Recursion desired)”给带偏以为标志位是一个完整的数值。但协议规定它是个位域也就是16个独立的位被成组赋予意义。所以你在分析报文的时候一定要“位级”地去读而不是把0x0100当普通整数去看。这一点我在实训时也是绕了一下才彻底转过弯来的。4. 问题部分Question Section怎么解析从域名编码到查询类型头部看完接着看QNAME。这部分是DNS报文分析里最“绕”的地方因为它不是直接用ASCII字符串存域名而是采用了一种“长度前缀标签”的编码方式。4.1 域名的压缩编码规则还是用前面的十六进制串头部结束之后从偏移12开始0x07 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x03 0x63 0x6f 0x6d 0x00解析规则是这样的每段标签以一个长度字节开始这个字节的数值表示后面紧跟的标签长度单位是字节然后跟上对应长度的ASCII字符直到遇见0x00表示域名结束。逐字节翻译0x07后面长度7字节0x65 0x78 0x61 0x6d 0x70 0x6c 0x65ASCII分别是 e x a m p l e拼起来是“example”0x03后面长度3字节0x63 0x6f 0x6dASCII分别是 c o m拼起来是“com”0x00域名终止符拼在一起就是“example.com”。这种编码为什么高效因为它把域名里被重复访问的标签比如com、net在同一个报文的多个地方只用一次大大缩减了报文体积。这个设计在上世纪80年代是相当精简的放到今天处理海量DNS查询时依然是有效功。建立这个认知之后问题部分剩下的两个字段就简单了QTYPE查询类型占2字节0x0001表示A记录查询也就是查IPv4地址0x001c表示AAAA记录查IPv6地址。QCLASS查询类别占2字节0x0001表示INInternet绝大多数场景都是这个值。按照这个规则继续解析我们的报文在域名结束标志0x00后面的四字节是0x00 0x01 0x00 0x01拆开就是QTYPE0x0001A查询QCLASS0x0001Internet。把这一节串起来问题部分的完整含义就是“请告诉我example.com的IPv4地址。”4.2 指针压缩响应报文里最坑的偏移量陷阱查询报文里QNAME的编码是直白的长前缀格式但到了响应报文里由于服务器经常需要在回答部分重复域名就会出现指针pointer。指针的标识是第一字节的高两位是“11”也就是0xC0开头。比如0xC0 0x0C这个指针表示不要直接读这里的字节作为域名而是跳回到当前DNS报文起始位置偏移0x0C的地方从那里开始重新解析域名。这个机制是救人也是坑人的。救人在于它的压缩效率极高尤其应对一条几百条记录的响应时非常有用坑人在于初学者一旦忘了检查字节的高两位就会把0xC0这一字节当成普通ASCII来读然后就出现“域名里面怎么有个乱码”的迷惑。举一个真实例子如果响应报文里回答部分有一条记录的NAME字段是0xC00C那么这个记录的域名就是整个DNS报文的第12个字节开始的那个域名也就是查询部分里的那个域名。这就是为什么我们在分析DNS响应报文时十六进制下面那一条蓝色的“Name: example.com”虽然看着是自动解析的但它背后的偏移跳转逻辑极其精妙。我自己的习惯是在Wireshark十六进制视图里点选Name字段时会自动高亮显示它实际引用的偏移位置。这个可视化联动功能非常有用建议你熟悉一下。理解了指针之后你才算真正跨进了DNS报文结构的门槛。5. 回答部分Answer Section里的门道从TTL到RDATA的逐条解读DNS响应的重头戏在回答部分。这部分一条记录由四个子字段构成NAME、TYPE、CLASS、TTL、RDLENGTH、RDATA。它们合起来描述了一条“资源记录”Resource RecordRR。5.1 一个完整资源记录的字段拆解假设抓到一个响应报文回答部分有这样一个RR从十六进制流角度展示0xC0 0x0C # NAME指针指向偏移12 0x00 0x01 # TYPE A 0x00 0x01 # CLASS IN 0x00 0x00 0x00 0x3C # TTL 60秒 0x00 0x04 # RDLENGTH 4字节 0x5D 0xB8 0xD8 0x22 # RDATA 93.184.216.34每个字段都不是白给的它的实际意义是这样的TTLTime To Live单位是秒。60秒意味着这条记录在收到它的缓存服务器上只存活60秒过期后必须重新向权威服务器询问。网站做DNS变更后迟迟不生效十有八九是TTL值设得很大旧记录一直在缓存中撑着。RDLENGTH指明RDATA的长度单位是字节。对于A记录而言因为返回IPv4地址固定是4字节AAAA记录则是16字节。根据RDLENGTH再去读RDATA是解析可变长度记录的核心手法。RDATA存放真正要返回的数据。A记录里就是4字节的IPv4地址十六进制0x5D B8 D8 22对应的十进制刚好是93.184.216.34。那TYPE还有其他常见值吗有而且你在真实环境里见到的频率很高。TYPE值含义RDATA格式A (1)IPv4地址4字节AAAA (28)IPv6地址16字节CNAME (5)别名指向域名压缩格式MX (15)邮件交换服务器优先级域名NS (2)权威域名服务器域名TXT (16)文本记录长度文本PTR (12)反向解析域名5.2 回答部分的长度依赖关系别只顾着看单条记录回答部分里记录的条数是由头部的ANCOUNT决定的而每条记录的解析边界是由RDLENGTH决定的。有一个很常见的操作错误是拿到一个响应报文直接跳到最后几行看IP地址却不看ANCOUNT。如果响应里有多条A记录比如example.com同时解析出两个IPv4地址而你只用固定偏移去看可能只看到了其中一条剩下的完全错过。比如头部ANCOUNT2回答部分连续跟着两条A记录每条都是“指针TYPECLASSTTLRDLENGTHRDATA”的完整结构。分析一条之后要立刻回到“当前偏移这条记录总长度”的位置去解析下一条而不是从头再来一遍。这种“长度依赖”思维是读懂几乎所有二进制协议的关键不止DNS如此。5.3 响应报文中找“授权回答”和“附加记录”区很多教材把你引导到回答部分就停了但真实报文里还有两个区域值得关注NSCOUNT对应的权威部分和ARCOUNT对应的附加部分。比如我抓过一个响应报文回答部分给了example.com的A记录权威部分带出了ns1.example.com的NS记录附加部分又附上了ns1.example.com的IP地址。这种“附加值”是把权威DNS服务器的地址一起告诉你省去你再发一次查询的麻烦。这一关如果只要求解析应答内容分析到RDATA基本就结束了。但如果你想进阶观察一下NSCOUNT和ARCOUNT不为0时的报文结构会让你对DNS整个工作模式的理解立体不少。6. 实测中的一个完整案例分析从请求到响应的完整对照到这里前面几部分都是把细节掰开了讲。但掌握碎片还不够真正要过这一关、以及今后做网络排查你需要习惯把请求和响应当作一对数据来对照分析。下面我复现一个完整的实测过程把整个过程串一遍。6.1 请求和响应的字段对应关系我在自己的电脑上清空DNS缓存后对example.com发起了一次nslookup请求。Wireshark里捕获到一前一后两个报文查询报文源端口随机目的端口53的关键字段Transaction ID0x8A2BFlags0x0100RD1期望递归QDCOUNT1问题部分example.com类型A响应报文源端口53目的端口为刚才的随机端口的关键字段Transaction ID0x8A2B与查询完全一致Flags0x8180QR1RD1RA1RCODE0QDCOUNT1ANCOUNT1回答部分example.comA记录TTL60RDATA93.184.216.34把两个报文放一起看有几个地方非常值得你看一眼就秒懂Transaction ID是客户端随机生成的每一条查询都不同响应报文里原样返回这样客户端才能把响应和查询对上。这就是为什么一个客户端同时发出几十个DNS查询也不会乱套。响应报文里一定会原封不动地带有问题部分也就是“你问了什么”接着才放“你问的东西的答案”。RCODE0表示服务器成功处理了查询。如果RCODE3那表示NXDOMAIN也就是这个域名压根不存在。6.2 校验和Checksum该不该看什么时候看UDP报文头部有校验和字段很多分析题会让你算一下。说实话日常用Wireshark分析DNS报文网络层和传输层的校验和一般不用手动算Wireshark自己会告诉你对不对。但这一关如果专门考到了报文校验有一点需要提醒UDP的校验和覆盖范围是伪头部UDP头部数据部分不是只看UDP头部。如果把“伪头部”这个概念忽略了算出来的校验和永远对不上。6.3 典型考题的可视化思路做这一类实训时我强烈建议你把Wireshark的“Packet Details”面板和“Packet Bytes”面板上下铺开点一下树状列表里的“Transaction ID”或者“Name: example.com”下方的十六进制区会同步高亮对应字节。这种“点击联动”的方式比直接看答案更能在脑子里建立位置感。反复点几遍你会自然形成“字段在报文里是有固定排布顺序”的肌肉记忆。等看完这个案例再回去看头歌第3关给出的题目你会发现它考的核心无非就是三类一是给定报文里找出头部字段Transaction ID、Flags、计数二是解释标志位的二进制含义三是根据回答部分写出查询的域名和解析结果。掌握了上面这套“头部→问题→回答”的完整阅读链这三类题都不再有难度。7. 踩坑总结几个我在实训中走过的弯路这部分就当是附加经验包把我自己在实际分析过程中遇到的问题集中列出来希望能帮你绕过这些看似不大但特别耗时的坑。7.1 把“响应”误判成“查询”或是反之排查问题第一步一定要先看QR位。如果上来就看计数字段查询报文的ANCOUNT是0你可能误以为抓到了服务器故障。实际上查询报文本来就不该有回答。反过来说如果一个“响应”报文里的QR位是0那它极有可能是伪装的查询报文在网络排障时要养成只看协议行为而非只看端口来源的检查习惯。7.2 被16进制展示“整懵”的时刻Wireshark默认把报文每个字节都按两位十六进制显示看起来是一串毫无规律的数字。第一次接触时非常容易晕。我的建议是不要尝试一次性看懂一整段二进制流而是按“12字节头部→问题部分→回答部分”的顺序切段看。一把整串报文从左往右读是读不出任何结构的结构本来就是分层的。7.3 理解“事务ID一样”不等于“两个报文完全一样”有一次实训题给了两个报文事务ID一样但内容显示一个是查询、一个是响应。我最初以为是平台的重复报文后来仔细看才发现一个是客户端发的查询另一个是服务器给的响应事务ID相同只是它们配对的证据。这个细节如果没看透很容易得出“平台数据发重复了”的错误结论。7.4 域名大小写问题容易忽略记录内容比较DNS域名在报文里严格要求大小写不敏感但规范上允许保留原始大小写。因此在做“字段一致性校验”时比较字符串之前要先统一转成小写。不然你会很疑惑为什么报文里写着WWW.Example.Com但服务器却给出了完全正常的应答。8. 一个推荐的分析顺序拿来就能用把所有细节都过完我整理出一套自己现在每次抓DNS报文都会采用的分析顺序。你可以直接照着这个顺序来练习尤其是做头歌这类实训平台的题目时它能把思考路径固定下来。第1步定方向。看QR位确认当前报文是查询0还是响应1。第2步看标志。读Opcode查询类型、RD是否要递归、RA服务器是否可递归、RCODE是否有错误。这几个值组合起来基本能判断这次交互是否正常。第3步结对账。记下Transaction ID在抓包文件里过滤同样ID的另一个方向报文确认它们成对出现。第4步看问题。从偏移12开始解析QNAME注意判断是普通长度前缀还是0xC0指针。读完QNAME后紧接着4字节是QTYPE和QCLASS。第5步看回答。如果ANCOUNT0先确认回答记录是从哪个偏移开始的然后按“NAME、TYPE、CLASS、TTL、RDLENGTH、RDATA”逐条拆拆完一条根据RDLENGTH跳到下一条的起始位置。第6步算验证。如果需要校验Checksum按UDP伪头部UDP头的规则做一遍如果只是判断报文是否有问题以Wireshark的Checksum Status列为准。这套流程熟练之后从打开pcap文件到口算出域名的解析结果正常情况下不超过两分钟。平时多抓几次包多关掉Wireshark的解析结果自己先猜一遍分析速度会提升得非常快。如果你想进一步扩展可以在这套顺序基础上尝试写一个简单的Python脚本用dpkt或scapy库读取pcap文件并自动提取出每个DNS报文的Transaction ID、域名和A记录。这会让你的“报文分析”能力从手工解析升级到自动化处理也更容易应对数据量大的场景——不过那就是这一关之外的乐趣了。
把“看的懂协议”变成“真的会分析”往往就差一次报文拆解的距离。最近在做头歌平台“DNS协议分析”实训的第3关“DNS报文分析”时我花了整个下午跟Wireshark里的DNS报文死磕从最初的一头雾水到后面能对着十六进制流逐字节说出含义这个过程比想象中的更有意思也踩了几个教科书上不会明说的坑。这篇就把我完整走通这条链路的过程、方法还有容易卡住的地方都写出来给你当一份可直接参考的实操笔记。1. 为什么DNS报文分析是协议学习里最值得较真的一关很多人在学网络协议时有个误区总觉得“报文格式”这种东西背下来就行了。但头歌把这一关安排为DNS协议分析的第三关而且专门命名为“DNS报文分析”说明它的目的不是让你背格式而是逼你真正理解“DNS在网络上到底长什么样子”。先理顺一个基本概念DNS是应用层协议但它的报文结构跟HTTP这种纯文本协议完全不一样。HTTP报文里是肉眼可读的GET、POSTDNS报文是二进制格式所有的字段都要按偏移量和位去解析。你抓到一个DNS报文之后直接看是看不出“这个查询在问www.example.com的A记录”的需要自己按协议规范把字节拆开才能知道里面藏了什么信息。之所以说这一关值得较真还有一个实际原因DNS报文格式几乎是所有网络协议里“复用性”最强的模板。它的头部结构事务ID、标志位、计数字段直接影响了你后面学DHCP、NTP这些基于UDP的协议时的理解速度。也就是说这一关拆明白了后面很多协议的报文分析都顺了这一关混过去的后面总会回来补课。这个实训关卡的核心要求说直白一点就是给你一个真实的DNS报文让你通过分析获取这些信息——事务ID是多少、是查询还是响应、有没有递归请求、问的是什么域名、返回的是什么IP地址。这些恰恰是排查网络问题时最常参考的字段。我在处理这一关时给自己定了一个比较“笨”但非常有效的方法不看现成的解析结果强制自己先对着原始十六进制流手动拆字段拆完再打开Wireshark对照验证。这个方法推荐给所有想真正把这关吃透的人。2. 搭建一个干净的抓包环境别在第一公里翻车报文分析的前提是能拿到一份“干净”的报文样本。头歌平台上有些关卡的报文是直接提供的但在实际练习里最好还是自己动手抓一份真实的DNS报文。整个过程要注意的地方不少。2.1 工具的选型与准备这一题最顺手的工具毫无疑问是Wireshark两个理由一是它能自动解析DNS协议层并展示字段含义方便做“标准答案”对照二是它自带强大的显示过滤器可以只保留DNS流量避免被无关的网络包淹没。安装Wireshark时有个提醒值得注意Windows下安装包会附带Npcap/WinPcap这个是抓包必需的底层驱动安装时务必勾选否则工具装好了也听不到网卡上的流量。另外如果只是看报文分析题里给出的固定报文也可以直接用Wireshark打开保存好的.pcapng文件不一定非要实时抓包。2.2 抓包时的网卡选择和过滤如果你决定自己抓包选对网卡比什么都重要。这里有个新手最常犯的错误笔记本开着Wi-Fi却选的是以太网卡抓了半天什么都抓不到。解决办法很简单——在Wireshark主界面看网卡列表后的实时流量条哪个在跳就选哪个。抓包开始后默认的capture filter建议直接写明udp port 53DNS默认走UDP 53端口只抓这个过滤条件就能让绝大多数流量不进入缓存。显示过滤器是抓到之后用的dns一条显示过滤器既能看到DNS查询Queries也能看到DNS响应Responses比抓包过滤器更灵活建议两个filter配合使用。2.3 最容易忽略的DNS缓存的坑很多人自己练习时遇到的问题不是抓不到包而是“想抓的包压根没发出去”。因为操作系统和浏览器都有DNS缓存同一个域名如果你之前访问过再次请求时直接命中缓存根本不会有DNS报文经过网卡。我在实训时就是反复刷新同一个域名等了几分钟一条DNS包都没有一度以为Wireshark装错了。后来才意识到是本地DNS缓存在作祟。清理缓存的命令很简单在Windows的命令提示符或PowerShell下执行ipconfig /flushdnsLinux/macOS下则用sudo systemd-resolve --flush-caches # 或 sudo killall -HUP mDNSResponder清完缓存之后再来一次nslookup或者浏览器访问DNS报文就乖乖出现在抓包列表里了。2.4 不依赖平台限制的备选方案有些实训环境的浏览器可能限制你安装软件或者你不想在自己电脑上装抓包工具这个不碍事。用在线DNS查询工具的“递推过程”展示功能也能看出查询报文的请求链路和最终的结果记录。但我个人的建议是如果条件允许还是尽量用Wireshark走一遍。因为这一关的核心目标是看懂二进制报文结构Wireshark的双排视图上排树状解析、下排十六进制是全世界最容易建立“字段和字节”对应关系的工具没有之一。3. 按字节拆开DNS报文头每一个标志位都在说什么拿到一个DNS报文后正常情况下你应该先看头部。DNS头部永远固定是12字节这也是整个DNS报文里最容易固定下来的标识。这一部分如果啃下来后面看问题部分和回答部分就只是“体力活”了。3.1 头部结构的核心字段为了方便说明我先给出一份常见的DNS报文十六进制数据我们后面都拿它来分析。这是一个权威DNS服务器解析example.com时截获的查询请求0x24 0x49 0x01 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x07 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x03 0x63 0x6f 0x6d 0x00 0x00 0x01 0x00 0x01从偏移0开始前12个字节是DNS头部。逐个字段看偏移字节数字段本例值含义0-12字节Transaction ID事务ID0x2449 9289对应查询和响应的匹配编号2-32字节Flags标志字段0x0100见下文逐位拆解4-52字节QDCOUNT问题数0x0001 1报文中包含1个问题6-72字节ANCOUNT回答数0x0000 0查询报文中没有回答8-92字节NSCOUNT权威记录数0x0000 0没有权威记录10-112字节ARCOUNT附加记录数0x0000 0没有附加记录写这段的时候我想多提醒一句计数字段的四个值之间不是对等关系。QDCOUNT代表“问题部分有几条”ANCOUNT代表“回答部分有几条”NSCOUNT和ARCOUNT分别对应权威和附加。判断一个报文是查询还是响应最直接的办法反而是看Flags而不是计数——因为响应报文的ANCOUNT通常不为零但并不是所有响应都一定有回答记录比如NXDOMAIN的错误响应。3.2 Flags标志字段的位级拆分这是DNS头部里最难懂、也是这一关最爱出考题的部分。Flags字段一共16位每一位或每几位都有明确含义。我们拿0x0100来拆。先把十六进制转成二进制0x0100 0000 0001 0000 0000逐位分配一下Bit 150x8000QR位0代表查询1代表响应。0x0100的最高位是0说明这是一个查询报文。Bit 14-110x7800Opcode4位0000表示标准查询。Bit 100x0400AA位Authoritative Answer权威回答查询请求中为0。Bit 90x0200TC位TrunCation截断标志0表示未截断。Bit 80x0100RD位Recursion Desired期望递归本例二进制恰好是1说明客户端希望DNS服务器帮忙递归解析。Bit 70x0080RA位Recursion Available允许递归查询中为0。Bit 60x0040Z位保留位必须为0。Bit 5-40x0020和0x0010AD位和CD位分别表示“应答是否经过DNSSEC验证”和“是否忽略验证结果”。现代DNS报文里越来越常见老教材不提它们但抓真实流量时经常会看到。比如CD位在客户端禁用DNSSEC校验时会置1这一点容易被忽略。Bit 3-0RCODE应答码0000表示无错误。也就是说0x0100这个标志字段的含义是标准查询、期望递归。加上前面的Transaction ID 9289就够凑成一次完整查询的头部特征了。对比一下如果是一个递归成功的响应报文它的Flags很可能长成0x8180二进制的拆法是0x8180 1000 0001 1000 0000从高到低QR1响应Opcode0000标准查询AA0非权威TC0未截断RD1期望递归RA1递归可用Z000RCODE0000无错误。把这两个状态记熟以后看Wireshark里的Flags那一行你能完全对上号就不需要在线上到处搜“0x8180代表什么意思”了。3.3 为何教科书写的是“两字节标志位”而不是“一个整数”初学者很容易被Wireshark里显示的那种“Flags: 0x0100 (Recursion desired)”给带偏以为标志位是一个完整的数值。但协议规定它是个位域也就是16个独立的位被成组赋予意义。所以你在分析报文的时候一定要“位级”地去读而不是把0x0100当普通整数去看。这一点我在实训时也是绕了一下才彻底转过弯来的。4. 问题部分Question Section怎么解析从域名编码到查询类型头部看完接着看QNAME。这部分是DNS报文分析里最“绕”的地方因为它不是直接用ASCII字符串存域名而是采用了一种“长度前缀标签”的编码方式。4.1 域名的压缩编码规则还是用前面的十六进制串头部结束之后从偏移12开始0x07 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x03 0x63 0x6f 0x6d 0x00解析规则是这样的每段标签以一个长度字节开始这个字节的数值表示后面紧跟的标签长度单位是字节然后跟上对应长度的ASCII字符直到遇见0x00表示域名结束。逐字节翻译0x07后面长度7字节0x65 0x78 0x61 0x6d 0x70 0x6c 0x65ASCII分别是 e x a m p l e拼起来是“example”0x03后面长度3字节0x63 0x6f 0x6dASCII分别是 c o m拼起来是“com”0x00域名终止符拼在一起就是“example.com”。这种编码为什么高效因为它把域名里被重复访问的标签比如com、net在同一个报文的多个地方只用一次大大缩减了报文体积。这个设计在上世纪80年代是相当精简的放到今天处理海量DNS查询时依然是有效功。建立这个认知之后问题部分剩下的两个字段就简单了QTYPE查询类型占2字节0x0001表示A记录查询也就是查IPv4地址0x001c表示AAAA记录查IPv6地址。QCLASS查询类别占2字节0x0001表示INInternet绝大多数场景都是这个值。按照这个规则继续解析我们的报文在域名结束标志0x00后面的四字节是0x00 0x01 0x00 0x01拆开就是QTYPE0x0001A查询QCLASS0x0001Internet。把这一节串起来问题部分的完整含义就是“请告诉我example.com的IPv4地址。”4.2 指针压缩响应报文里最坑的偏移量陷阱查询报文里QNAME的编码是直白的长前缀格式但到了响应报文里由于服务器经常需要在回答部分重复域名就会出现指针pointer。指针的标识是第一字节的高两位是“11”也就是0xC0开头。比如0xC0 0x0C这个指针表示不要直接读这里的字节作为域名而是跳回到当前DNS报文起始位置偏移0x0C的地方从那里开始重新解析域名。这个机制是救人也是坑人的。救人在于它的压缩效率极高尤其应对一条几百条记录的响应时非常有用坑人在于初学者一旦忘了检查字节的高两位就会把0xC0这一字节当成普通ASCII来读然后就出现“域名里面怎么有个乱码”的迷惑。举一个真实例子如果响应报文里回答部分有一条记录的NAME字段是0xC00C那么这个记录的域名就是整个DNS报文的第12个字节开始的那个域名也就是查询部分里的那个域名。这就是为什么我们在分析DNS响应报文时十六进制下面那一条蓝色的“Name: example.com”虽然看着是自动解析的但它背后的偏移跳转逻辑极其精妙。我自己的习惯是在Wireshark十六进制视图里点选Name字段时会自动高亮显示它实际引用的偏移位置。这个可视化联动功能非常有用建议你熟悉一下。理解了指针之后你才算真正跨进了DNS报文结构的门槛。5. 回答部分Answer Section里的门道从TTL到RDATA的逐条解读DNS响应的重头戏在回答部分。这部分一条记录由四个子字段构成NAME、TYPE、CLASS、TTL、RDLENGTH、RDATA。它们合起来描述了一条“资源记录”Resource RecordRR。5.1 一个完整资源记录的字段拆解假设抓到一个响应报文回答部分有这样一个RR从十六进制流角度展示0xC0 0x0C # NAME指针指向偏移12 0x00 0x01 # TYPE A 0x00 0x01 # CLASS IN 0x00 0x00 0x00 0x3C # TTL 60秒 0x00 0x04 # RDLENGTH 4字节 0x5D 0xB8 0xD8 0x22 # RDATA 93.184.216.34每个字段都不是白给的它的实际意义是这样的TTLTime To Live单位是秒。60秒意味着这条记录在收到它的缓存服务器上只存活60秒过期后必须重新向权威服务器询问。网站做DNS变更后迟迟不生效十有八九是TTL值设得很大旧记录一直在缓存中撑着。RDLENGTH指明RDATA的长度单位是字节。对于A记录而言因为返回IPv4地址固定是4字节AAAA记录则是16字节。根据RDLENGTH再去读RDATA是解析可变长度记录的核心手法。RDATA存放真正要返回的数据。A记录里就是4字节的IPv4地址十六进制0x5D B8 D8 22对应的十进制刚好是93.184.216.34。那TYPE还有其他常见值吗有而且你在真实环境里见到的频率很高。TYPE值含义RDATA格式A (1)IPv4地址4字节AAAA (28)IPv6地址16字节CNAME (5)别名指向域名压缩格式MX (15)邮件交换服务器优先级域名NS (2)权威域名服务器域名TXT (16)文本记录长度文本PTR (12)反向解析域名5.2 回答部分的长度依赖关系别只顾着看单条记录回答部分里记录的条数是由头部的ANCOUNT决定的而每条记录的解析边界是由RDLENGTH决定的。有一个很常见的操作错误是拿到一个响应报文直接跳到最后几行看IP地址却不看ANCOUNT。如果响应里有多条A记录比如example.com同时解析出两个IPv4地址而你只用固定偏移去看可能只看到了其中一条剩下的完全错过。比如头部ANCOUNT2回答部分连续跟着两条A记录每条都是“指针TYPECLASSTTLRDLENGTHRDATA”的完整结构。分析一条之后要立刻回到“当前偏移这条记录总长度”的位置去解析下一条而不是从头再来一遍。这种“长度依赖”思维是读懂几乎所有二进制协议的关键不止DNS如此。5.3 响应报文中找“授权回答”和“附加记录”区很多教材把你引导到回答部分就停了但真实报文里还有两个区域值得关注NSCOUNT对应的权威部分和ARCOUNT对应的附加部分。比如我抓过一个响应报文回答部分给了example.com的A记录权威部分带出了ns1.example.com的NS记录附加部分又附上了ns1.example.com的IP地址。这种“附加值”是把权威DNS服务器的地址一起告诉你省去你再发一次查询的麻烦。这一关如果只要求解析应答内容分析到RDATA基本就结束了。但如果你想进阶观察一下NSCOUNT和ARCOUNT不为0时的报文结构会让你对DNS整个工作模式的理解立体不少。6. 实测中的一个完整案例分析从请求到响应的完整对照到这里前面几部分都是把细节掰开了讲。但掌握碎片还不够真正要过这一关、以及今后做网络排查你需要习惯把请求和响应当作一对数据来对照分析。下面我复现一个完整的实测过程把整个过程串一遍。6.1 请求和响应的字段对应关系我在自己的电脑上清空DNS缓存后对example.com发起了一次nslookup请求。Wireshark里捕获到一前一后两个报文查询报文源端口随机目的端口53的关键字段Transaction ID0x8A2BFlags0x0100RD1期望递归QDCOUNT1问题部分example.com类型A响应报文源端口53目的端口为刚才的随机端口的关键字段Transaction ID0x8A2B与查询完全一致Flags0x8180QR1RD1RA1RCODE0QDCOUNT1ANCOUNT1回答部分example.comA记录TTL60RDATA93.184.216.34把两个报文放一起看有几个地方非常值得你看一眼就秒懂Transaction ID是客户端随机生成的每一条查询都不同响应报文里原样返回这样客户端才能把响应和查询对上。这就是为什么一个客户端同时发出几十个DNS查询也不会乱套。响应报文里一定会原封不动地带有问题部分也就是“你问了什么”接着才放“你问的东西的答案”。RCODE0表示服务器成功处理了查询。如果RCODE3那表示NXDOMAIN也就是这个域名压根不存在。6.2 校验和Checksum该不该看什么时候看UDP报文头部有校验和字段很多分析题会让你算一下。说实话日常用Wireshark分析DNS报文网络层和传输层的校验和一般不用手动算Wireshark自己会告诉你对不对。但这一关如果专门考到了报文校验有一点需要提醒UDP的校验和覆盖范围是伪头部UDP头部数据部分不是只看UDP头部。如果把“伪头部”这个概念忽略了算出来的校验和永远对不上。6.3 典型考题的可视化思路做这一类实训时我强烈建议你把Wireshark的“Packet Details”面板和“Packet Bytes”面板上下铺开点一下树状列表里的“Transaction ID”或者“Name: example.com”下方的十六进制区会同步高亮对应字节。这种“点击联动”的方式比直接看答案更能在脑子里建立位置感。反复点几遍你会自然形成“字段在报文里是有固定排布顺序”的肌肉记忆。等看完这个案例再回去看头歌第3关给出的题目你会发现它考的核心无非就是三类一是给定报文里找出头部字段Transaction ID、Flags、计数二是解释标志位的二进制含义三是根据回答部分写出查询的域名和解析结果。掌握了上面这套“头部→问题→回答”的完整阅读链这三类题都不再有难度。7. 踩坑总结几个我在实训中走过的弯路这部分就当是附加经验包把我自己在实际分析过程中遇到的问题集中列出来希望能帮你绕过这些看似不大但特别耗时的坑。7.1 把“响应”误判成“查询”或是反之排查问题第一步一定要先看QR位。如果上来就看计数字段查询报文的ANCOUNT是0你可能误以为抓到了服务器故障。实际上查询报文本来就不该有回答。反过来说如果一个“响应”报文里的QR位是0那它极有可能是伪装的查询报文在网络排障时要养成只看协议行为而非只看端口来源的检查习惯。7.2 被16进制展示“整懵”的时刻Wireshark默认把报文每个字节都按两位十六进制显示看起来是一串毫无规律的数字。第一次接触时非常容易晕。我的建议是不要尝试一次性看懂一整段二进制流而是按“12字节头部→问题部分→回答部分”的顺序切段看。一把整串报文从左往右读是读不出任何结构的结构本来就是分层的。7.3 理解“事务ID一样”不等于“两个报文完全一样”有一次实训题给了两个报文事务ID一样但内容显示一个是查询、一个是响应。我最初以为是平台的重复报文后来仔细看才发现一个是客户端发的查询另一个是服务器给的响应事务ID相同只是它们配对的证据。这个细节如果没看透很容易得出“平台数据发重复了”的错误结论。7.4 域名大小写问题容易忽略记录内容比较DNS域名在报文里严格要求大小写不敏感但规范上允许保留原始大小写。因此在做“字段一致性校验”时比较字符串之前要先统一转成小写。不然你会很疑惑为什么报文里写着WWW.Example.Com但服务器却给出了完全正常的应答。8. 一个推荐的分析顺序拿来就能用把所有细节都过完我整理出一套自己现在每次抓DNS报文都会采用的分析顺序。你可以直接照着这个顺序来练习尤其是做头歌这类实训平台的题目时它能把思考路径固定下来。第1步定方向。看QR位确认当前报文是查询0还是响应1。第2步看标志。读Opcode查询类型、RD是否要递归、RA服务器是否可递归、RCODE是否有错误。这几个值组合起来基本能判断这次交互是否正常。第3步结对账。记下Transaction ID在抓包文件里过滤同样ID的另一个方向报文确认它们成对出现。第4步看问题。从偏移12开始解析QNAME注意判断是普通长度前缀还是0xC0指针。读完QNAME后紧接着4字节是QTYPE和QCLASS。第5步看回答。如果ANCOUNT0先确认回答记录是从哪个偏移开始的然后按“NAME、TYPE、CLASS、TTL、RDLENGTH、RDATA”逐条拆拆完一条根据RDLENGTH跳到下一条的起始位置。第6步算验证。如果需要校验Checksum按UDP伪头部UDP头的规则做一遍如果只是判断报文是否有问题以Wireshark的Checksum Status列为准。这套流程熟练之后从打开pcap文件到口算出域名的解析结果正常情况下不超过两分钟。平时多抓几次包多关掉Wireshark的解析结果自己先猜一遍分析速度会提升得非常快。如果你想进一步扩展可以在这套顺序基础上尝试写一个简单的Python脚本用dpkt或scapy库读取pcap文件并自动提取出每个DNS报文的Transaction ID、域名和A记录。这会让你的“报文分析”能力从手工解析升级到自动化处理也更容易应对数据量大的场景——不过那就是这一关之外的乐趣了。
