No, root and TLD DNS servers do not always respond with IP addresses or additional records. Their primary role is delegation; they return NS records pointing to authoritative nameservers for the next zone in the hierarchy. An A record (IP address) is only returned if the queried domain is at the apex of a zone served by that specific server, which is rare for root or generic TLD queries against non-authoritative caches.
Understanding the DNS Hierarchy
To grasp why these responses vary, one must understand how the Domain Name System structures data. The DNS is a distributed database organized in a tree structure. At the very top are the root servers, followed by Top-Level Domain (TLD) servers like those managing .com or .org zones, and finally, authoritative nameservers for specific domains. When you query a name, the response depends entirely on where your query lands in this hierarchy and what data exists at that specific node.
Root servers are responsible for the "." zone. They do not store information about individual websites or subdomains. Instead, they know which servers are authoritative for each TLD. Therefore, when you ask a root server for "example.com", it cannot give you an IP address because it does not know who hosts example.com. It can only tell you which TLD server handles ".com". This delegation mechanism is fundamental to the scalability of the internet.
Similarly, TLD servers manage the zone just below the root. A .com server knows which nameservers are authoritative for "example.com", but it typically does not hold the A records for every single site within its vast namespace. If you query a TLD server directly for "www.example.com", it will likely return an error or refer you back to the root if it doesn't have the delegation data cached. However, if you query for the apex of the TLD itself (which is rarely done), it might return NS records.
This hierarchical delegation means that intermediate servers in the chain almost never provide the final answer (the IP address). They provide pointers to the next step in the resolution process. The actual IP address is found only at the bottom of the tree, on the authoritative nameserver for the specific domain.
The Role of Caching
While the protocol dictates delegation, real-world behavior is influenced heavily by caching. Recursive resolvers (like those provided by ISPs or public services like Cloudflare or Google DNS) cache results to speed up subsequent queries. If a resolver has previously looked up "example.com", it may return the cached A record without querying the root or TLD servers again. This creates a perception that all servers return IPs, but technically, the recursive resolver is providing a cached result, not fresh data from the root or TLD.
When performing manual resolution using tools like
dig or
nslookup, you bypass some of this caching logic by targeting specific servers. This reveals the true nature of the responses: root and TLD servers are giving you delegation instructions, not end-user data.
Why Additional Records Are Rare
Additional records (ANSWER section containing A/AAAA records) are absent from root and TLD responses because those zones do not contain them. The root zone file contains glue records for the TLD nameservers themselves (e.g., the IP addresses of
a.gtld-servers.net). These are necessary for the resolution process to continue. However, the root zone does not contain A records for user domains.
Likewise, TLD zones contain NS records for the authoritative nameservers of registered domains. They generally do not contain A records for those domains. Glue records are only included in the additional section if they are necessary to resolve the NS records provided in the authority section, and even then, this is usually handled by the authoritative server for the child zone, not the TLD server itself.
For more details on how nameserver troubleshooting can help diagnose these resolution paths, see our guide on
Name Server Troubleshooting: A Comprehensive Guide.
Demonstrating the Behavior
You can observe this behavior clearly using command-line tools. When you query a root server directly for a domain, you expect an SOA or referral response, not an A record.
dig @a.root-servers.net example.com +noall +answer
The output will likely show an empty ANSWER section or contain NS records pointing to TLD servers. It will not contain an IP address for "example.com". Similarly, querying a TLD server:
dig @a.gtld-servers.net www.example.com +noall +answer
Again, you will not get an A record. You might get a referral to the authoritative nameservers if the TLD server is configured to provide that level of detail, but typically, you need to go to the authoritative nameserver listed in the NS records to get the IP.
It is important to distinguish between the response from the authoritative server and the response from the recursive resolver. The authoritative server for example.com will return the A record. The recursive resolver will return that A record to your client, often including additional records if they were requested or cached. But the root and TLD servers in the middle are strictly delegating.
If you are experiencing issues where DNS records point to unexpected locations, understanding this hierarchy is crucial. For instance, checking if your NS records are correctly delegated is a common step. You can read more about external domain references in
Is it possible to have a DNS NS record point to a domain from outside the queried nameserver's domain?.
Common Misconceptions
Many users assume that because their browser resolves a domain quickly, the DNS lookup is simple. In reality, multiple hops occur. The misconception that root servers return IPs stems from seeing the final result in a traceroute or ping, which aggregates the entire resolution path. Another misconception is that TLD servers are "authoritative" for all domains under their extension. They are only authoritative for the delegation records (NS records) of those domains, not the content records (A, MX, TXT).
Understanding this distinction helps in debugging complex DNS issues. If a domain is not resolving, checking the root and TLD responses can confirm if the delegation is correct. If the TLD server returns no NS records for a domain, the domain registration or delegation is likely misconfigured.
Frequently Asked Questions
Can I force a root server to return an IP address?
No, root servers are programmed to only return delegation records for TLDs. They do not store IP addresses for individual domains, so there is no flag or setting to change this behavior. You must follow the delegation chain down to the authoritative nameserver to get an IP.
Why do some dig outputs show additional records from TLD servers?
Sometimes, TLD servers include glue records for their own nameservers in the additional section to help resolvers connect to them. However, they will not include A records for third-party domains like example.com unless they are acting as a cache, which is not standard for direct TLD queries.
What is the difference between a referral and an answer in DNS?
An answer section contains the final requested data, such as an IP address. A referral indicates that the server does not have the answer and points the resolver to another server that might. Root and TLD servers primarily issue referrals to guide the resolver down the hierarchy.
How do I find the authoritative nameserver for a domain?
You can use the
dig command with the
+trace option or query the TLD server for the NS records of the domain. For example,
dig NS example.com @a.gtld-servers.net will show you which nameservers are responsible for that domain.
Do CDN providers like Cloudflare change this behavior?
Cloudflare operates both recursive resolvers and authoritative nameservers. While their recursive resolvers cache and return IPs efficiently, their authoritative servers still follow standard DNS protocols. Querying their authoritative servers directly for a domain will yield the expected A records, but querying their root-level infrastructure will still result in referrals.