Как работает DNS-запрос
Когда я набираю www.google.com, как работает поиск DNS. Насколько мне известно, он сначала идет на корневой сервер и выясняет, где находится DNS-сервер.com. Затем он возвращает IP-адрес этого сервера. Далее оттуда узнает, где находится сервер Google. Теперь он возвращает IP-адрес, и это место, где находится www.google.com.
Таким образом, чтобы решить эту проблему, нужны два DNS-поиска. Поправь меня, если я ошибаюсь.
6 ответов
Разрешение DNS может стать довольно проблематичным, когда вы начнете рассматривать такие вещи, как кэширование и anycast, но давайте пока оставим это простым.
Вот фрагменты раскопок рядом с фрагментами tcpdumps запроса для www.google.com на недавно запущенный сервер имен, поэтому кэширование не используется. Я сократил некоторые временные метки для удобочитаемости.
Сначала локальный сервер имен (здесь 192.168.10.10) запрашивает у одного из корневых серверов (в данном случае h.root-servers.net, 128.63.2.53) запрос "что такое запись A для www.google.com?" h.root-servers.net не является полномочным для www.google.com, но имеет делегирование для.com, поэтому возвращает его.
192.168.10.10.17203 > 128.63.2.53.53: 29969 [1au] A? www.google.com. (43)
128.63.2.53.53 > 192.168.10.10.17203: 29969- 0/15/16 (719)
;; QUESTION SECTION:
;www.google.com. IN A
;; AUTHORITY SECTION:
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
Во-вторых, локальный сервер имен затем выбирает один из серверов имен из списка, возвращаемого h.root-servers.net, и отправляет тот же запрос: "Что такое запись A для www.google.com?" В этом случае запрашиваемым сервером имен был f.gtld-servers.net (192.35.51.30). f.gtld-servers.net, который является полномочным для.com, ответил делегированием сервера имен для зоны google.com.
192.168.10.10.65182 > 192.35.51.30.53: 58632 [1au] A? www.google.com. (43)
192.35.51.30.53 > 192.168.10.10.65182: 58632- 0/4/5 (179)
;; QUESTION SECTION:
;www.google.com. IN A
;; AUTHORITY SECTION:
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
Все ближе! Теперь локальный сервер имен выбирает один из серверов имен в последнем ответе и задает ему тот же вопрос. В этом случае он запрашивает ns2.google.com (216.239.34.10). ns2.google.com отвечает, что www.google.com на самом деле является записью CNAME (каноническое имя) для www.l.google.com.
192.168.10.10.4767 > 216.239.34.10.53: 15830 [1au] A? www.google.com. (43)
216.239.34.10.53 > 192.168.10.10.4767: 15830*- 6/0/0 CNAME[|domain]
;; QUESTION SECTION:
;www.google.com. IN A
;; ANSWER SECTION:
www.google.com. 604800 IN CNAME www.l.google.com.
Очень близко! Теперь нам просто нужен адрес www.l.google.com. Теперь, поскольку мы уже знаем серверы имен для google.com, мы просто спросим одного из них. В этом случае мы спрашиваем ns3.google.com (216.239.36.10) "что такое запись A для www.l.google.com.?" Он отвечает адресом, и у нас есть наш ответ:
192.168.10.10.63657 > 216.239.36.10.53: 62511 [1au] A? www.l.google.com. (45)
216.239.36.10.53 > 192.168.10.10.63657: 62511*- 5/0/0 A[|domain]
;; QUESTION SECTION:
;www.l.google.com. IN A
;; ANSWER SECTION:
www.l.google.com. 300 IN A 74.125.232.116
www.l.google.com. 300 IN A 74.125.232.112
www.l.google.com. 300 IN A 74.125.232.115
www.l.google.com. 300 IN A 74.125.232.113
www.l.google.com. 300 IN A 74.125.232.114
Ура!
Во всяком случае, я надеюсь, что этого достаточно, чтобы начать. Есть много отличных ресурсов там. Книга О'Рейли "DNS и BIND" очень полезна.
Я настоятельно рекомендую установить dig, чтобы увидеть, как идут запросы DNS. Например, вы можете использовать dig +trace, чтобы легко увидеть путь делегирования к хосту:
; <<>> DiG 9.7.0-P1 <<>> +trace www.google.com
;; global options: +cmd
. 516930 IN NS k.root-servers.net.
. 516930 IN NS g.root-servers.net.
. 516930 IN NS h.root-servers.net.
. 516930 IN NS j.root-servers.net.
. 516930 IN NS a.root-servers.net.
. 516930 IN NS m.root-servers.net.
. 516930 IN NS b.root-servers.net.
. 516930 IN NS f.root-servers.net.
. 516930 IN NS d.root-servers.net.
. 516930 IN NS c.root-servers.net.
. 516930 IN NS l.root-servers.net.
. 516930 IN NS i.root-servers.net.
. 516930 IN NS e.root-servers.net.
;; Received 244 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 492 bytes from 202.12.27.33#53(m.root-servers.net) in 45 ms
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
;; Received 168 bytes from 192.33.14.30#53(b.gtld-servers.net) in 42 ms
www.google.com. 604800 IN CNAME www.l.google.com.
www.l.google.com. 300 IN A 74.125.232.115
www.l.google.com. 300 IN A 74.125.232.113
www.l.google.com. 300 IN A 74.125.232.116
www.l.google.com. 300 IN A 74.125.232.114
www.l.google.com. 300 IN A 74.125.232.112
;; Received 132 bytes from 216.239.34.10#53(ns2.google.com) in 131 ms
Заметьте, насколько это похоже на трассировку запроса ранее? Надеюсь, это поможет.
Это немного сложнее, поскольку DNS довольно сильно кешируется. Ваша локальная машина может даже кэшировать данные, и поиск не идет дальше.
Ваша машина будет запрашивать свой собственный кеш, а в случае сбоя она будет запрашивать основной DNS-сервер, о котором ей сообщили. Это может быть кеширующий DNS-сервер, и у меня есть результат в его кеше, и в этом случае запись возвращается вам, и поиск заканчивается. Скорее всего, это рекурсивный DNS-сервер, и теперь он будет выполнять всю работу на вашем компьютере.
Если основной DNS-сервер не имеет информации, он будет запрашивать корневые серверы имен, на которые они ответят (в вашем примере) серверами имен TLD для.com
Запрос будет отправлен на серверы домена верхнего уровня.com, которые ответят адресом полномочного сервера имен для google.com.
На официальный сервер имен google.com будет отправлен запрос с запросом на запись www.google.com. Он будет найден и возвращен на основной DNS-сервер, который кеширует его и возвращает запись вам.
DNS является иерархическим и, как сказал Лэйн, сильно кешируется. Возможно, вам может помочь более сложный пример.
Предположим, у вас есть машина, принадлежащая компании с несколькими бизнес-единицами, которые отражены в структуре домена. Ваша машина имеет имя machine.businessunit1.company.com, то есть принадлежит businessunit1.company.com, который является основным DNS-суффиксом.
Подразделение очень большое и управляет несколькими DNS-серверами (dns1.businessunit1.company.com, dns2.businessunit1.company.com), а также, например, веб-сервером www.businessunit1.company.com.
Если ваша машина теперь хочет разрешить www.businessunit1.company.com, она сначала ищет локальный DNS-кеш. И. е. Ваша машина сама запоминает записи DNS, которые вы недавно запрашивали, потому что весьма вероятно, что вам снова понадобятся результаты, например, когда вы нажимаете ссылку на веб-сайте. Я не знаю, можете ли вы увидеть, что ваша машина кэшировала, но есть команда для удаления всего, что ваша машина помнила (в Windows): ipconfig /flushdns
Если ваша машина не помнит ответ, она спросит - как я ранее прокомментировал - DNS-сервер (ы), которые настроены для вашего сетевого адаптера. Скорее всего, ваши администраторы настроили dns1.businessunit1.company.com и dns2.businessunit.company.com. Причина в том, что вы хотите, чтобы ваш DNS-запрос отвечал быстро, без большого трафика. Если dns1.businessunit1.company.com получит ваш запрос для www, он ответит на него, поскольку он является полномочным для зоны *.businessunit1.company.com. Авторитетный означает, что этот сервер знает единственный правильный ответ для всех имен DNS, оканчивающихся на "businessunit1.company.com".
Теперь предположим, что у вас есть вопросы www.businessunit2.company.com. Ваша машина, если она не помнит сам ответ, снова спросит dns1.businessunit1.company.com. Теперь есть много возможностей: во-первых, ваши администраторы могут быть умными, и они предвидят, что весьма вероятно, что люди из businessunit1 также захотят часто получать доступ к компьютерам в businessunit2. Поэтому они настроили dns1.businessunit1.company.com для хранения копии данных с dns1.businessunit2.company.com. dns1.businessunit1.company.com может использовать эту копию, чтобы ответить на ваш вопрос. Во-вторых, ваши администраторы обязательно скажут dns1.businessunit1.company.com, что делать, если он не знает ответа на ваш вопрос: это запрос другого DNS-сервера. Возможно, это dns1.company.com, но это может быть и любой другой DNS-сервер, включая корневые серверы.
Как сказал Лейн, dns1.businessunit1.company.com может запомнить любой ответ, полученный от других DNS-серверов. И. е. если вы запрашиваете www.google.com, возможно, придется запросить другой сервер, но если вы спросите второй раз, он запомнит ответ и сообщит вам напрямую.
Вы можете увидеть, где находится ваш ответ DNS, когда вы набираете, например, nslookup www.google.com, Выходные данные скажут вам сервер и является ли это авторитетным ответом или нет. Скорее всего, он будет неавторизованным, поскольку на него не отвечают DNS-серверы Google, которые отвечают за все DNS-имена, заканчивающиеся на "google.com".
На самом деле все очень сложно и зависит от DNS-сервера. Unbound сделать 66 запрос.
Вы не ошиблись. Вот отличная иллюстрация того, как работает DNS-запрос.