TL;DR: When the primary hosted zone contains two NS records, containing the name servers for the primary hosted zone (example.com) and the subdomain hosted zone (sub.example.com) would that be sufficient to get sub.domain.com resolved going over the nameserver of example.com?
Domains are currently managed by name.com but DNS should be managed by AWS Route 53 in order to automate creation of new sub-domains and set up records dynamically.
The domain ownership should stay with name.com which means a custom name server needs to be configured for the domain example.com
Subdomains like sub.example.com should be resolved through the name server of example.com as well, otherwise adding a new subdomain would require to configure a custom name server on name.com.
In the current setup, each domain and sub-domain is in its own hosted zone. example.com has a NS record and sub.example.com has one, too.
Now to delegate I have added another NS record in example.com for sub.example.com containing the name servers of sub.example.com
So two NS records in the hosted zone example.com. Yet when I run
dig @ns-of-example.com sub.example.com
I don't get an answer section, though authority section containing the right nameservers. I would have assumed dig does a recursion and then asks the authoritive nameservers listed there.
But I assume I have a flaw in my logic how the DNS protocol works here.
Best Answer
Then you should be good. By default,
digonly asks the server you told it to ask, and shows you the answer from that server.That's an incorrect assumption. If you want a recursive lookup that is a fully valid test of how the domain behaves on the Internet, you need to ask a public recursive resolver to do it for you, e.g.
dig @8.8.8.8 my-sub.example.com.Otherwise, you can get the behavior you want it you use
dig ... +tracebut be aware that there are circumstances where this can give you a false sense of success, because it's not doing a lookup using a recursive resolver -- which is how normal machines will do their lookups.