Route 53 is supposed to be an Authoritative Name Server as per the AWS docs. If example.com is the domain that I have bought, and I have www.example.com pointing to an IP 192.0.2.4, then, the Top Level Domain Name Server(the NS for ".com") stores a mapping between the Authoritative Name Server (ANS) for the domain example.com and the domain example.com as shown below:
example.com. 172800 IN NS ns1.awsdns.com
So, this is the NS record and this NS record is sitting in the TLD Name Server for ".com". Is my understanding right? If yes, then, why do I also get to see the same record in the Route 53 Console? Route 53 is supposed to be an Authoritative Name Server. Why does an Authoritative Name Server need to keep pointers about the example.com domain being served by itself? Isn't the fact that the ANS for the domain example.com is ns1.awsdns.com, needs to be known to the .com TLD NS and not Route53 itself?
Also, where would the SOA record reside? Would it reside in the ANS itself? Below is an SOA record:
ns1.awsdns.com admin.awsdns.com 2013022001 86400 7200 604800 300
This has the:
The primary name server for the domain: ns1.awsdns.com
The responsible party for the domain: admin.awsdns.com
timestamp that changes whenever you update your domain: 2013022001
The number of seconds before the zone should be refreshed: 86400
The number of seconds before a failed refresh should be retried: 7200
The upper limit in seconds before a zone is considered no longer authoritative: 604800
The negative result TTL: 300
If this SOA record is sitting in the ANS itself, that is in the ns1.awsdns.com machine itself, then what is the point of this SOA record telling the ANS ns1.awsdns.com that ns1.awsdns.com is the primary name server?
Can someone clear the confusion here? I am utterly confused.
Why does an Authoritative Name Server need to keep pointers about the example.com domain being served by itself?
Your question is not specific to Amazon nor to a specific TLD, nor to the TLD position in the DNS tree, the below applies everywhere in the DNS.
A given nameserver (in fact set of nameservers) is authoritative on a zone. Hence it has the full zone content, which includes SOA and NS records of the zone. It is authoritative over it.
But, for the zone to resolve, its parent needs to know the set of nameservers, and hence this set is published at the parent.
So you have one information in two spots, but the child is authoritative on that. It may happen that both got desynchronized, this is called a lame delegation. But it is expected from resolvers to believe the child version of the content, not the parent one.
In RFC1034 you have this:
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.
and about the split and which side is authoritative:
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.
The DNS Terminology document (RFC 8499) tries also to reduce the confusion:
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.
As for
what is the point of this SOA record telling the ANS ns1.awsdns.com that ns1.awsdns.com is the primary name server?
this is another problem.
The nameserver listed in the SOA record and considered the primary has little relevance to operations in fact, except in the case of dynamic updates. When there are DNS dynamic updates the clients are expected to send their packets to this host if they want to update something in the zone described by this SOA record. But outside of that, the name here is a little relevance. It may even not be reachable.
Compare for example SOA fr. and NS fr.: you will see that the primary nameserver listed in the SOA record does not even appart among the set of authoritative nameservers for the zone.
The DNS terminology document says this:
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.
Which does not reflect completely the reality, because if you try to contact the nameserver listed in the fr. SOA record, you won't get any reply, as the name does not resolve publicly anyway (this is typically called an "hidden master" setup).