Route53: Где хранятся записи SOA, записи NS?

Why does an Authoritative Name Server need to keep pointers about the example.com domain being served by itself?

Ваш вопрос не относится ни к Amazon, ни к конкретному ДВУ, ни к положению ДВУ в дереве DNS, приведенное ниже относится ко всему в DNS.

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

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

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

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

Though logically part of the authoritative data, the RRs that describe the top node of the zone are especially important to the zone's management. These RRs are of two types: name server RRs that list, one per RR, all of the servers for the zone, and a single SOA RR that describes zone management parameters.

а по поводу раскола и какая сторона авторитетнее:

The RRs that describe cuts around the bottom of the zone are NS RRs that name the servers for the subzones. Since the cuts are between nodes, these RRs are NOT part of the authoritative data of the zone, and should be exactly the same as the corresponding RRs in the top node of the subzone. Since name servers are always associated with zone boundaries, NS RRs are only found at nodes which are the top node of some zone. In the data that makes up a zone, NS RRs are found at the top node of the zone (and are authoritative) and at cuts around the bottom of the zone (where they are not authoritative), but never in between.

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

Authoritative data: "All of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom edge of the zone." (Quoted from [RFC1034], Section 4.2.1) Note that this definition might inadvertently also cause any NS records that appear in the zone to be included, even those that might not truly be authoritative because there are identical NS RRs below the zone cut. This reveals the ambiguity in the notion of authoritative data, because the parent-side NS records authoritatively indicate the delegation, even though they are not themselves authoritative data.

Что касается

what is the point of this SOA record telling the ANS ns1.awsdns.com that ns1.awsdns.com is the primary name server?

это другая проблема.

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

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

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

Primary master: "The primary master is named in the zone's SOA MNAME field and optionally by an NS RR." (Quoted from [RFC1996],
Section 2.1) [RFC2136] defines "primary master" as "Master server at the root of the AXFR/IXFR dependency graph. The primary master is named in the zone's SOA MNAME field and optionally by an NS RR.
There is by definition only one primary master server per zone."

The idea of a primary master is only used in [RFC1996] and [RFC2136]. A modern interpretation of the term "primary master" is a server that is both authoritative for a zone and that gets its updates to the zone from configuration (such as a master file) or from UPDATE transactions.

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