Last Updated on
The Internet’s DNS structure is often (accurately) described as hierarchical with authoritative servers sitting at the top of the structure. However because of this setup it is essential that all DNS servers are able to communicate with each other in order to supply response to the name queries which are submitted by clients.
This is because although we would expect our companies internal DNS server to know all the addresses of internal clients and servers, we wouldn’t expect it’s database to contain every external server on the the internet. Although in the early days of the internet, most DNS servers did contain an entire list of connected server addresses, nowadays that would simply not be feasible or in fact very sensible.
When a DNS server needs to find an address which is not in it’s database, it will query another DNS server on behalf of the requesting client in order to find the answer. The server in this instance is actually acting in the same way as a client by making a request to another DNS server for the information, this process is known as recursion.
It’s actually quite difficult to detect whether a query is answered by recursion or by directly when troubleshooting DNS queries. You need to be able to listen to all a DNS servers traffic in order to identify a recursive query. The additional query (recursive one) is generated after the DNS serverc has checked it’s local database in order to resolve the query. If this isn’t successful the DNS server will generate the additional request before replying to the client. This is also dependent on the recursion bit being set in the initial query from the client too, as this allows the server to ask another server if the answer is not in it’s own database.
The recursive query is merely a copy of the initial DNS request and it has the effect of turning the server into a client. You can notice if you analyse the traffic that the transaction ID numbers will change in order to differentiate the initial query from the recursive query sent by the DNS server. It’s important to keep a note of these transaction IDs when troubleshooting DNS traffic as it’s easy to get confused as many of the packets will look very similar. If you are trying to analyze something more complicated like the modern, intelligent Smart DNS servers like these – http://www.proxyusa.com/smart-dns-netflix-its-back then it’s even more important to keep track of these transactions. This is because these DNS servers actually make decisions on how to route the traffic in addition to resolving queries.