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.
