The "No Reachable Authority" error in DNS occurs when parent servers cannot contact the name servers listed in your delegation records. This happens because the NS records for a subdomain, such as home.example.com, point to servers that are either unreachable or not responding to queries from the internet. To resolve this, you must ensure that the authoritative name servers for the child zone are publicly accessible and correctly configured to serve the zone data.
Understanding DNS Delegation Mechanics
When you delegate a subdomain to another set of DNS servers, you are essentially telling the global DNS system where to find the authoritative answers for that specific part of your domain tree. This process relies on two critical components: Name Server (NS) records and glue records. The parent zone (the main domain) holds the NS records that point to the child zone's servers. For example, if you own example.com and want to delegate home.example.com to external providers like Cloudflare or AWS Route53, your registrar or parent DNS provider must list those external servers as the authorities for home.example.com. The issue arises when these pointers exist but the actual servers behind them fail to respond. DNS resolution is recursive; a resolver asks the root servers, which point to the TLD servers, which then ask your parent zone’s servers. If the parent says "ask server A for home.example.com," the resolver attempts to connect to server A. If server A does not reply within a reasonable timeout, the resolver returns an error indicating it cannot reach the authority. This is distinct from NXDOMAIN errors, which mean the record does not exist, or SERVFAIL, which often indicates a configuration mismatch within the server itself rather than connectivity issues.The Role of Glue Records
Glue records are essential when your name servers are subdomains of the zone they are authorizing. For instance, if you try to use ns1.home.example.com as the name server for home.example.com, a circular dependency occurs. The resolver needs to know where ns1.home.example.com is located, but finding that location requires resolving home.example.com first. To break this cycle, the parent zone must include A or AAAA records (glue) alongside the NS records. If you are using external DNS providers, they typically provide their own non-subdomain nameservers (like ns1.cloudflare.com), avoiding the need for glue records entirely. However, if you manage your own infrastructure, ensuring these glue records are present and correct is vital for delegation stability.Troubleshooting Connectivity Issues
The most common cause of this error is network-level blocking or misconfiguration on the authoritative servers themselves. You must verify that the servers listed in your delegation are actually reachable from the public internet. This involves checking firewall rules, security groups, and any intermediary load balancers. DNS operates primarily over UDP port 53, though TCP port 53 is required for larger responses and zone transfers. If your firewall only allows inbound traffic from specific IP ranges or blocks all external connections, resolvers will time out when trying to query your servers. You can test this by using command-line tools likedig or nslookup from various locations outside your local network. Querying the specific name server directly for a record within the delegated zone should return a valid response with the AA (Authoritative Answer) flag set. If the query times out or returns a connection refused error, the problem is likely at the network or server configuration level. Additionally, ensure that your DNS service is not rate-limiting or blocking standard resolver IPs, as some aggressive security measures might inadvertently block legitimate traffic.
Verifying Record Consistency
Another frequent culprit is inconsistency between what the parent zone reports and what the child zone serves. Use thedig command with the +trace option to see the full path of resolution. This output shows exactly which servers are being queried at each step. Look for discrepancies where the parent lists one set of servers, but the child zone is hosted elsewhere. If you recently migrated your DNS hosting, you must update the NS records at your domain registrar or previous DNS provider to match the new hosting environment.
Furthermore, check for TTL (Time to Live) mismatches. If you changed servers recently, old NS records might still be cached by upstream resolvers. While this usually causes intermittent failures rather than a hard "No Reachable Authority" error, it can complicate troubleshooting. Clearing caches on your local machine and waiting for global propagation ensures you are testing against the current state of the DNS hierarchy. For more details on how modern DNS protocols interact with traditional queries, you might find Is DNS-over-HTTPS (DOH) Dependent on Regular DNS Queries? helpful, as DOH clients may behave differently when reaching authoritative sources.
Resolving the Error
To fix the issue, start by validating your name server health. Ensure the servers are online, accepting connections on port 53, and configured to answer authoritatively for the delegated zone. If you are using a third-party provider, confirm that the zone has been created and activated in their dashboard. Next, update the NS records at your parent zone to point to these healthy servers. If you are self-hosting, review your firewall settings to allow inbound UDP and TCP traffic on port 53 from all sources, or at least from major resolver IP ranges. After making changes, monitor the propagation status. It may take several hours for the new delegation to propagate fully across the global DNS network. During this period, you may see mixed results depending on which resolver a user’s device contacts. Patience and consistent verification are key. If the problem persists despite correct configurations, consider checking if your ISP or regional network is blocking DNS traffic, although this is rare for standard port 53 usage. For broader context on how dynamic systems handle these architectural challenges, see Understanding Dynamic Name System Architecture.Frequently Asked Questions
What is the difference between No Reachable Authority and NXDOMAIN?
NXDOMAIN means the specific domain name requested does not exist in the DNS database. In contrast, No Reachable Authority means the domain exists and has delegation records, but the servers listed in those records cannot be contacted. One is a content error, while the other is a connectivity or configuration error.
How long does it take for DNS delegation changes to propagate?
Propagation time depends on the TTL values set on your previous records and the caching behavior of intermediate resolvers. Typically, updates can take anywhere from a few minutes to 48 hours to fully propagate globally, though most changes occur within an hour if low TTLs were used prior to the change.
Can I use my own custom nameservers without glue records?
If your custom nameservers are subdomains of the zone you are delegating (e.g., ns1.example.com for example.com), you absolutely need glue records provided by the parent zone. Without them, resolvers enter a loop trying to resolve the nameserver’s address before they can query the zone itself.
Why do some resolvers succeed while others fail?
This often happens due to partial propagation or varying firewall policies across different networks. Some ISPs or corporate networks may block outbound DNS queries or have stricter filtering rules, causing them to fail while residential users succeed. Testing from multiple public DNS endpoints helps isolate this variance.
What tools can I use to diagnose DNS delegation issues?
Command-line tools like dig, nslookup, and host are standard for diagnosing these issues. Using dig +trace provides a detailed view of the resolution path, showing exactly where the query fails. Online DNS checkers can also provide a global perspective on how your delegation is viewed from different geographic locations.