Why Your Subdomain Isn't Resolving: The Rare Case of Missing NS Records at the Zone Apex
Published: 21 Oct, 2025

blog_61519868f7ae2444f04_thumb.png

You’ve configured a subdomain like api.example.com, pointed the A record correctly, and even verified propagation. Yet, DNS queries intermittently fail—or worse, work for some users and not others.
In obscure cases, the issue isn’t the subdomain itself, but a missing NS delegation at the zone apex when using certain advanced configurations.

When This Happens

This issue is rare and typically occurs in scenarios like:

  • Using delegated subdomains with their own nameservers (e.g. dev.example.com served from external NS)

  • DNS zones hosted with cloud providers where NS records are required explicitly for sub-zone resolution

  • Split-horizon DNS setups with internal vs public resolvers

Even if your A record is valid, without the NS delegation present in the parent zone, some resolvers will fail to follow the path—especially strict recursive resolvers like Unbound or PowerDNS.

Example Scenario


 

; zone file for example.com api.example.com. IN A 203.0.113.10 ; <-- looks fine

But the recursive resolver is expecting:


 

api.example.com. IN NS ns1.api-dns.net. IN NS ns2.api-dns.net.

Without that delegation, your response may fail DNSSEC validation, or return SERVFAIL from certain resolvers—while appearing to work fine on Google DNS or 1.1.1.1.

How to Fix It

  • If you're not delegating, ensure the subdomain is handled directly in your existing zone.

  • If you are delegating, add the appropriate NS records in the parent zone (example.com).

  • Use dig +trace or our DNS Lookup Tool to confirm resolution paths and verify that the subdomain is properly linked at every level.

Pro Tip

In BIND or PowerDNS setups, forgetting to reload the parent zone after a delegation change can result in silent resolution failures, especially if zone signing is active.