What DNS server is the first in being queried when trying to found an IP? [closed]

The question on what is the first server that gets queried depends on:

• Circumstances: what’s already cached and where?
• The part of the DNS we are focusing on:
  • How a recursive name server starts hierachically from the root?
  • How a clients sends a query to its nearest recursive name server?
• Abstraction level: are we interested just in the delegation hierachy or actual records.

This answer aims at explaining the flow with different levels of abstration, discuss what’s left out to simplify it a bit… and correct the misunderstanding left by the presentation you had seen. Let’s start with this (Jean Piaget’s) accommodation…

To correct the misleading

Prof.I.Sengupta explains the recursive name resolution inaccurately and misleadingly. Starting from 35:01 there’s a slide showing this figure. The warning around it is mine. 😉

The hierarchy in the authoritative DNS is one way: recursion starts always downwards from the root, and never up towards the root like in this picture. Furthermore, this suggests that all the DNS queries and their responses between TLD’s would be going through the root name servers. Clearly that can’t be the case, and the root name servers are loaded enough even with their current responsibilities i.e. simply with serving the delegation of control down to the TLD name servers.

Although some name servers could have both recursive and authoritative roles, that’s not recommended, and open recursive name service is even prohibited in the IANA Ttechnical requirements for authoritative name servers. There are several reasons for this isolation:

• Preventing amplification attacks (RFC 5358, 4).

• Preventing DNS cache poisoning, although this is mostly a historical reason best explained in the 3rd edition of Nemeth, E., Snyder, G., Seebass, S., & Hein, T. (2000). UNIX system administration handbook. Pearson Education. (Chapter 16 THE DOMAIN NAME SYSTEM; The BIND software; Authoritative and caching-only servers.):

  In BIND4 and BIND 8, it wasn’t a good idea to use a single name serevr
  as an authoritative server for some zones and as a caching server for
  others. Each named ran with a single in-memory database, and
  cross-contamination could occur if memory was tight and cached data
  mixed with authoritative data. BIND 9 has eliminated this problem, so
  mix away.

• For stability / load balancing: authorative name servers are crucial part of the Internet, as almost everything else relies on DNS. Therefore, we shouldn’t allow technical errors or high loads an a recursive server to affect the performance of this system.

Different levels of abstraction

Many pictures on the subject are simplified to not take caching into consideration.

• Marshall Brain: How Domain Name Servers Work (already mentioned in Tim’s answer)

• Lorraine Bellon: What is the difference between authoritative and recursive DNS nameservers?

• SophieDogg: An Intro to DNS. The following version of this illustration & the citation are from there:

  Below is an example of a recursive DNS query. It is important to know
  that a recursive server always has a copy of the IP addresses of the
  root nameservers, in order to provide the necessary addresses for step
  #2 in the figure below. This list of root nameservers need to be kept up to date, or else the recursive nameserver will not know where to
  start its lookups!

  

If we add caching on different levels (browser, OS, recursive server), the picture gets a little more complicated. This illustration from The TCP/IP Guide: DNS Name Resolution Process shows what happens if nothing was cached.

Figure 245: Example Of The DNS Name Resolution Process

This fairly complex example illustrates a typical DNS name resolution
using both iterative and recursive resolution. The user types in a DNS
name (“www.net.compsci.googleplex.edu”) into a Web browser, which
causes a DNS resolution request to be made from her client machine’s
resolver to a local DNS name server. That name server agrees to
resolve the name recursively on behalf of the resolver, but uses
iterative requests to accomplish it. These requests are sent to a DNS
root name server, followed in turn by the name servers for “.edu”,
“googleplex.edu” and ‘compsci.googleplex.edu”. The IP address is then
passed to the local name server and then back to the user’s resolver
and finally, her Web browser software.

Here we already have almost everything, if we only add that:

• Caching:

  • The client could already know the IP address, and 3-15 can be omitted.
  • Everything could be already cached on the recursive server, and 5-13 can be omitted.
  • Assuming www.net.compsci.googleplex.edu was recently queried, the recursive name server already knows compsci.googleplex.edu name servers; when querying e.g. for sw.compsci.googleplex.edu, 5-10 can be omitted.
  • Even more often the recursive name server already know TLD name servers; omit 5-6.

• Name servers are returned as NS records, but for every level you need the actual IP addresses. If they are not returned with the NS records, the corresponding A records needs to be queried too. This might happen e.g. if the name servers located on a different TLD. In this case, a recursive name server may need to start from the root twice. Closely related to this, glue records are whole another subject.

• Not all local DNS servers used perform the recursion by themselves, but they may ask from other recursive name server called forwarders. Likewise, the forwarders have caching capabilities, and their relation is similar to the situation between the OS level cache and the local name server on this picture.

If we try and add all this into a same illustration, it would be as complex as any explanation.