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

[115517] Существует команда [115966]dnstracer[115967] (вам может понадобиться установить её, по крайней мере, в Debian, это также и имя пакета), которая отследит разрешение имен. Вы также можете (как указывает Коверас в комментарии) использовать [115968]dig[115969].

Вот команда dnstracer. [115970]-s .[115971] означает начинать с корня; [115972]-4[115973] означает использовать IPv4 (здесь нарушена v6...); [115974]-o[115975] означает на самом деле показывать разрешенные IP адреса в конце (я опустил эту часть вывода, их много).

Этот вывод продолжается, так как dnstracer трассирует все пути (так что вы можете увидеть, например,

1. Итак, вы можете видеть, что требуется один запрос к серверу имён корня, затем один к gtld-серверам (серверу для .com зоны), и, наконец, один к серверу имён Google.

2. С помощью [115976]dig[115977] вывод намного более подробный (так что я сделаю много вырезаний):

3. dig[115979] дополнительно показывает, что он сделал запрос для получения текущего списка серверов имён корня. Это то, что DNS-сервер обычно делает очень редко. Поэтому я не уверен, считаете ли вы это в вашем холодном кэше.

4. Вы, конечно, можете также смотреть фактические запросы на проводе с помощью, например, [115980]wireshark[115981].[115530].

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

Что ж, давайте выберем этот уровень отдельно.

"Предположим, что ваш настроенный сервер имён не имеет кэшированных результатов в своём распоряжении"[115987] -- во-первых, если он имеет [115988]нет[115989] кэшированных данных вообще, то он не может ничего разрешить. Для того, чтобы кэшировать резольвер, необходимо иметь записи NS и адрес (A, AAAA) для [115990].[115991] (корневая зона A.K.A.). Это корневые серверы имен, которые находятся в зоне [115992]root-servers.net.[115993]. Нет ничего волшебного ни в этой зоне, ни в этих DNS-серверах. Однако, эти данные часто предоставляются DNS resolver "вне диапазона", именно для подготовки кэша resolver. Авторитетным серверам имен эти данные не нужны, но разрешающим серверам имен нужны.

Также, "разрешающим" к чему? К какому-нибудь RR-типу этого имени? [115994]A[115995] RR? Или к чему-то еще? Какой класс ([115996]CH[115997]/Chaosnet, [115998]IN[115999]/Internet, ...)? Точный процесс будет другим, но общая идея останется прежней.

smb://username:password@192.168.0.1/ *or whatever your volume's IP is.*

Если мы можем предположить, что знаем, как найти корневые серверы имен, но не более того, и что под "разрешением" мы подразумеваем получение содержимого любых [116000]IN A[116001] RR, связанных с именем, то это становится намного практичнее.

Для разрешения DNS-имени, вы, в основном, разделяете имя на метки, а затем работаете справа налево. Не забудьте про [116002].[116003] в конце; на самом деле вы бы разрешили [116004]map.google.com.[116005], а не [116006]maps.google.com[116007]. Это оставляет нас с необходимостью разрешения (мы знаем это, но реализация DNS resolver вероятно не будет):

• .
• com.
• google.com.
• maps.google.com.
• Начните с выяснения, где можно запросить содержимое [116016].[116017]. Это просто; у нас уже есть эта информация: корневой сервер имен [116018]имена и IP-адреса[116019]. Итак, у нас есть сервер имен корня. Допустим, мы решили использовать 198.41.0.4 ([116020]a.root-servers.net[116021], также 2001:503:ba3e::2:30) для продолжения разрешения имен. На практике, одной из первых вещей, выполняемых преобразователем, скорее всего, будет использование предоставленных данных сервера корневой зоны для запроса на один из серверов корневой зоны точного списка серверов имен для корневой зоны, тем самым гарантируя, что если любое из имен и IP-адресов будет корректным и доступным, то, когда разрешение начнется, он будет иметь полный и полный набор данных для корневой зоны.
• Снимите DNS-запрос для [116022]map.google.com. В A[116023] к 198.41.0.4. В ответе будет сказано "нет, не буду, но вот кто-то может знать"; это направление. Он содержит [116024]NS[116025] записи для ближайшей зоны, о которой знает сервер, вместе с любыми клеевыми записями, которые есть у сервера. Если данные клея недоступны, вам сначала нужно разрешить хост, названный в выбранной вами NS-записи, чтобы получить IP-адрес; если данные клея недоступны, у вас будет IP-адрес сервера имен, который, по крайней мере, "ближе" к ответу. В этом случае, это будет набор серверов для зоны [116026]com.[116027], и данные клея также будут предоставлены.
• Повторите процесс, задав один из серверов имен [116028]com.[116029] тот же самый вопрос. Они тоже не знают, но направят вас к авторитетным серверам имен Google. На данный момент в общем случае, будет нанесен удар или пропущено, предоставляются ли данные о клее или нет; ничто не мешает домену [116030]com[116031] иметь серверы имен только в [116032]nl[116033], например, в этом случае данные о клее вряд ли будут доступны с серверов gTLD. Предоставленные данные о клее также могут быть неполными, а если вам действительно не повезло, то они могут быть даже неверными! Вы должны быть готовы к тому, что [116034]всегда [116035] будет порождать то отдельное разрешение имени, о котором я упоминал выше.

В основном, вы продолжаете работать до тех пор, пока не получите ответ с установленным флагом [116036]aa[116037] (авторитетный ответ). Этот ответ скажет вам, что вы просите, или что RR, который вы просите, не существует (либо [116038]NXDOMAIN[116039], либо [116040]NOERROR[116041] с записями данных нулевого ответа). Продолжайте искать ответы типа [116042]SERVFAIL[116043] (и отступите на один шаг и попробуйте другой сервер, если он у вас есть; если все именованные серверы вернутся [116044]SERVFAIL[116045], то провалите процесс разрешения имен и верните [116046]SERVFAIL[116047] клиенту самостоятельно).

Альтернативой запроса полного RRname с каждого сервера (что можно считать плохой практикой) является использование разделенного списка меток, который мы определили ранее, запрос серверов имен, предоставленных сервером далее к корню для [116048]IN NS[116049] и [116050]IN A[116051]/[116052]IN AAAA[116053] RRs для этой метки, и использование этих меток для дальнейшего процесса разрешения имен. Это лишь незначительно отличается на практике, и тот же самый процесс все еще применяется.

Вы можете смоделировать весь этот процесс, используя опцию [116054]+trace[116055] к утилите [116056]dig[116057], которая идет как часть BIND, или [116058]set debug[116059] в [116060]nslookup[116061]. Также стоит помнить, что некоторые RR-типы (в частности, [116062]NS[116063], [116064]MX[116065] и некоторые другие; кроме того, [116066]A6[116067] довольно хорошо использовался в течение некоторого времени, но был устаревшим) могут и делают ссылки на другие RR. В этом случае, возможно, вам понадобится икра [116068]еще один [116069] процесс разрешения имен, чтобы дать полный и полезный ответ вашему клиенту.[115566].