Как работает разрешение имен DNS в принципе?

Сейчас я прохожу онлайн-курс по системному администратору Linux, и мне задали вопрос, который я просто не понимаю. Я знаю, как искать сервер имен, если я прав, по крайней мере, он использует команду dig для поиска адреса в дополнительной команде section, но я немного растерялся, когда задал следующий вопрос.

Если ваш настроенный сервер имен не имеет кэшированных результатов, сколько серверов имен должен запросить ваш сервер имен для разрешения maps.google.com? Какие команды вы бы использовали, чтобы найти все эти серверы имен? Перечислите по одному на каждом уровне и объясните, почему этот уровень необходим.

Я не хочу ответа, я просто хотел бы знать, что именно меня просят сделать.

Если ваш настроенный сервер имен не имеет кэшированных результатов, сколько серверов имен должен запросить ваш сервер имен для разрешения maps.google.com? Какие команды вы бы использовали, чтобы найти все эти серверы имен? Перечислите по одному на каждом уровне и объясните, почему этот уровень необходим.

Хорошо, давайте выберем это.

«Предполагая, что у настроенного сервера имен нет кэшированных результатов» - во-первых, если у него вообще нет кэшированных данных, то он ничего не может разрешить. Чтобы заполнить кэш резолвера, вам нужно иметь записи NS и адреса (A, AAAA) для зоны .(AKA root). Это корневые серверы имен, которые находятся в root-servers.net.зоне. В этой зоне или этих DNS-серверах нет ничего волшебного. Тем не менее, эти данные часто предоставляются «вне диапазона» для распознавателя DNS, именно для заполнения кеша преобразователя. Только для авторитетных серверов имен эти данные не нужны, а для разрешения серверов имен.

Также «разрешить» на что? Любой тип RR на это имя? ARR? Или что-то другое? Какой класс ( CH/ Chaosnet, IN/ Интернет, ...)? Точный процесс будет другим, но общая идея останется прежней.

Если мы можем предположить, что мы знаем, как найти корневые серверы имен, но не более того, и что под «разрешением» мы подразумеваем получение содержимого любых IN ARR, связанных с именем, это становится намного более практичным.

Чтобы разрешить 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-адреса действительны и доступны, у них будет полный и полный набор данных для корневой зоны, когда начнется разрешение.

maps.google.com. IN AОтстрелить DNS-запрос на 198.41.0.4. В ответ он скажет: «Нет, не собираюсь этого делать, но вот кто-то, кто может знать»; это реферал. Он содержит NSзаписи для ближайшей зоны, о которой знает рассматриваемый сервер, а также любые склеенные записи, которые сервер имеет в наличии. Если склеенные данные недоступны, вам сначала нужно разрешить хост, названный в выбранной вами записи NS, поэтому создайте отдельное разрешение имен, чтобы получить IP-адрес; если доступны клейкие данные, у вас будет IP-адрес сервера имен, который как минимум «ближе» к ответу. В этом случае это будет набор серверов для com.зоны, а также предоставляются склеенные данные.

Повторите процесс, задав один из com.серверов имен тот же вопрос. Они тоже не знают, но направят вас к авторитетным серверам имен Google. На этом этапе в общем случае будет удар или пропуск, независимо от того, предоставлены ли данные склеивания или нет; ничто не мешает comдомену иметь серверы имен только nl, например, в этом случае склеенные данные вряд ли будут доступны с серверов рДВУ. Предоставленные данные клея также могут быть неполными, или, если вам действительно не повезло, это может быть даже неверно! Вы всегда должны быть готовы к появлению той отдельной резолюции имен, которую я упоминал выше.

По сути, вы продолжаете, пока не получите ответ с установленным 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. В этом случае вам может понадобиться запустить еще один процесс разрешения имен, чтобы дать полный и полезный ответ вашему клиенту.

Существует dnstracerкоманда (вам может потребоваться установить ее, по крайней мере, в Debian, это также имя пакета), которая отслеживает разрешение имен. Вы также можете (как указывает Koveras в комментарии) использовать dig.

Вот с днстрачером. -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-серверам (серверу для зоны .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.