Блог

Почему авторитетному серверу имен необходимо хранить указатели о example.com домен обслуживается сам по себе?

Ваш вопрос не относится ни к Amazon, ни к определенному TLD, ни к позиции TLD в дереве DNS, нижеприведенное применимо везде в DNS.

Данный сервер имен (фактически набор серверов имен) является авторитетным в зоне. Следовательно, он содержит полное содержимое зоны, которое включает в себя SOA и NS записи зоны. Он является авторитетным по отношению к нему.

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

Итак, у вас есть одна информация в двух местах, но дочерний элемент является авторитетным в этом. Может случиться так, что оба были десинхронизированы, это называется неудачным делегированием. Но ожидается, что распознаватели будут верить дочерней версии содержимого, а не родительской.

В RFC1034 у вас есть это:

Хотя логически они являются частью авторитетных данных, RR, описывающие верхний узел зоны, особенно важны для управления зоной. Эти RR бывают двух типов: RR сервера имен, в которых перечислены, по одному на RR, все серверы для зоны, и один RR SOA, который описывает параметры управления зоной.

и о разделении, и какая сторона является авторитетной:

RR, которые описывают разрезы в нижней части зоны, — это NS RR, которые называют серверы для подзон. Поскольку разрезы находятся между узлами, эти RR НЕ являются частью достоверных данных зоны и должны быть точно такими же, как соответствующие RR в верхнем узле подзоны. Поскольку серверы имен всегда связаны с границами зоны, NS RRS находятся только на узлах, которые являются верхним узлом некоторой зоны. В данных, составляющих зону, NS RR находятся в верхнем узле зоны (и являются авторитетными) и в разрезах вокруг нижней части зоны (где они не являются авторитетными), но никогда между ними.

Документ по терминологии DNS (RFC 8499) также пытается уменьшить путаницу:

Достоверные данные: «Все RR, подключенные ко всем узлам от верхнего узла зоны до конечных узлов или узлов выше, проходят по нижнему краю зоны». (Цитируется по [RFC1034], раздел 4.2.1) Обратите внимание, что это определение может непреднамеренно также привести к включению любых записей NS, которые появляются в зоне, даже тех, которые могут не быть действительно авторитетными, потому что есть идентичные записи NS RR ниже границы зоны. Это показывает двусмысленность понятия авторитетных данных, поскольку записи NS на родительской стороне авторитетно указывают на делегирование, даже если они сами не являются авторитетными данными.

Что касается

какой смысл в этой записи SOA сообщать ANS ns1.awsdns.com это ns1.awsdns.com является ли сервер имен основным?

это еще одна проблема.

Сервер имен, указанный в записи SOA и считающийся основным, фактически не имеет отношения к операциям, за исключением случая динамических обновлений. Ожидается, что при наличии динамических обновлений DNS клиенты будут отправлять свои пакеты на этот хост, если они хотят что-то обновить в зоне, описанной этой записью SOA. Но помимо этого, название здесь имеет небольшое значение. Это может быть даже недоступно.

Сравните, например, SOA fr. и NS fr. : вы увидите, что основной сервер имен, указанный в записи SOA, даже не входит в набор авторитетных серверов имен для зоны.

В документе по терминологии DNS говорится следующее:

Первичный мастер: «Первичный мастер указан в поле SOA MNAME зоны и, необязательно, с помощью NS RR». (Цитируется из [RFC1996],
раздел 2.1) [RFC2136] определяет «первичный мастер» как «Главный сервер в корне графика зависимостей AXFR / IXFR. Имя основного мастера указывается в поле SOA MNAME зоны и, необязательно, с помощью NS RR.
По определению существует только один основной главный сервер для каждой зоны.»

Идея основного мастера используется только в [RFC1996] и [RFC2136]. Современная интерпретация термина «первичный мастер» — это сервер, который одновременно является авторитетным для зоны и который получает свои обновления в зону из конфигурации (например, из основного файла) или из транзакций ОБНОВЛЕНИЯ.

Что не полностью отражает реальность, потому что, если вы попытаетесь связаться с сервером имен, указанным в fr. SOA записи, вы не получите никакого ответа, поскольку имя в любом случае не разрешается публично (обычно это называется настройкой «скрытого мастера»).