当我查看 dig 的手册页时，我得到以下内容：
+[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.
dig那么，在实践中，这是如何工作的呢？功能上等效的一系列命令（没有 +trace）是什么？
答案1
dig +trace它假装自己是一个名称服务器，并从树的根开始，使用迭代查询沿着命名空间树向下工作，并沿着沿途的引用进行操作。
它所做的第一件事是向正常系统 DNS 服务器询问“。”的 NS 记录。
在收到响应（即当前的根名称服务器列表）后，它会选择一个，然后请求该名称的 A 记录（如果第一次没有在附加记录部分获得该记录），这样它就有了一个 IP 地址可以发送下一个查询。假设它选择了 f.root-servers.net，其 IP 地址为 192.5.5.241。
此时，让我们使用dig +trace www.google.co.uk.想要跟踪解析路径的域名作为命令。
下一个幕后查询将是这样的：
$ dig +norecurse @192.5.5.241 www.google.co.uk
; <<>> DiG 9.9.4 <<>> +norecurse @192.5.5.241 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8962
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 15
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.co.uk. IN A
;; AUTHORITY SECTION:
uk. 172800 IN NS ns5.nic.uk.
uk. 172800 IN NS ns6.nic.uk.
uk. 172800 IN NS ns4.nic.uk.
uk. 172800 IN NS nsc.nic.uk.
uk. 172800 IN NS ns2.nic.uk.
uk. 172800 IN NS ns3.nic.uk.
uk. 172800 IN NS nsd.nic.uk.
uk. 172800 IN NS nsa.nic.uk.
uk. 172800 IN NS ns7.nic.uk.
uk. 172800 IN NS nsb.nic.uk.
uk. 172800 IN NS ns1.nic.uk.
;; ADDITIONAL SECTION:
ns1.nic.uk. 172800 IN A 195.66.240.130
ns2.nic.uk. 172800 IN A 217.79.164.131
ns3.nic.uk. 172800 IN A 213.219.13.131
ns4.nic.uk. 172800 IN A 194.83.244.131
ns5.nic.uk. 172800 IN A 213.246.167.131
ns6.nic.uk. 172800 IN A 213.248.254.130
ns7.nic.uk. 172800 IN A 212.121.40.130
nsa.nic.uk. 172800 IN A 156.154.100.3
nsb.nic.uk. 172800 IN A 156.154.101.3
nsc.nic.uk. 172800 IN A 156.154.102.3
nsd.nic.uk. 172800 IN A 156.154.103.3
ns1.nic.uk. 172800 IN AAAA 2a01:40:1001:35::2
ns4.nic.uk. 172800 IN AAAA 2001:630:181:35::83
nsa.nic.uk. 172800 IN AAAA 2001:502:ad09::3
;; Query time: 45 msec
;; SERVER: 192.5.5.241#53(192.5.5.241)
;; WHEN: Tue Feb 11 19:19:14 MST 2014
;; MSG SIZE rcvd: 507
哇，现在我们知道有名称服务器，uk而且这是根服务器唯一知道的事情。 这是一个推荐，因为我们没有要求递归（+norecurse将其关闭）。
很好，我们重复一遍。这次我们选择其中一个uk域名服务器并问同样的问题。
$ dig +norecurse @195.66.240.130 www.google.co.uk
; <<>> DiG 9.9.4 <<>> +norecurse @195.66.240.130 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 618
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.co.uk. IN A
;; AUTHORITY SECTION:
google.co.uk. 172800 IN NS ns1.google.com.
google.co.uk. 172800 IN NS ns3.google.com.
google.co.uk. 172800 IN NS ns2.google.com.
google.co.uk. 172800 IN NS ns4.google.com.
;; Query time: 354 msec
;; SERVER: 195.66.240.130#53(195.66.240.130)
;; WHEN: Tue Feb 11 19:22:47 MST 2014
;; MSG SIZE rcvd: 127
太棒了，现在我们发现uk顶级名称服务器知道有一个名为 的区域google.co.uk，并告诉我们去向这些名称服务器询问我们的问题。这是另一个推荐。
冲洗，重复。
然而，这一次，我们没有在响应的附加记录部分获得 A 记录，所以我们选择一个，比如 ns2.google.com，然后我们必须找到它的地址。我们重新开始查询（再次在根节点）并追踪树以找到 ns2.google.com 的 IP 地址。为了简洁起见，我将跳过该部分，但我们知道它的 IP 是 216.239.34.10。
因此我们的下一个查询是：
$ dig +norecurse @216.239.34.10 www.google.co.uk
; <<>> DiG 9.9.4 <<>> +norecurse @216.239.34.10 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33404
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.google.co.uk. IN A
;; ANSWER SECTION:
www.google.co.uk. 300 IN A 74.125.225.216
www.google.co.uk. 300 IN A 74.125.225.223
www.google.co.uk. 300 IN A 74.125.225.215
;; Query time: 207 msec
;; SERVER: 216.239.34.10#53(216.239.34.10)
;; WHEN: Tue Feb 11 19:26:43 MST 2014
;; MSG SIZE rcvd: 82
我们完成了！（终于）我们怎么知道我们完成了？我们得到了查询的答案，即 www.google.co.uk 的 A 记录。你也可以知道，因为它不再是一个引荐，该aa位在最后一个响应中设置，这意味着这是权威答案为您的查询。
这就是您使用时每一步发生的情况dig +trace。
请注意，如果您有支持 DNSSEC 的 dig 版本，并且您+dnssec向命令中添加了内容，您可能会看到更多记录。这些额外记录是什么，留给读者练习吧……但要了解其dig +sigchase工作原理。
答案2
假设你正在抬头
www.domain.co.uk
DNS 是一个层次结构，从根服务器开始，根服务器知道哪些服务器对 TLD（域名的最后一部分）具有权威性。因此，相当于
dig subdomain.domain.co.uk
一步一步来：
dig SOA @g.root-servers.net uk
（即查询其中一个根服务器以查找谁是 .uk 的权威服务器）
这将响应一系列权威的英国服务器，因此我们询问他们谁拥有 co.uk
dig SOA @ns6.nic.uk co.uk
我们被告知 SOA（权威）位于同一台服务器上
因此，让我们查询 ns1.nic.uk 来查看谁拥有 domain.co.uk
dig SOA @ns1.nic.uk domain.co.uk
返回结果显示域名的权限位于 dns.dns1.de（加上备份）；
现在我们可以请求 A 记录：
dig A @dns.dns2.de www.domain.co.uk
;; QUESTION SECTION:
;www.domain.co.uk. IN A
;; ANSWER SECTION:
www.domain.co.uk. 86400 IN CNAME domain.co.uk.
domain.co.uk. 86400 IN A 95.130.17.36