DNS协议实战：从报文捕获到权威解析【头歌】

1. DNS协议基础与实战环境搭建

DNS（Domain Name System）就像互联网世界的电话簿，负责把人类易记的域名翻译成机器识别的IP地址。每次你在浏览器输入网址，背后都藏着至少一次DNS查询。这次我们不用枯燥的理论，直接上手实战——用Wireshark抓包工具把DNS通信过程扒个精光。

先说说实验环境。我推荐在Linux系统下操作，Windows和Mac也能跑但命令稍有不同。你需要准备：

• Wireshark（最新版就行，别用老古董）
• nslookup（系统自带，但Windows和Linux用法略有差异）
• 一个能联网的电脑（废话，但真的有人问过断网能不能做这实验）

安装Wireshark时有个坑要注意：普通用户默认没权限抓包。在Ubuntu下用这个命令快速解决：

sudo usermod -aG wireshark $USER

然后注销重新登录。不这么搞的话，待会儿抓包时会发现网卡列表是灰的，别问我怎么知道的——说多了都是泪。

2. 捕获NS记录查询全过程

NS记录好比域名界的"114查号台"，告诉你该找谁问路。比如查询baidu.com的NS记录，相当于问："百度这个地盘归哪个DNS服务器管？"

实战步骤：

1. 开Wireshark选网卡（选正在用的那个，wifi选wlan0，有线选eth0）
2. 在过滤器栏输入dns后回车（别输引号）
3. 打开终端执行：

nslookup -type=NS baidu.com

这时候Wireshark会突然刷出一堆数据包，别慌。找到那个显示"Standard query NS baidu.com"的请求包，和对应的响应包。重点看三个地方：

• 请求包的Question部分会显示：

  Name: baidu.com Type: NS (authoritative name server)

• 响应包的Answer部分藏着宝：

  baidu.com nameserver = ns1.baidu.com baidu.com nameserver = ns2.baidu.com ...

  这就是百度的"官方指路人"

有个骚操作你可能不知道：在Wireshark里右键任意DNS包，选"Follow > UDP Stream"，能看到原始报文对比。我上次用这招发现某公共DNS居然篡改响应，吓得赶紧换了服务商。

3. 反向DNS解析的玄机

PTR记录玩的是"反查"——通过IP找域名。比如黑客追踪时常用这招查IP归属，运维也用它做访问控制。但反向查询有个奇葩设定：IP要倒着写！

操作实录：

nslookup -type=PTR 39.156.69.79.in-addr.arpa

Wireshark里你会看到Query部分长这样：

Name: 39.156.69.79.in-addr.arpa Type: PTR

如果响应包里有Answer，可能会返回类似：

39.156.69.79.in-addr.arpa = www.baidu.com

为什么倒着写？这得从DNS的树状结构说起。想象IP是电话号码，国家码-区号-本地号，DNS从右往左解析就像打电话先拨国家码。有次我手贱没倒置直接查，结果收到个NXDOMAIN错误，愣是查了半小时文档才明白过来。

4. 指定DNS服务器查询技巧

默认用ISP的DNS？太天真了！用nslookup 域名 DNS服务器IP可以指定问谁。比如：

nslookup baidu.com 114.114.114.114

Wireshark里会清晰看到：

• 请求直接发往114DNS（目标IP 114.114.114.114）
• 响应包里可能有不同的Answer（不同DNS策略不同）

有次我比较三大DNS的响应速度，发现：

1. 谷歌8.8.8.8平均200ms
2. 阿里223.5.5.5平均80ms
3. 腾讯119.29.29.29竟然有50%丢包 后来才知道那天腾讯DNS在升级...

5. DNS报文结构深度拆解

抓到的包在Wireshark里展开看，DNS报文其实分五个部分：

Header头部（12字节固定）：

• ID：会话标识（像快递单号）
• QR：0是查询，1是响应
• RD：要求递归查询（打钩服务器就得负责到底）
• RA：服务器支持递归（打钩表示"我能接这活"）

Question问题区：

• QNAME：查询的域名（如baidu.com）
• QTYPE：查询类型（A/NS/MX等）
• QCLASS：查询类（通常都是IN，指Internet）

Answer回答区（可能多个记录）：

• NAME：域名
• TYPE：记录类型
• TTL：缓存有效期（单位秒）
• RDATA：记录数据（比如IP地址）

实战技巧：在Wireshark搜索栏输入dns.flags.response == 1可以只看响应包。有次排查DNS污染，我就是用这招快速定位到被篡改的响应。

6. 常见问题排查实录

场景1：抓不到DNS包？

• 检查过滤器是不是输错了（是dns不是DNS）
• 确认网卡没选错（虚拟机用户经常选成NAT虚拟网卡）
• 试试ping baidu.com同时抓包，先确认基础抓包功能正常

场景2：响应报文中TC标志位为1？

• 表示报文被截断，通常因为UDP包超过512字节
• 解决方案是改用TCP查询：

dig +tcp baidu.com NS

场景3：响应码RCODE非0？

• 2：服务器故障（SOA记录配置错误我见过）
• 3：域名不存在（输错域名常见）
• 5：查询被拒绝（企业内网DNS常有权限控制）

记得有次内网开发，RCODE=5折腾半天，最后发现是IT部门新加了白名单。所以看到错误码先查RFC文档，比瞎猜高效多了。

7. 高阶玩法与安全分析

EDNS扩展： 现代DNS支持扩展机制（RFC6891），允许更大的UDP包。Wireshark里看OPT记录：

Type: OPT UDP payload size: 4096

没这个的话，DNSSEC等高级功能会受限。

DNSSEC验证： 在响应包找AD标志位：

• AD=1表示数据经过完整验证
• 但要注意客户端必须配置信任锚才能验证

缓存投毒攻击： 观察异常现象：

• 相同Query ID连续出现
• 权威服务器突然变成陌生IP
• TTL异常大（攻击者希望持久化）

有次我抓包发现某公共WiFi的DNS响应TTL高达86400秒（24小时），明显不正常，后来证实是路由器的DNS劫持功能被黑产利用。