Рейтинг:1

Почему dig не показывает раздел полномочий и как заставить его показывать авторитетные серверы имен, которые содержат ответ на DNS-запрос?

флаг br

Недавно я начал изучать DNS и застрял при использовании команды dig в Linux. Точнее, я хотел бы видеть авторитетные серверы имен (их имена или IP-адреса), которые содержат ответы на мои DNS-запросы, и я не знаю, как это сделать. Как вы, наверное, уже знаете, вывод команды dig состоит из 5 разделов: HEADER, QUERY, ANSWER, AUTHORITY и ADDITIONAL. Последние 3 включают записи ресурсов, найденные в ответе на DNS-запрос, отправленный dig. Меня интересует раздел AUTHORITY, в котором обычно должны отображаться записи ресурсов типа NS (сервер имен), предоставляющие информацию об авторитетных серверах имен, с которых извлекается ответ на исходный запрос. Полномочные серверы, конечно, отличаются от кэш-серверов тем, что могут повысить эффективность.

Теперь моя проблема в том, что каждый раз, когда я вызываю dig, ответ не содержит записей AUTHORITY. Возможно, я не знаю нужных параметров или может возникнуть какая-то другая проблема, о которой я не знаю. В чем могут быть причины неполучения ответа от властей и что нужно сделать, чтобы его получить? Я бы выложил образ терминала но у меня пока нет 10 репутации, но вопрос остается.

Рейтинг:3
флаг cn

Точнее, я хотел бы видеть авторитетные серверы имен (их имена или IP-адреса), которые содержат ответы на мои DNS-запросы, и я не знаю, как это сделать.

Все зависит от того, какой сервер имен вы запрашиваете. Если вы ничего не укажете с @ флаг, он использует локальный рекурсивный, чтобы дать вам окончательный ответ.Этот ответ мог быть вычислен рекурсивным сервером имен, опрашивающим множество различных авторитетных серверов имен, прежде чем прийти к ответу, поэтому в этом сценарии нет «одного» авторитетного сервера имен.

Если вы можете копать с +след он будет вести себя как рекурсивный сервер имен и покажет вам каждый шаг разрешения, с каждым запрошенным авторитетным сервером имен и его ответом.

Меня интересует раздел AUTHORITY, в котором обычно должны отображаться записи ресурсов типа NS (сервер имен), предоставляющие информацию об авторитетных серверах имен, с которых извлекается ответ на исходный запрос.

Это сложнее, чем это. Это зависит от того, какой сервер имен вы запрашиваете, и какой запрос вы делаете.

Давайте использовать serverfault.com например (и помните копать землю делает А запрос типа записи по умолчанию) и сравните рекурсивный сервер имен, авторитетный для имени, авторитетный для родителя.

Запрос рекурсивного сервера имен

$ dig serverfault.com @9.9.9.9 +noall +auth +nottlunits
$

Как и ожидалось, в разделе AUTHORITY нет данных. Рекурсивный сервер имен не является авторитетным для данных, поэтому он просто дает вам ответ, который вы запрашиваете.

Опрос авторитетных серверов имен зоны

$ dig serverfault.com NS +short
ns-cloud-c1.googledomains.com.
ns-cloud-c2.googledomains.com.
ns-1135.awsdns-13.org.
ns-860.awsdns-43.net.
$ dig serverfault.com @ns-cloud-c1.googledomains.com. +noall +auth +nottlunits
$

Никакого ПОЛНОМОЧИЯ тоже потому что оно вам просто не нужно, это оптимизация. Обратите внимание, что если вы запросите серверы имен AWSDNS, вы получите раздел AUTHORITY, но это бесполезно.

Опрос родительских авторитетных серверов имен

$ копать ком. НС +короткий
b.gtld-servers.net.
k.gtld-servers.net.
d.gtld-servers.net.
i.gtld-servers.net.
j.gtld-servers.net.
f.gtld-servers.net.
h.gtld-servers.net.
c.gtld-servers.net.
например, gtld-servers.net.
g.gtld-servers.net.
m.gtld-servers.net.
a.gtld-servers.net.
l.gtld-servers.net.
$ dig serverfault.com @g.gtld-servers.net. +noall +auth +nottlunits
serverfault.com. 172800 В NS ns-860.awsdns-43.net.
serverfault.com. 172800 В NS ns-1135.awsdns-13.org.
serverfault.com. 172800 В NS ns-cloud-c1.googledomains.com.
serverfault.com. 172800 В NS ns-cloud-c2.googledomains.com.

Здесь вы всегда (независимо от того, какой из вышеперечисленных серверов имен вы запрашиваете) получите раздел AUTHORITY (и фактически не раздел ANSWER), потому что у этих серверов имен нет ответа на ваш запрос, поскольку они не являются авторитетными в отношении имени, но они знают делегирование существует, поэтому они возвращают вам в AUTHORITY список серверов имен, которые вы должны запросить вместо этого.

Это обычный рабочий процесс делегирования DNS.

PS:

Я бы выложил образ терминала но у меня пока нет 10 репутации

Нет, ни в коем случае не ставьте изображение. Терминал — это строки текста. Скопируйте и вставьте соответствующие, КАК ТЕКСТ, в любой вопрос. Категорически не прикрепляйте скриншот, это плохо по всем аспектам.

jakeprog123 avatar
флаг br
Большое спасибо за ваш подробный и прямолинейный ответ. Хотел бы я получить такие ответы на все свои вопросы, но я признаю, что это также касается терпения и того, как вы формулируете вопрос.
Рейтинг:1
флаг br

Я только что понял, что «dig» неявно использует серверы имен, найденные в /etc/resolv.conf. Это те, на которые «dig» по умолчанию отправляет любой DNS-запрос. Таким образом, если я наберу, например, «dig google.com», я не получу никаких авторитетных записей в выводе, но если я укажу определенный сервер имен для запроса по его IP-адресу, например «dig @byte.byte.byte. byte google.com», может случиться так, что вы получите ответ, содержащий раздел с ненулевыми правами доступа. Итак, насколько я могу понять до сих пор, вывод команды «dig» может сильно различаться в зависимости от того, какой сервер имен вы запрашиваете, и если база данных этого сервера определена как содержащая авторитетную запись в качестве ответа на ваш запрос, тогда вы получаете авторитетные записи в ответе. Надеюсь, я недалек от истины. Если вы обнаружите какие-либо ошибки или информацию, которая может быть добавлена, пожалуйста, добавьте комментарий.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.