Этот вопрос изначально был задан здесь: Почему для файлов зоны DNS требуются записи NS?
Подводя итог: «Когда я иду к своему регистратору и покупаю example.com, я сообщаю своему регистратору, что мои серверы имен - это ns1.example.org и ns2.example.org».
Но, пожалуйста, кто-нибудь может прояснить следующее:
После регистрации в реестре .com теперь будет запись, в которой указывается, что преобразователю необходимо посетить ns1.example.org или ns2.example.org, чтобы узнать IP-адрес example.com. IP-адрес находится в записи A в файле зоны на ns1.example.org и имеет идентичную копию на ns2.example.org.
Однако внутри этого файла также должны быть 2 записи NS, в которых в качестве серверов имен указаны ns1.example.org и ns2.example.org. Но поскольку мы уже находимся на одном из этих серверов, похоже, это дублированная информация.
Первоначальный ответ на вопрос гласил, что серверы имен, перечисленные в файле зоны, являются «авторитетными». Если серверы имен не совпадают, приоритет имеют авторитетные серверы имен. Это все очень хорошо, но преобразователь прибыл на сервер имен, используя серверы имен перечислен в реестре .com, и если сервер имен не совпадает, то преобразователь будет искать файл зоны на неправильном сервере имен и не сможет его найти.
Или это случай, когда реестр .com извлекает информацию о сервере имен из записи ns файла зоны? (Но тогда я полагаю, что если вы измените ns, запись файла зоны без сообщив реестру, у него не было бы возможности узнать, где искать.)
Спасибо
Давайте немного разберемся.
Записи 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. Детали зависят от сервера, но цель состоит в том, чтобы кэшировать как можно больше, не открывая дверь сарая, позволяя любому серверу случайных имен в Интернете отменять записи делегирования для чего-либо, официально не находящегося под его «юрисдикцией».
Реестр .com - это «связующая запись», в которой в качестве IP-адреса указывается местоположение ваших серверов имен. У распознавателя нет способа узнать «идентичность» вашего DNS-сервера, поэтому он использует NS-запись для обеспечения совпадения чисел.
Запрос DNS -> реестр .com (ip - x.x.x.x) -> DNS (NS x.x.x.x) соответствует, разрешить.
Если они не совпадают или не существуют, то это не авторитетный ответ для домена.