Jak naprawdę działa dig + trace?

Kiedy patrzę na stronę man dla dig, otrzymuję następujące informacje:

+[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.

Jak to działa w praktyce? Jaka byłaby odpowiednik serii dig komendy (bez + śledzenia), które byłyby funkcjonalnie równoważne?

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.

Powiedzmy, że patrzyłeś w górę

www.domain.co.uk

DNS jest hierarchią, począwszy od serwerów głównych, które wiedzą, które serwery są autorytatywne dla TLD (ostatnia część nazwy domeny). Więc odpowiednik

dig subdomain.domain.co.uk

Krok po kroku byłoby:

dig SOA @g.root-servers.net uk

(tj. wyślij zapytanie do jednego z serwerów głównych, aby dowiedzieć się, kto jest autorytatywny dla .uk)

Odpowiada to serią autorytatywnych serwerów uk, więc pytamy ich, kto ma co.uk

dig SOA @ns6.nic.uk co.uk

Powiedziano nam, że SOA (autorytet) jest na tych samych serwerach

Więc wyślij zapytanie ns1.nic.uk, aby zobaczyć, kto ma domain.co.uk

dig SOA @ns1.nic.uk domain.co.uk

Wraca i mówi, że uprawnienia do domeny to dns.dns1.de (plus kopie zapasowe);

Więc teraz możemy poprosić o rekord 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