直接先上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

因為涉及到公司網路環境的內容，就不截圖了。

本人在內網搭建了自己的本域根伺服器，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抓包讓我們看到了整個詳細的過程。