Сейчас я прохожу онлайн-курс для системных администраторов Linux, и мне задали вопрос, который я вообще не понимаю. Я знаю, как искать сервер имен, если я правильно понимаю, по крайней мере, это использование команды dig для поиска адреса в дополнительной секции, но я немного растерялся, когда мне задали следующий вопрос.
Если предположить, что ваш настроенный сервер имен не имеет кэшированных результатов в своем распоряжении, сколько серверов имен должен запросить ваш сервер имен, чтобы разрешить maps.google.com? Какую(ые) команду(ы) вы бы использовали, чтобы найти все эти серверы имен? Перечислите по одному из каждого уровня и объясните, почему этот уровень необходим.
Мне не нужен ответ, я просто хочу знать, что именно меня просят сделать.
решение1
Если предположить, что ваш настроенный сервер имен не имеет кэшированных результатов в своем распоряжении, сколько серверов имен должен запросить ваш сервер имен, чтобы разрешить maps.google.com? Какую(ые) команду(ы) вы бы использовали, чтобы найти все эти серверы имен? Перечислите по одному из каждого уровня и объясните, почему этот уровень необходим.
Ну что ж, давайте разберем это подробнее.
«Предполагается, что ваш настроенный сервер имен не имеет в своем распоряжении никаких кэшированных результатов»-- во-первых, если у него естьнеткэшированные данные вообще, то он не может ничего разрешить. Чтобы подготовить кэш резолвера, вам нужно иметь записи NS и адреса (A, AAAA) для .(AKA root) зоны. Это корневые серверы имен, которые находятся в зоне root-servers.net.. Нет ничего магического в этой зоне или этих DNS-серверах. Однако эти данные часто предоставляются «вне диапазона» резолверу DNS, именно для подготовки кэша резолвера. Серверам имен, работающим только с полномочиями, эти данные не нужны, но серверам имен, разрешающим имена, они нужны.
Также, "разрешить" во что? Любой RRtype с таким именем? ARR? Или что-то еще? Какой класс ( CH/Chaosnet, IN/Internet, ...)? Точный процесс будет другим, но общая идея останется прежней.
Если предположить, что мы знаем, как найти корневые серверы имен, но не более того, и что под «разрешением» мы подразумеваем получение содержимого всех IN Aзаписей ресурсов, связанных с именем, то все становится гораздо более практичным.
Чтобы разрешить имя DNS, вы в основном разделяете имя на метки, а затем работаете справа налево. Не забудьте в .конце; вы действительно будете разрешать, maps.google.com.а не maps.google.com. Это оставляет нас с необходимостью разрешать (мы это знаем, но реализация DNS-резолвера, вероятно, не будет):
.com.google.com.maps.google.com.
Начните с выяснения того, где можно запросить содержание. . Это просто; у нас уже есть эта информация: корневой сервер именимена и IP-адреса. Итак, у нас есть корневой сервер имен. Допустим, мы решили использовать 198.41.0.4 ( a.root-servers.net, также 2001:503:ba3e::2:30) для продолжения разрешения имен. На практике одним из первых действий резолвера, скорее всего, будет использование предоставленных данных корневого сервера для запроса одного из серверов корневой зоны на точный список серверов имен для корневой зоны, тем самым гарантируя, что если какое-либо из имен и IP-адресов является допустимым и доступным, у него будет полный и завершенный набор данных для корневой зоны, когда начнется разрешение.
Отправьте DNS-запрос на maps.google.com. IN A198.41.0.4. В ответ вы получите ответ: «Нет, я этого делать не буду, но вот кто-то, кто может знать»; это ссылка. Она содержит NSзаписи для ближайшей зоны, о которой знает рассматриваемый сервер, а также любые записи Glue, которые есть у сервера. Если данные Glue недоступны, вам сначала нужно разрешить этот хост, указанный в выбранной вами записи NS, поэтому создайте отдельное разрешение имени, чтобы получить IP-адрес; если данные Glue доступны, у вас будет IP-адрес сервера имен, который по крайней мере «ближе» к ответу. В этом случае это будет набор серверов для зоны com., а также предоставляются данные Glue.
Повторите процесс, задав один com.и тот же вопрос одному из серверов имен. Они тоже не знают, но направят вас к авторитетным серверам имен Google. На этом этапе в общем случае будет либо не дано, либо нет данных Glue; нет ничего, что мешает домену comиметь серверы имен только в nl, например, в этом случае данные Glue вряд ли будут доступны с серверов gTLD. Предоставленные данные Glue также могут быть неполными, или, если вам совсем не повезет, они могут быть даже неверными! Вам нужновсегдабудьте готовы к появлению отдельного разрешения имен, о котором я упоминал выше.
По сути, вы продолжаете, пока не получите ответ с aaустановленным флагом (авторитетный ответ). Этот ответ скажет вам, что вы запрашиваете, или что запрошенный вами RR не существует (либо NXDOMAIN, либо NOERRORс нулевыми записями данных ответа). Продолжайте искать ответы типа SERVFAIL(и отступите на один шаг и попробуйте другой сервер, если получите один; если все именованные серверы возвращают SERVFAIL, провалите процесс разрешения имен и вернитесь SERVFAILк клиенту).
Альтернативой запросу полного имени RR с каждого сервера (что может считаться плохой практикой) является использование разделенного списка меток, который мы определили ранее, запрос серверов имен, предоставленных сервером, далее по направлению к корню для IN NSи IN A/ IN AAAARR для этой метки и использование их для дальнейшего процесса разрешения имени. Это лишь незначительно отличается на практике, и тот же процесс по-прежнему применяется.
Вы можете смоделировать весь этот процесс, используя +traceопцию утилиты dig, которая входит в состав BIND, или set debugв nslookup.
Также стоит помнить, что некоторые типы RR (в частности NS, MXи некоторые другие; также,A6 довольно часто использовался некоторое время, но был объявлен устаревшим) могут ссылаться и ссылаются на другие RR. В этом случае вам может потребоваться вызватьеще одинпроцесс разрешения имени, чтобы дать полный и полезный ответ вашему клиенту.
решение2
Есть dnstracerкоманда (вам может потребоваться ее установить, по крайней мере на Debian, это также имя пакета), которая отследит разрешение имен. Вы также можете (как указывает Коверас в комментарии) использовать dig.
Вот с dnstracer. -s .означает начать с корня; -4означает использовать IPv4 (v6 здесь сломан...); -oозначает фактически показать разрешенные IP-адреса в конце (я опустил эту часть вывода, их много).
anthony@Zia:~$ dnstracer -s . -4 -o maps.google.com
Tracing to maps.google.com[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4)
|\___ m.gtld-servers.net [com] (192.55.83.30)
| |\___ ns4.google.com [google.com] (216.239.38.10) Got authoritative answer
| |\___ ns3.google.com [google.com] (216.239.36.10) Got authoritative answer
| |\___ ns1.google.com [google.com] (216.239.32.10) Got authoritative answer
| \___ ns2.google.com [google.com] (216.239.34.10) Got authoritative answer
⋮
Этот вывод продолжается, поскольку dnstracer отслеживает все пути (чтобы вы могли увидеть, например, не имеют ли некоторые серверы имен устаревшую зону).
Итак, вы видите, что один запрос отправляется на корневой сервер имен, затем один на gtld-servers (сервер для зоны .com) и, наконец, один на сервер имен Google.
С dig, вывод будет гораздо более подробным (поэтому я буду делать много сокращений):
dig -4 maps.google.com. +norecurse +trace
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> maps.google.com. +norecurse +trace
;; global options: +cmd
. 425379 IN NS b.root-servers.net.
⋮
com. 172800 IN NS f.gtld-servers.net.
⋮
google.com. 172800 IN NS ns2.google.com.
⋮
maps.google.com. 300 IN A 74.125.228.70
⋮
digдополнительно показывает, что он сделал запрос для получения текущего списка корневых серверов имен. Это то, что DNS-сервер обычно делает очень редко. Так что я не уверен, учитываете ли вы это в вашем случае с холодным кэшем.
Конечно, вы также можете отслеживать реальные запросы в сети, например, с помощью wireshark.