直接先上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抓包讓我們看到了整個詳細的過程。