dig +trace命令
dig @ip 域名 类型 +trace
工作过程
以 dig pbc.gov.cn +trace 为例。
-
用户看到的结果
-
wireshark抓包看到的结果（只显示了查询部分，响应就是查询目的对源地址的响应）
| 步骤 | 源 | 目的 | 查询 |
|---|---|---|---|
| 1 | 本机 | @ip中指定的ip | .的NS |
| 2 | 本机 | 本地DNS | .的NS的A（可能会尝试查询多个NS的A） |
| 3 | 本机 | 根 | pbc.gov.cn的NS |
| 4 | 本机 | 本地DNS | gov.cn的NS的A（可能会尝试查询多个NS的A） |
| 5 | 本机 | gov.cn的NS | pbc.gov.cn的NS |
| 6 | 本机 | 本地DNS | pbc.gov.cn的NS的A（可能会尝试查询多个NS的A） |
| 7 | 本机 | pbc.gov.cn的NS | pbc.gov.cn的NS |
运行含义
dig命令加上trace之后：
- 需要从根开始去迭代查询
- 每次去查询NS的迭代工作就由本机完成，而不是递归服务器完成了
dig 加上trace之后其实是想知道完整的域名迭代查询过程。而由于本机拿不到递归服务器的迭代查询报文，所以通过自己去迭代查找的过程。每次查询NS的A还要通过本地DNS完成，可能是因为本机无法像递归一样，从得到的NS报文中解析出ADDITIONAL字段中对应NS的A记录。而查询NS的A记录的时候，可能会查询多个NS的A，原因还不太清楚。
参考文献
【CSDN】通过wireshark抓包详细分析dig +trace每个报文的请求
【百度文库】DNS报文研究 通过抓包分析dig +trace跟踪全过程