Introduction to DNS

Why It Matters

Without DNS, using the internet would mean memorizing numbers. With it, you get four things.

User-friendliness. Domain names are easier to remember and type than IP addresses, which are long strings of digits.

Scalability. DNS is a distributed and hierarchical system rather than one enormous server, which is how it copes with the ever-growing number of names and addresses on the internet.

Flexibility. A website can change its IP address without affecting users. The DNS records are updated, and people keep reaching the site through the same domain name.

Load balancing. DNS can spread user requests across several servers, which improves the performance and reliability of a site.

Reading a Domain Name

A domain name is a human-readable address made of character strings separated by dots, like www.example.com.

Read it from the right.

A top-level domain (TLD) is the rightmost part, such as .com in www.example.com. TLDs come in two kinds:

• Generic TLDs (gTLDs) name a category: .com, .org, .net.
• Country-code TLDs (ccTLDs) name a country or territory: .us for the United States, .uk for the United Kingdom.

A subdomain is a subdivision of a domain name, used to create a separate section of a site. Subdomains appear to the left of the main domain. In blog.example.com, blog is the subdomain of example.com.

The Three Kinds of Server

The hierarchy that makes DNS scale is built from three tiers of server.

Root servers sit at the highest level and direct queries to the right TLD server. There are 13 root server clusters worldwide, run by various organizations, and each cluster holds multiple servers for redundancy and reliability.

TLD servers store information about the domain names inside their own TLD. Given a query, a TLD server points to the authoritative name server responsible for that domain.

Authoritative name servers hold the actual DNS records for a domain, including its IP address. They give the final answer to a query.

Notice that only the last one actually knows the answer. The first two exist to narrow the search.

Resolvers: Who Does the Work

A DNS resolver is any component, software or hardware, responsible for turning a domain name into an IP address. There are several kinds, and they differ in how much of the job they take on.

Stub resolver. The minimal DNS client running on your device. It knows one or more DNS servers to ask, sends the query to one of them, waits, and hands the reply back to the application. It does not do the lookup itself. The server it asks is usually set automatically by your router, or set by hand, which is what you are doing when you configure 8.8.8.8 for Google Public DNS or 1.1.1.1 for Cloudflare.

Recursive resolver. A DNS server that actually performs the lookup on the client's behalf. It checks its own cache first. If the answer is not there, it queries the root servers, then the relevant TLD server, then the authoritative server, until it has the answer. It then caches the result and returns it. Most internet providers run one, and Google Public DNS, Cloudflare and OpenDNS are public examples.

Caching-only resolver. A server whose main job is to cache query results and reuse them. It hosts no DNS zones of its own, meaning it is not authoritative for any domain. Many home routers work this way: once one device in the house looks up a site, the next device gets the answer from the router almost instantly.

Forwarder. A DNS server that passes queries it cannot answer to another DNS server upstream instead of doing the full lookup itself. Companies use this to manage, log and filter DNS in one place, and it can still keep a local cache.

Iterative (non-recursive) resolver. Rather than chasing the answer, it returns either what it already knows or a referral naming another server to try next. This is uncommon on end-user devices. It is mostly how authoritative servers behave: asked about a subdomain they do not handle, they reply with the address of the name server that does.

The Whole Path, End to End

Put those pieces together and one lookup looks like this.

1. You type a name into your browser.
2. Your device's stub resolver sends the query to its configured DNS server, often your provider's or a public one.
3. That recursive resolver checks its cache. If the answer is there, it comes straight back.
4. If not, the resolver asks a root server, then the TLD server, then the authoritative server for the domain.
5. The IP address comes back, gets cached along the way, and reaches your device.
6. Your browser connects to that address and the page loads.

Step 3 is the one that matters most in practice. Most lookups stop there.

💡 If an interviewer asks how a request reaches your service, do not begin at the load balancer. Beginning at the DNS lookup shows you know there is a resolution step before any of your infrastructure is involved, and it is where techniques like geographic routing actually happen.

Key takeaway: DNS translates domain names into IP addresses, like a phonebook for the internet. Names are read right to left: TLD, then domain, then subdomain. Three tiers of server narrow the search, root to TLD to authoritative, and only the authoritative server holds the records. Resolvers differ by how much work they do: a stub resolver only asks, a recursive resolver walks the whole hierarchy, and an iterative one hands back a referral instead.

The next lesson, DNS Resolution Process, looks at the two query styles and at the caching that keeps most lookups from ever reaching a root server.