What are the 4 Types of DNS?

There are four core types of DNS servers: Recursive Resolver, Root Nameserver, TLD Nameserver, and Authoritative Nameserver. Each plays a unique role in converting a domain name like www.example.com into the IP address your browser needs. 

‍

The Recursive DNS Server (or DNS recursor) does most of the legwork, while the others point it in the right direction or give it the final answer. 

‍

Here’s how these 4 server types make it all happen:

‍

1. DNS Recursive Resolver

‍

This is the server your device talks to first. You don’t connect to websites using IPs like 93.184.216.34, right? You type www.example.com and expect it to “just work.” The recursive DNS server is what makes that happen.

‍

Whenever your phone, laptop, or app wants to look up a domain name, it sends the request to a recursive resolver. It’s called recursive because it handles the full search journey on your behalf. It asks the right people, caches the answer, and hands it back to your device.

‍

Think of it like a librarian. You ask them for a specific book, and if they don’t have it in their quick-access shelf (the cache), they go talk to every department in the building until they find it.

‍

Here’s what it does:

‍

• Receives your DNS query (e.g., “What’s the IP of www.example.com?”)
  
  
• Checks its cache — if it already knows, it answers right away.
  
  
• If not, it goes on a journey: Root → TLD → Authoritative (we’ll get to those).
  
  
• Returns the IP address to your device so your browser can load the site.
  
  
• Caches the answer so it can reply faster next time.

‍

This server recurses down the chain so you don’t have to. ISPs usually give you one by default, but you can use faster public ones like Google DNS (8.8.8.8) or Cloudflare (1.1.1.1) if you want better privacy or speed.

‍

2. Root Nameserver 

‍

So once the recursive resolver realizes it doesn’t have the answer, it needs to ask someone. The first place it goes is the Root Nameserver.

‍

This server doesn’t know the final IP either — but it knows who to ask next.

‍

Let’s say you want to visit www.example.com. The root server only cares about the top of that domain — the .com part. So it tells the resolver, “For .com domains, go ask these TLD servers.”

‍

The root server is like the index of a huge phone book — it points you to the right chapter, but not to the exact number.

‍

Key facts:

• There are 13 logical root servers (A through M), but they’re mirrored on thousands of physical servers using Anycast (so your query hits the closest one).
• Root servers are the first real lookup when no one else has the answer cached.
• Maintained by a bunch of different orgs globally (e.g., ICANN, Verisign, universities, etc.).

‍

So when someone says the internet is decentralized — this is what they mean. The root isn’t a single server in some data center. 

‍

It’s spread out for redundancy, speed, and security.

‍

3. TLD Nameserver

‍

After the root server points your resolver to the right Top-Level Domain (TLD) server, that’s where we head next.

‍

Now the resolver is saying:

‍

“Okay, I know we’re looking for example.com — who owns example.com? Where can I get their info?”

‍

The TLD nameserver is specialized — it handles all domain names ending in .com, or .org, or .net, or country codes like .uk, .jp, etc. These are broken into two types:

‍

• gTLDs (Generic Top-Level Domains): like .com, .org, .net
• ccTLDs (Country Code TLDs): like .us, .ca, .de, .jp

‍

The TLD server doesn’t have the IP address either. But it does know which authoritative nameserver to talk to for example.com.

‍

So it replies:
“For example.com, go ask ns1.dnsprovider.net or ns2.dnsprovider.net — they have the final answer.”

‍

These TLD servers are run by organizations called registry operators. For example, Verisign runs .com. They maintain the directory that maps every .com domain to its authoritative server.

‍

4. Authoritative Nameserver 

‍

Now we’re at the end of the line — the authoritative DNS server.

‍

This server actually knows the answer. It stores the DNS records for a domain like example.com. If you’re a domain owner, this is the server where you create A records, CNAMEs, MX records (for email), and so on.

‍

This is the only server in the chain that holds official, up-to-date info about your domain. It doesn’t look things up — it answers directly.

‍

So when the recursive resolver finally gets here and asks, “Hey, what’s the IP for www.example.com?”, the authoritative server checks its zone file and says, “It’s 93.184.216.34. Here’s the TTL, too.”

‍

Once the recursive resolver gets that, it:

‍

• Sends the IP back to your device.
• Stores it for future queries.
• Done.

‍

Quick fact: Most domain owners don’t run their own authoritative nameservers. They use DNS providers like Cloudflare, AWS Route 53, Google Cloud DNS, or others. These are configured when you register the domain, via NS (nameserver) records.

‍

The Whole Process, Start to Finish

‍

Let’s say you visit a site for the first time and nothing is cached.

‍

Here's what happens behind the curtain:

‍

1. You enter www.example.com into your browser.
2. Your device checks its own cache. If no record is found...
3. It asks the recursive resolver (e.g., Cloudflare’s 1.1.1.1).
4. Resolver checks its cache. Still no luck? Onward.
5. Resolver queries a Root Nameserver, asking: “Where can I find .com?”
6. Root responds with a list of .com TLD servers.
7. Resolver asks a TLD server, “Who’s in charge of example.com?”
8. TLD server replies with the authoritative nameservers for that domain.
9. Resolver contacts the authoritative server, asking for the IP of www.example.com.
10. Authoritative server replies with the actual IP address.
11. Resolver caches the result and returns it to your device.
12. Browser connects to the web server using that IP\

‍

And you’re in.

‍

All of that might sound like a lot, but if nothing is cached, this can still happen in under 100 milliseconds. And once caching kicks in, most of these steps are skipped for subsequent visits.

‍

Why Bother Knowing the Server Types?

‍

If you’re in tech (or you troubleshoot anything involving DNS), knowing these roles helps a lot:

‍

• If a website’s down, is it the authoritative server misconfigured?
• Is the resolver caching an old value?
• Is the TLD or registrar pointing to the wrong NS?

‍

DNS feels invisible until it breaks. But once you understand what each of these servers does, diagnosing and fixing those problems becomes a lot easier.

‍

‍