dig +trace działa poprzez udawanie, że jest serwerem nazw i działa w dół drzewa nazw, używając zapytań iteracyjnych rozpoczynających się w katalogu głównym drzewa, po poleceniach po drodze.
Pierwszą rzeczą, jaką robi, jest poproszenie normalnego serwera DNS o rekordy NS dla „.”
Po otrzymaniu odpowiedzi, która będzie aktualną listą głównych serwerów nazw, wybierze jedną, a następnie poprosi o rekord A dla tej nazwy, jeśli nie dostanie jej w sekcji dodatkowych rekordów za pierwszym razem, więc adres IP, aby wysłać następne zapytanie do. Powiedzmy, że wybiera f.root-servers.net, którego adres IP to 192.5.5.241.
W tym momencie użyjmy dig +trace www.google.co.uk. jako nasze polecenie z nazwą domeny chcemy prześledzić ścieżkę rozdzielczości dla.
Następnym pytaniem za kulisami będzie to:
$ 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
Wow, więc teraz wiemy, że istnieją serwery nazw uk i to jedyna rzecz, o której wie serwer główny. To jest skierowanie , ponieważ nie poprosiliśmy o rekursję ( +norecurse wyłącza go).
Świetnie, my płukamy i powtarzamy. Tym razem wybieramy jedną z uk serwery nazw i zadaj to samo pytanie .
$ 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
Niesamowite, teraz dowiedzieliśmy się, że uk serwer nazw najwyższego poziomu wie, że została wywołana strefa google.co.uk i mówi nam, żebyśmy poszli zadać naszym imiennikom nasze pytanie. To jest kolejne skierowanie.
Spłucz, powtórz.
Tym razem jednak nie dostaliśmy rekordów A w sekcji dodatkowych rekordów odpowiedzi, więc wybieramy jeden, powiedzmy ns2.google.com, i musimy znaleźć jego adres. My uruchom ponownie zapytanie (ponownie w katalogu głównym) i ścigaj drzewo, aby znaleźć adres IP dla ns2.google.com. Pominę tę część dla zwięzłości, ale dowiadujemy się, że adres IP to 216.239.34.10.
Nasze następne zapytanie brzmi:
$ 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
I skończyliśmy! (w końcu) Skąd wiemy, że skończyliśmy? Mamy odpowiedź na nasze zapytanie, które było rekordami A dla www.google.co.uk. Możesz również powiedzieć, ponieważ nie jest to już skierowanie aa bit jest ustawiony w znaczeniu ostatniej odpowiedzi to jest autorytatywna odpowiedź dla twojego zapytania.
Tak właśnie dzieje się na każdym kroku podczas użytkowania dig +trace.
Zauważ, że jeśli posiadasz wersję dig i jesteś świadomą DNSSEC, dodaj +dnssec do polecenia możesz zobaczyć więcej rekordów. To, co te dodatkowe rekordy są, pozostawiam jako ćwiczenie dla czytelnika ... ale wpada w to jak dig +sigchase Prace.