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服务器管？"
实战步骤：
- 开Wireshark选网卡（选正在用的那个，wifi选wlan0，有线选eth0）
- 在过滤器栏输入
dns后回车（别输引号） - 打开终端执行：
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.arpaWireshark里你会看到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.114Wireshark里会清晰看到：
- 请求直接发往114DNS（目标IP 114.114.114.114）
- 响应包里可能有不同的Answer（不同DNS策略不同）
有次我比较三大DNS的响应速度，发现：
- 谷歌8.8.8.8平均200ms
- 阿里223.5.5.5平均80ms
- 腾讯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劫持功能被黑产利用。
