NS
and A
records are completely different and achieve different goals.
An A
record associates a name to an IP address.
An NS
record basically say: this zone is handled by this nameserver (name).
Your question would be fare simpler, including for you, if you were using real names.
If ns1.example.com
and ns2.example.com
are hostnames, that is something that need to be reachable because they host some services, then they need A
records (or AAAA
records if you stop using the legacy IPv4 Internet).
Since ns1.example.com
(and ns2
) is inside the example.com
zone, the zonefile hosted by the authoritative nameservers of zone example.come
need to have the A
record.
Now if you say that subzone.example.com
has to be delegated (remember that this not an automatic fact just because there is a dot, delegation happens only when needed and desired by the people in charge of a zone, as a matter of giving control of part of the tree to another entity), and if ns1
and ns2.example.com
are to be authoritative nameservers for this subzone then you will need to have NS
records in the example.com
AND in the subzone.example.com
zonefiles.
What about glues?
It is conceptually simple but since it may create problems it is often best to avoid this route until you manage to fully grasp how the DNS is working.
If a given domain name uses as authoritative nameservers some nameservers whose hostnames is inside the same zone, then the parent zone also needs to publish directly A
(or AAAA
) records for those hostnames, otherwise the resolution can not occur properly at all.
Said differently, you want to resolve www.example.com
, and example.com
has ns1.example.com
and ns2.example.com
as authoritative nameservers, then the following (simplified process occurs):
- You (from now on, you is in fact the recursive nameserver you are using) ask one root server (whose IP addresses are hardcoded and refreshed periodically) about
www.example.com
- the root zone will tell you that it knows nothing about this name, but it knows about authoritative nameservers for
.com
since .com
is delegated from .
(the root)
- now you redo your query but this time towards one of the authoritative nameservers for
com
: they will tell you they know nothing about www.example.com
but they know about example.com
, since it is delegated; hence it will send you back the set of nameservers authoritative on example.com
- at this point, if you got only
ns1.example.com
and ns2.example.com
to be able to contact them to ask them about www.example.com
you obviously first need to resolve their names, for which you will need of course to start back from the first point in this list... hence you see the deadlock
- in reality for this specific reason, at step 3., the authoritative nameservers for
.com
will given you both the set of authoritative nameservers for example.com
AND their IP addresses, which is what is called glue records: A
/AAAA
records in the parent zone that are needed to make the resolution happen.
You can see exactly the above process if you use dig +trace
.
PS: something that normally simplifies understanding the system is to remember that no node is special in the tree (except the root one if you want), and anything can happen in the same way at any "level" or depth of the tree.