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

Question

dns
dig

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

35641

Doktor J 2014-02-12 в 00:28

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

12

2 ответа на вопрос

30

1

Paul 2014-02-12 в 00:52

Допустим, вы искали

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

Как мне обратиться к теме делегирования? Допустим, полномочия для domain.co.uk - dns.dns1.de, но members.domain.co.uk делегирован dns.dns2.com, и я ищу joe.members.domain.co.uk. Как узнать, когда "безопасно" сойти с карусели SOA и запросить другие записи? Doktor J 10 лет назад 0

Фактический процесс требует записи `A` все время. Нет волшебного переключения на запросы `SOA`. (Не может быть, так как разрешающий прокси не будет знать, когда переключиться обратно.) В этом вопросе также нет волшебной модификации доменного имени. Это `www.domain.ru '. Это важно помнить, потому что это означает, что любой из опрошенных контент-серверов может предоставить полный ответ. JdeBP 10 лет назад 0

@DoktorJ Да, это моя ошибка, JdeBP прав. Я пытался найти точку с SOA, но это запуталось в ответе. Другой ответ более точный. Paul 10 лет назад 0

@Paul спасибо за продолжение; Я пометил другой ответ как правильный ответ, чтобы выручить любого, кто может оказаться здесь (без обид!) :) Doktor J 10 лет назад 0

@doktorj Совсем нет, именно так и должно быть :) Paul 10 лет назад 0

Accepted Answer · 2014-02-12 02:33:43

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работает.

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

2 ответа на вопрос

Похожие вопросы