Давайте разберемся с этим немного.
Записи NS в зоне TLD (например, example.com NS ...в com) являются записями делегирования .
Записи A и AAAA в зоне TLD (например, ns1.example.com A ...в com) являются связующими записями.
Записи NS в самой зоне (то есть example.com NS ...в example.com) являются авторитетными записями.
Записи A и AAAA в самой зоне ( ns1.example.com A ...в example.com) являются адресными записями, простыми и понятными.
Когда (рекурсивный) распознаватель запускается без кэша данных вашей зоны и только с кэшем корневой зоны (который используется для начальной загрузки процесса разрешения имен), он сначала перейдет к ., а затем com.. Эти comсерверы будут реагировать с ответом власти раздела , который в основном говорит : «Я не знаю, но посмотрите здесь для кого - то , кто знает», так же как серверы для .дел о com. Этот ответ на запрос не является официальным и не содержит заполненный раздел с ответами. Он может также включать в себя так называемом дополнительномраздел, в котором приведены сопоставления адресов для любых имен хостов, о которых знает конкретный сервер (либо из склеенных записей, либо, в случае рекурсивных преобразователей, из ранее кэшированных данных). Средство распознавания примет этот ответ делегирования, разрешит имя хоста записи NS, если это необходимо, и продолжит запрашивать сервер DNS, которому были делегированы полномочия. Этот процесс может повторяться несколько раз, если у вас глубокая иерархия делегирования, но в конечном итоге приводит к ответу на запрос с установленным флагом «авторитетный ответ» .
Важно отметить, что распознаватель (как правило, мы надеемся) не будет пытаться разбить имя хоста, которое будет разрешено спрашивать о нем по частям, а просто отправит его полностью на «лучший» сервер, о котором он знает. Поскольку средний авторитетный сервер имен в Интернете не является авторитетным для подавляющего большинства действительных DNS-имен, ответом будет неавторизованный ответ делегирования, указывающий на какой-либо другой DNS-сервер.
Теперь серверу не нужно указывать имена в записях делегирования или полномочий в любом месте, чтобы быть полномочным для зоны. Рассмотрим, например, случай частного главного сервера; в этом случае существует авторитетный DNS-сервер, о котором знают только администраторы подчиненных DNS-серверов зоны. DNS-сервер является полномочным для зоны, если, по ее мнению, он обладает полными и точными знаниями о данной зоне. Нормально уполномоченный DNS-сервер может, например, стать неавторизованным, если не удается достичь настроенных главных серверов в течение срока, определенного как время истечения в записи SOA.
Только достоверные ответы должны рассматриваться как правильные ответы на запросы; все остальное - либо делегирование, либо какая-то ошибка. Делегирование на неавторизованный сервер называется «хромым» делегированием и означает, что распознаватель должен вернуться на один шаг назад и попробовать другой DNS-сервер с другим именем. Если в делегировании не существует никаких авторитетных достижимых серверов имен, то разрешение имен не выполняется (в противном случае это будет медленнее, чем обычно).
Это все важно, потому что неавторизованные данные не должны кэшироваться . Как это может быть, поскольку неавторизованный сервер не имеет полной картины? Таким образом, авторитетный сервер должен сам по себе ответить на вопрос «кто должен быть авторитетным и для чего?». Это информация, предоставленная записями NS в зоне.
Существует целый ряд крайних случаев, когда это может на самом деле иметь серьезное значение, в основном вокруг нескольких меток имен хостов в одной зоне (вероятно, довольно часто встречающихся, например, в обратных зонах DNS, особенно для больших динамических диапазонов IP), или когда список серверов имен отличается между родительская зона и рассматриваемая зона (что, скорее всего, является ошибкой, но также может быть сделано преднамеренно).
Вы можете увидеть, как это работает, более подробно, используя digего +norec(не запрашивая рекурсию) и @функции спецификатора сервера. Ниже приводится иллюстрация того, как работает фактический разрешающий DNS-сервер. Запрос записи A для unix.stackexchange.comначала, например a.root-servers.net:
$ dig unix.stackexchange.com. A @a.root-servers.net. +norec
Посмотрите внимательно на количество, flagsа также количество разделов. qrявляется ответом на запрос и aaявляется официальным ответом. Обратите внимание, что вы делегированы только на comсерверы. Вручную следуйте этому делегированию (в реальной жизни рекурсивный распознаватель будет использовать IP-адрес из дополнительного раздела, если он предусмотрен, или инициировать отдельное разрешение имен одного из именованных серверов имен, если в ответе на делегирование не указаны IP-адреса, но мы будем пропустите эту часть и просто вернитесь к обычному распознавателю операционной системы для краткости примера):
$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec
Теперь вы видите, что stackexchange.comэто делегировано (среди прочих) ns1.serverfault.com, и вы все еще не получаете авторитетного ответа. Снова следуйте за делегацией:
$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;unix.stackexchange.com. IN A
;; ANSWER SECTION:
unix.stackexchange.com. 300 IN A 198.252.206.16
Бинго! Мы получили ответ, потому что aaфлаг установлен, и он содержит IP-адрес, как мы и надеялись найти. Кроме того, стоит отметить, что, по крайней мере, на момент написания этой статьи списки серверов имен делегированных и перечисленных полномочий различались, показывая, что эти два значения не обязательно должны быть идентичными. То, что я привел в качестве примера выше, - это, в основном, работа, выполняемая любым распознавателем, за исключением того, что любой практический распознаватель также будет кешировать ответы по пути, чтобы ему не приходилось каждый раз обращаться к корневым серверам.
Как видно из приведенного выше примера, записи о делегировании и связывании служат целям, отличным от записей полномочий и адресов в самой зоне.
Кэширующий, разрешающий сервер имен также обычно выполняет некоторые проверки работоспособности возвращаемых данных для защиты от заражения кэша. Например, он может отказаться кэшировать ответ, comв котором указаны официальные серверы для источника, отличного от того, который уже был назван родительской зоной как удаленный для com. Детали зависят от сервера, но цель состоит в том, чтобы как можно больше кешировать, не открывая дверь сарая, позволяющую любому серверу случайных имен в Интернете переопределять записи делегирования для чего-либо, что официально не относится к его «юрисдикции».