记一次dig与dig +trace选项之间的探究

直接先上man文档得到的结果：

+[no]trace
Toggle tracing of the delegation path from the root name servers for the name being looked up. Tracing is disabled
by default. When tracing is enabled, dig makes iterative queries to resolve the name being looked up. It will follow
referrals from the root servers, showing the answer from each server that was used to resolve the lookup.

If @server is also specified, it affects only the initial query for the root zone name servers.

环境：内网机器，可以出外网

      自建本域根：a.root-servers.jia

因为涉及到公司网络环境的内容，就不截图了。

本人在内网用BIND 9.16.26版本搭建了自己的本域根服务器，dig ns . @自建的域名服务器，可以正常返回自建的那些根；

dig ns . @自建的域名服务器 +trace，就会报错：

couldn't get address for 'a.root-servers.xxx': not found，说自定义的那些根域找不到。

首先想到的就是用strace命令去跟踪，看一下dig都调用了哪些系统函数，发现与域名解析有关的有一行：

openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY) = 6

初步怀疑是跟本机配置的默认的nameserver 8.8.8.8有关系，把这个换成自建的域名服务器ip，然后再进行+trace，

就可以正常返回结果了。

然后，通过tcpdump抓包，来进一步分析dig +trace与不加选项的区别。

比如，配置文件/etc/resolv.conf nameserver 8.8.8.8

dig www.baidu.com @自建的域名服务器

这时的报文流向是在客户端与自建的域名服务器之间，也即没有经过8.8.8.8；

dig www.baidu.com @自建的域名服务器 +trace

这时的报文流向，首先是客户端与自建的域名服务器之间，先获取到自建的域名服务器的根节点，

然后就变成了客户端与本机配置文件/etc/resolv.conf里的nameserver的报文，也即8.8.8.8(dns.google.domain)去解析你自建的

那些自定义根，这个返回结果肯定就是not found了，因为市面上那些域名解析服务器怎么可能会记录你自建的那些根呢。

再回过头看man文档，

If @server is also specified, it affects only the initial query for the root zone name servers.

意思是dig +trace @server，这个命令行里的server，只是影响了首次查询.的NS记录时，等从server查询到.的NS记录之后，

接下来就是/etc/resolv.conf 里配置的那个nameserver去解析这些NS记录及后续的工作了。

这也解释了strace的时候，为什么我们会看到打开了/etc/resolv.conf文件，而strace只能到系统调用这个层面，打开了这个文件

也并不意味着每次都会用到里面的内容，而tcpdump抓包让我们看到了整个详细的过程。