Premium Video

This video is available to premium subscribers only

Unlock Full Access

Every time you type a domain like example.com into your browser, your computer first has to answer a simple question: what IP address should it connect to?

That is the job of DNS, the Domain Name System.

This chapter explains how DNS resolution actually works, how caching and TTLs affect its performance, the most important DNS record types, and what happens behind the scenes when you type a domain name into your browser.

DNS stands for Domain Name System. Its main job is to translate human-readable domain names into IP addresses that computers can use to communicate.

You can think of DNS as a distributed directory for the internet. Instead of every user remembering the IP address of every service, we use stable domain names like example.com, and DNS figures out where those names should point to.

This also gives us an important layer of abstraction. The IP address behind a domain can change without users needing to know about it. If example.com moves to a new server at a new address, users keep typing the same name.

DNS is organized as a hierarchy rather than one giant database.

Each level is responsible for pointing you toward the next level.

The root servers don't know the IP address of every website on the internet. They only know where to find the servers responsible for top-level domains like .com. The .com servers then know which name servers are responsible for example.com. And those authoritative name servers contain the actual DNS records for the domain.

This hierarchical structure is one of the main reasons DNS can scale to billions of domain names without relying on a single central database.

Now let's see what actually happens when you enter a domain like example.com in your browser.

First, your browser checks whether it already has the DNS result cached. If not, the operating system may check its own DNS cache.

If the address still isn't available, the request goes to a recursive DNS resolver, usually provided by your Internet Service Provider or a public DNS service such as 8.8.8.8 or 1.1.1.1.

The resolver then starts looking for the answer:

Only after that does your browser connect to the destination server.

There are two important types of DNS queries: recursive and iterative.

Recursive means, "Find the final answer for me."

Iterative means, "Tell me what you know, or point me to the next server I should ask."

Your computer usually sends a recursive query to a DNS resolver. It is basically saying, "Find the IP address of example.com for me and give me the final answer."

Your computer does not want to contact the root server, the .com server, and the authoritative server itself. It delegates that work to the resolver.

The resolver then performs a series of iterative queries. It first asks a root DNS server, which points it to the .com TLD servers. It then asks a .com TLD server, which points it to the authoritative DNS server for example.com. Finally, the resolver asks the authoritative DNS server, which returns the actual DNS record.

The resolver then sends that final answer back to your computer.

DNS lookups would be too slow and inefficient if every request had to go all the way through the root, TLD, and authoritative servers. That's why DNS relies heavily on caching.

A DNS result can be cached at several layers:

So if example.com was looked up recently, the resolver may already have the answer and can return it immediately without repeating the full DNS lookup.

This makes DNS much faster and also greatly reduces the amount of traffic reaching authoritative DNS servers. A hundred lookups from users of the same resolver can turn into a single query to the authoritative server.

But cached records cannot stay there forever.

Each DNS record has a TTL, or Time To Live, which tells caches how long they can reuse that record before they need to fetch a fresh copy.

Any cache that receives this answer may reuse it for up to 300 seconds. After that, the entry expires and the next lookup fetches a fresh copy.

A longer TTL means DNS records stay cached for more time. That improves cache hit rates, reduces DNS traffic, and usually makes lookups faster.

But there's a tradeoff.

If you change the IP address of your service, users may continue using the old cached address until the TTL expires.

A shorter TTL makes DNS changes propagate faster, which can be useful for failover or traffic routing. But it also means caches expire more often, so DNS resolvers have to perform more lookups.

So TTL is really a balance between caching efficiency and how quickly you want DNS changes to take effect.

Now let's look at the DNS record types you're most likely to see.

With the CNAME above, , blog.example.com, and shop.example.com can all point at example.com. When the address behind example.com changes, every one of them follows it.

When you change a DNS record, the new value does not appear everywhere instantly.

This is often called DNS propagation, but what's really happening is mostly cache expiration. Nothing pushes the new value out to resolvers. Their cached copies simply run out.

Suppose api.example.com used to point to one IP address, and you update it to a new one.

Resolvers that do not have the old record cached may see the new value immediately. But resolvers that already cached the old value can continue using it until that record's TTL expires.

So for some period of time, different users may receive different answers for the same domain.

If you know you're about to migrate traffic or perform a failover, lowering the TTL in advance can help clients pick up the new DNS record more quickly. Lower it first, wait for the old, longer TTL to run out, and only then change the record. Caches then hold the old value for seconds instead of hours.

DNS translates human-readable domain names into IP addresses, and it lets the address behind a name change without users noticing.

It is organized as a hierarchy. Root servers point to TLD servers, TLD servers point to a domain's authoritative name servers, and those authoritative servers hold the actual records.

Your computer sends one recursive query to a resolver. The resolver does the iterative work of walking root, TLD, and authoritative servers, then returns the final answer.

Caching at the browser, the operating system, and the resolver makes DNS fast and keeps traffic off authoritative servers. The TTL decides how long each cached copy lives, which is a balance between caching efficiency and how quickly changes take effect.

That same caching is why record changes are not instant. What people call propagation is mostly old cached copies running out, so lower the TTL before a planned change.