How DNS Resolves a Name

DNS turns a name such as api.example.com into an IP address by asking a hierarchy of servers, each responsible for one part of the name. The name is read from right to left: root servers know who runs each top-level domain such as .com, the .com servers know who runs example.com, and example.com's own servers know the address of api.example.com. No single server knows every answer.

Think of a visitor at a large office who asks the receptionist for one person. The receptionist sends them to the right department, and the department points to the right desk. The comparison breaks in one place: in DNS a resolver walks every step on the client's behalf and remembers each answer, so the next visitor asking for the same name is answered at the door.

Three roles do the work.

The stub resolver is the small DNS client in the operating system. It does not walk the hierarchy itself; it sends the whole question to one recursive resolver and waits for the final answer.

The recursive resolver does the walking. Run by the internet provider, by a company for its network, or by a public service such as 1.1.1.1 or 8.8.8.8, it asks each level in turn and keeps every answer in its cache.

Authoritative servers hold the real records for a domain. The owner of example.com, or the DNS provider they pay, runs them, and their answer is final.

The levels above only refer. A root server asked about api.example.com does not know its address; it answers with the names of the .com servers, a referral, and the resolver asks again there. Each referral is cached too, so a resolver that has looked up one .com name rarely needs the root again for another.

The root servers' addresses are built into every resolver, which is how the walk can start. There are 13 root server names, each answered by many machines around the world through anycast.

So when a name fails to resolve, the question is which level gave the wrong answer, or no answer: the resolver, a referral, or the domain's own servers.