dig + traceは実際にどのように機能しますか？

digの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.

それでは、実際にこれはどのように機能しますか？dig機能的に同等になる同等の一連のコマンド（+ traceなし）は何ですか？

dig +trace ネームサーバーであるかのように動作し、ツリーのルートから開始され、途中でリフェラルをたどる反復クエリを使用して、ネームスペースツリーをたどります。

最初に行うことは、「。」のNSレコードを通常のシステムDNSサーバーに要求することです。

ルートネームサーバーの現在のリストである応答を取得した後、1つを選択し、最初に追加のレコードセクションで取得しなかった場合はその名前の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ネームサーバーの1つを選択し、同じ質問をします。

$ 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のように1つを選択し、そのアドレスを見つける必要があります。私たちは、再起動（再ルートで）クエリをして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

（つまり、ルートサーバーの1つを照会して、.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