Custom NS records for subdomains often fail to resolve due to missing glue records, incorrect delegation at the parent zone, or DNS propagation delays. By verifying the authoritative nameservers are reachable and ensuring the parent domain correctly delegates authority, you can restore connectivity for hosts like foo.example.com and bar.example.com.
Understanding NS Record Delegation
When you delegate a subdomain to custom nameservers, you are essentially telling the global DNS system that queries for that specific part of your domain hierarchy should be directed elsewhere. This process involves two distinct layers: the parent zone (the main domain) and the child zone (the subdomain). If either layer is misconfigured, resolution will fail with errors such as NXDOMAIN or SERVFAIL. The most common point of failure occurs when the parent domain does not explicitly list the custom nameservers in its own SOA or NS records. Without this explicit delegation, recursive resolvers have no instruction on where to send the query, causing them to default to the primary nameservers registered for the root domain.
To fix this, you must ensure that the parent domain's DNS provider has entries for the subdomain's nameservers. For example, if you want
foo.example.com to use
ns1.custom-host.com, the
example.com zone file must contain an NS record pointing to
ns1.custom-host.com. This is a critical step that many administrators overlook when migrating subdomains to third-party hosting providers. You should check the current delegation by querying the parent domain directly using tools like
dig or online lookup services. Look for the NS section in the response to confirm that your custom nameservers are listed alongside any existing ones.
Verifying Parent Zone Configuration
The first diagnostic step is to verify that the parent zone is aware of the new delegation. Use the following command to check the NS records for your subdomain:
dig NS foo.example.com +short
If the output is empty or returns the default nameservers of
example.com instead of your custom ones, the delegation has not been applied. In this scenario, you need to log into the DNS management console of your primary domain registrar or host. Add an NS record for the subdomain pointing to the specific nameservers provided by your secondary host. It is important to note that some registrars require you to create "hostnames" or "glue records" before they will accept the NS delegation. Ensure that these prerequisites are met to avoid silent failures during propagation.
Glue Records and Child Nameservers
One of the most frequent causes of resolution failure is the lack of proper glue records. Glue records are A or AAAA records that provide the IP addresses of the nameservers when those nameservers are within the same domain being delegated. For instance, if you are delegating
bar.example.com to
ns1.bar.example.com, the resolver needs to know the IP address of
ns1.bar.example.com to contact it. However, because
ns1.bar.example.com is inside the
bar.example.com zone, a circular dependency occurs. To break this loop, the parent zone (
example.com) must include A records for
ns1.bar.example.com. These are known as glue records.
Without glue records, the resolver cannot reach the nameserver to get the answer, leading to a timeout or referral loop. Most modern DNS providers handle this automatically if you create the nameserver hostname through their interface. However, if you are managing raw zone files, you must manually add the A records for each custom nameserver in the parent zone. This ensures that the information travels down the chain correctly. If you are using external nameservers that are outside your domain (e.g.,
ns1.cloudflare.com), glue records are generally not required, but you must still ensure the NS delegation is present.
For more details on managing complex DNS zones, see our guide on DNS Zone Management Basics.
DNS Propagation and TTL Considerations
Even after correct configuration, changes may not appear immediately due to Time-To-Live (TTL) values. When you update NS records, the old values persist in the caches of recursive resolvers until the TTL expires. This can make it seem like the change failed when it is actually just delayed. High TTLs set on the previous nameservers can prolong this wait time significantly. To minimize downtime during migration, consider lowering the TTL 24-48 hours before making the change. This allows caches to refresh faster once the new delegation is active.
You can monitor the propagation status using public DNS checking tools. These tools query from various geographic locations to show if the new NS records are visible globally. If some regions show the old records while others show the new ones, you are simply waiting for propagation to complete. Patience is key here; aggressive flushing of local caches or restarting routers rarely affects global DNS resolution. Instead, focus on validating that the authoritative servers are responding correctly.
Authoritative Server Health Checks
Once delegation is confirmed, the next step is to ensure the authoritative nameservers themselves are healthy and responsive. A common issue is that the nameservers are unreachable due to firewall rules, port blocking, or service outages. DNS relies on UDP port 53 for standard queries. Ensure that your server's firewall allows inbound traffic on this port. Additionally, check that the DNS service is running and bound to the correct interfaces.
Use the
dig command with the
+trace flag to see the full path of the resolution. This trace shows every hop from the root servers down to your authoritative servers. If the trace stops or times out at your nameserver, the issue lies with your server configuration or network accessibility. Verify that your server is returning valid responses for the queried domain. If the server is up but returning errors, check the logs for configuration syntax errors or missing zone data.
See also Resolving DNS Timeouts for deeper troubleshooting on network-level issues.
Frequently Asked Questions
Why do I get NXDOMAIN for my subdomain?
An NXDOMAIN error usually means the subdomain does not exist in the DNS hierarchy. This happens if you forgot to add the NS record in the parent zone or if the subdomain name is misspelled. Check your parent zone file to ensure the delegation is explicitly defined for the exact subdomain name you are querying.
How long does NS record propagation take?
Propagation depends on the TTL set on the previous records, typically ranging from a few minutes to 48 hours. Lowering the TTL before making changes speeds up this process. You can force a refresh on your local machine by clearing the DNS cache, but global propagation is controlled by intermediate resolvers.
What are glue records and why are they needed?
Glue records are IP addresses provided by the parent zone for nameservers that reside within the delegated domain. They prevent circular dependencies where a resolver needs to ask the nameserver for its own IP address. Without glue records, the resolver cannot reach the nameserver to retrieve the zone data.
Can I use the same nameservers for multiple subdomains?
Yes, you can delegate multiple subdomains to the same set of nameservers. Each subdomain requires its own NS record in the parent zone pointing to those nameservers. This is a common setup for hosting multiple sites under one DNS provider account.
How do I check if my nameservers are reachable?
Use the
dig command with the
+trace option to visualize the resolution path. If the trace fails at your nameserver, check your firewall settings to ensure UDP port 53 is open. You can also use online tools to test connectivity from different geographic locations.