когда я набираю www.google.com, как работает поиск DNS. Насколько мне известно, он сначала обращается к корневому серверу и выясняет, где находится DNS-сервер .com. Затем он возвращает IP-адрес этого сервера. Далее выясняется, где находится сервер Google. Теперь он возвращает IP-адрес, и это будет место, где находится www.google.com.
Итак, чтобы решить эту проблему, необходимы два поиска DNS. Поправьте меня, если я ошибаюсь.
Разрешение DNS может стать довольно проблемным, если вы начнете рассматривать такие вещи, как кеширование и произвольное рассылку, но пока давайте не будем усложнять.
Вот фрагменты раскопок рядом с фрагментами 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
Запрос будет отправлен на серверы TLD .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), а также e. грамм. веб-сервер www.businessunit1.company.com.
Если ваша машина теперь хочет разрешить www.businessunit1.company.com, она сначала выполнит поиск в локальном кэше DNS. I. e. ваша машина сама запоминает записи 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. Теперь есть много возможностей: во-первых, ваши администраторы могут быть сообразительными, и они предвидели, что весьма вероятно, что люди из бизнес-подразделения 1 также захотят часто получать доступ к машинам в бизнес-подразделении 2. Поэтому они настроили 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-серверов. I. e. если вы запрашиваете www.google.com, возможно, ему придется спросить какой-то другой сервер, но если вы спросите второй раз, он запомнит ответ и сообщит вам напрямую.
Вы можете в основном увидеть, откуда пришел ваш ответ DNS, когда набираете e. грамм. nslookup www.google.com. Вывод сообщит вам сервер и будет ли это достоверный ответ или нет. Скорее всего, он будет неавторитетным, потому что на него не отвечают DNS-серверы Google, которые отвечают за все DNS-имена, оканчивающиеся на «google.com».
На самом деле все очень сложно и зависит от DNS-сервера. Несвязанный сделать 66 запрос.
Вы не ошиблись. Вот отличная иллюстрация того, как работает DNS-запрос.
Это верно. И, возможно, еще один поиск субдомена "www".
