dig + trace如何实际起作用？

当我查看手册页进行挖掘时，会得到以下信息：

+[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）是什么？

dig +trace 通过假装它是一个名称服务器来工作，并使用迭代查询从名称树开始，从树的根目录开始，然后进行引用。

它要做的第一件事是向普通系统DNS服务器查询NS记录中的“。”。

得到响应后，它将是根名称服务器的当前列表，它将选择一个，然后在第一次在附加记录部分中未获得该名称的情况下询问该名称的A记录。发送下一个查询的IP地址。假设它选择了IP地址为192.5.5.241的f.root-servers.net。

此时，让我们将其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工作原理。

假设您在抬头

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