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 .
