Как на самом деле работает dig + trace?

Когда я смотрю на справочную страницу для 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), которая будет функционально эквивалентной?

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, и нам нужно найти ее адрес. Мы перезапускаем запрос (снова в корне) и прогоняем дерево, чтобы найти IP-адрес для ns2.google.com. Я пропущу эту часть для краткости, но мы узнаем, что 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

И мы сделали! (наконец) Откуда мы знаем, что мы закончили? Мы получили ответ на наш запрос, который был A записи для www.google.co.uk. Вы также можете сказать, потому что это больше не реферал, aaбит устанавливается в последнем ответе, что означает, что это официальный ответ на ваш запрос.

Так вот что происходит каждый шаг на пути, когда вы используете dig +trace.

Обратите внимание, что если у вас есть версия dig с поддержкой DNSSEC, и вы добавляете +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