The DNS resolver gave up trying to find a name server for a domain because the authoritative name server for that domain’s parent zone couldn’t provide the necessary IP addresses (glue records) for the domain’s own name servers.
Cause 1: Missing or Incorrect Glue Records at the Parent Zone
Diagnosis: Use dig to query the parent zone (e.g., .com, .org) for the NS records of the domain and then query for the A/AAAA records of those NS.
dig NS example.com @a.gtld-servers.net
dig A ns1.example.com @a.gtld-servers.net
dig AAAA ns1.example.com @a.gtld-servers.net
If the dig A or dig AAAA commands above return SERVFAIL or no records, the glue records are missing or incorrect at the parent zone.
Fix: Log into your domain registrar’s control panel. Navigate to the DNS management section for example.com. Ensure that the nameservers listed for example.com (e.g., ns1.example.com, ns2.example.com) have corresponding A and AAAA records pointing to their correct IP addresses. These are the "glue records" that the parent zone (.com in this case) needs to provide.
Why it works: The parent zone (like .com) acts as a directory. When a resolver asks for example.com, the .com servers need to know which name servers handle example.com and where those name servers are located (their IP addresses). If the .com servers don’t have the IP addresses of ns1.example.com and ns2.example.com, the resolver gets stuck.
Cause 2: Authoritative Name Servers Not Registered with the Parent Zone
Diagnosis: Similar to Cause 1, query the parent zone for the NS records of the domain, then attempt to resolve the IP addresses of those NS. If the NS records exist in the parent zone but the IP addresses for those NS are still missing, this is the likely culprit.
dig NS example.com @a.gtld-servers.net
dig A ns1.example.com @a.gtld-servers.net
If dig NS example.com returns ns1.example.com and ns2.example.com, but dig A ns1.example.com fails to return an IP address, the authoritative servers are not properly registered.
Fix: You need to explicitly register the nameservers and their IP addresses with your domain registrar, who then propagates this information to the top-level domain (TLD) registry. In your registrar’s control panel, find the section for "Nameserver Management" or "Child NS" and enter the hostnames of your authoritative name servers (e.g., ns1.example.com) along with their respective IP addresses.
Why it works: The parent zone (e.g., .com) needs to know both the names of the servers responsible for example.com and their locations (IPs) to delegate authority correctly. If the names are registered but their locations aren’t, the delegation fails.
Cause 3: Incorrectly Configured Authoritative Name Servers
Diagnosis: Directly query your own authoritative name servers for the domain’s NS and A/AAAA records.
dig NS example.com @ns1.example.com
dig A ns1.example.com @ns1.example.com
dig AAAA ns1.example.com @ns1.example.com
If your authoritative name servers do not correctly list themselves as the NS for the domain, or if they don’t have A/AAAA records for themselves, this is a configuration issue on your end.
Fix: Ensure your authoritative DNS server configuration (e.g., BIND’s named.conf and zone files) correctly defines the NS records for example.com and also defines the A/AAAA records for ns1.example.com and ns2.example.com.
Example BIND named.conf snippet:
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com";
};
zone "ns1.example.com" {
type master;
file "/etc/bind/zones/db.ns1.example.com";
};
Example db.example.com zone file:
$TTL 3600
@ IN SOA ns1.example.com. admin.example.com. (
2023102701 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
86400 ; minimum TTL
)
IN NS ns1.example.com.
IN NS ns2.example.com.
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2
Example db.ns1.example.com zone file:
$TTL 3600
@ IN SOA ns1.example.com. admin.example.com. (
2023102701 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
86400 ; minimum TTL
)
IN NS ns1.example.com.
ns1 IN A 192.0.2.1
Why it works: Your own authoritative name servers must be able to resolve their own hostnames to IP addresses. If they can’t, they can’t correctly answer queries about themselves, which is what the parent zone needs to delegate.
Cause 4: DNS Propagation Delay
Diagnosis: If you recently made changes to your DNS records or nameserver registrations, the changes may not have propagated across all DNS servers yet. Use dig with different public DNS resolvers (Google’s 8.8.8.8, Cloudflare’s 1.1.1.1) to see if the problem is localized.
dig NS example.com @8.8.8.8
dig A ns1.example.com @1.1.1.1
Compare the results with dig run without specifying a server (which uses your local resolver’s cache) or against the authoritative servers directly.
Fix: Wait for DNS propagation. This can take anywhere from a few minutes to 48 hours, depending on TTL values and caching. You can try reducing TTL values for glue records temporarily if you are actively making changes, but be aware this increases load on authoritative servers.
Why it works: DNS is a distributed system. Changes made at one point take time to replicate throughout the system. If the resolver is hitting a cache that hasn’t updated yet, it will appear as if the records don’t exist.
Cause 5: Network Connectivity Issues to Glue Record Servers
Diagnosis: Use ping or traceroute to test connectivity to the IP addresses of the name servers listed in the parent zone’s glue records.
ping 192.0.2.1
traceroute 192.0.2.1
If these tests fail, there’s a network problem preventing the resolver from reaching your authoritative name servers.
Fix: Investigate network configurations, firewall rules, or any upstream network providers that might be blocking traffic to your authoritative name servers on UDP/TCP port 53. Ensure your authoritative name servers have stable IP addresses and are reachable from the internet.
Why it works: Even if the glue records are perfectly configured in the parent zone, if the resolver cannot actually establish a connection to the IP address provided for the authoritative name server, it cannot complete the lookup.
Cause 6: Incorrectly Configured Parent Zone Delegation (Rare, often at TLD level)
Diagnosis: This is very rare and usually points to an issue with the TLD registry itself or a misconfiguration at the registrar level that affects the TLD zone. The dig commands from Cause 1 would likely show inconsistent or incorrect NS records for the domain within the parent zone.
Fix: Contact your domain registrar and/or the TLD registry support for the specific top-level domain (e.g., .com, .org). You’ll need to provide evidence of your correct DNS setup and request they verify/correct the delegation information in the parent zone.
Why it works: The parent zone is the ultimate source of truth for delegation. If it’s fundamentally misconfigured for your domain, only the operators of that zone can fix it.
The next error you’ll likely encounter if you fixed "No Suitable Glue for Delegation" but still have issues is a SERVFAIL from your authoritative name servers themselves, indicating a problem with how they are serving their own zones.