What does a DNS resolver actually do?

A recursive resolver does the searching on your behalf. When your device asks for a name, the resolver either returns a cached answer or walks the hierarchy, querying root, then top-level domain, then authoritative servers, until it has the address. It then returns that answer and caches it for future requests.

Why do DNS changes take time to appear?

Resolvers cache records for the duration of their TTL. Until that cached copy expires, those resolvers keep returning the old answer, so a change is only visible everywhere once all the relevant caches have timed out. Lowering the TTL before a planned change makes the switch happen faster.

What is the difference between an A record and a CNAME?

An A record maps a name directly to an IPv4 address, while a CNAME maps a name to another name, acting as an alias. The resolver follows a CNAME to its target and then looks up that target's A or AAAA record to find the final address.

Does DNS over HTTPS make me anonymous?

No. DoH encrypts your DNS queries so the local network and your provider cannot read which names you request. However, the resolver you use still sees every query, and DoH does not hide the destination IP your connection eventually reaches. It improves privacy but does not provide anonymity.

TTL stands for time to live. It is a value in seconds attached to each record that tells resolvers how long they may cache the answer before discarding it. A TTL of 3600 means the record can be cached for one hour. Lower values make changes propagate faster but increase lookup traffic.

DNS Explained

Every time you type a web address and press enter, an invisible lookup happens before the page even starts to load. Your browser does not know how to reach example.com directly, because computers route traffic using IP addresses, not friendly names. The Domain Name System, or DNS, is the service that translates the human-readable name into the numeric address a machine can actually connect to.

DNS is often called the phone book of the internet, and the comparison is fair, but it undersells how the system works. There is no single giant book. Instead DNS is a distributed, hierarchical network of servers that hand questions off to one another until the right answer is found, and the whole journey usually finishes in a fraction of a second.

This WhatIP guide walks through exactly what happens during a DNS lookup: the resolver that does the legwork on your behalf, the root and top-level domain servers that point the way, and the authoritative server that holds the real answer. We will also cover the main record types you will run into, how caching and TTL keep things fast, and how DNS over HTTPS changes where these lookups happen.

What DNS is and why it exists

DNS maps domain names that people can remember, like whatip.xyz, to the IP addresses that machines use to connect, like 203.0.113.10. People are good at names and bad at long strings of numbers, while routers and servers are the opposite. DNS sits in the middle and translates between the two.

The system is deliberately decentralized. No single organization holds every record. Instead, responsibility is delegated down a tree, so the operators of each domain control their own records while the overall structure stays consistent. This design lets DNS scale to billions of names without a central bottleneck.

The resolution path, step by step

When you request a name, several different servers cooperate to find the answer. Here is the typical journey for a fresh lookup of www.example.com that is not yet cached anywhere.

1. The stub resolver on your device

Your operating system has a small piece of software called a stub resolver. It does not do the searching itself. It simply forwards the question to a recursive resolver, usually run by your internet provider or a public service such as a well-known DNS provider.

2. The recursive resolver

The recursive resolver is the workhorse. Its job is to chase down the answer by asking other servers in turn. If it already has the answer in its cache from a recent lookup, it returns that immediately. Otherwise it begins the hierarchy walk described below.

3. The root servers

The resolver first asks a root server. The root does not know the address of www.example.com, but it knows who is responsible for the .com top-level domain. It replies with a referral pointing the resolver toward the .com servers.

4. The TLD servers

Next the resolver asks a .com top-level domain server. The TLD server does not hold the final answer either, but it knows which name servers are authoritative for example.com. It returns another referral, this time pointing at the authoritative servers for the domain.

5. The authoritative server

Finally the resolver asks the authoritative name server for example.com. This server holds the real records, so it returns the actual IP address for www.example.com. The resolver passes that answer back to your device, your browser opens a connection, and the page loads.

The whole chain, resolver to root to TLD to authoritative, often completes in well under a second on a first lookup, and far faster when cached.

Common DNS record types

A domain's records define how it behaves. The most common types you will encounter are:

A maps a name to an IPv4 address.
AAAA maps a name to an IPv6 address.
CNAME is an alias that points one name at another name.
MX specifies the mail servers that accept email for the domain.
TXT holds free-form text, widely used for email authentication policies and domain verification.
NS lists the authoritative name servers for the domain.
SOA is the start of authority record, holding administrative details like the primary server and refresh timers.
CAA states which certificate authorities are allowed to issue certificates for the domain.

You can inspect any of these for a real domain using the WhatIP dns-lookup tool, and check mail routing specifically with the mx-lookup tool.

Caching and TTL

If every lookup had to walk the full hierarchy every time, DNS would be slow and the root and TLD servers would be overwhelmed. Caching prevents this. When a resolver receives an answer, it stores the record for a set amount of time before discarding it.

That lifetime is the TTL, or time to live, measured in seconds and attached to every record by the domain owner. A record with a TTL of 3600 may be cached for one hour. During that hour, any device asking the same resolver for the same name gets the cached answer instantly, with no hierarchy walk at all.

A worked example of TTL behavior

Imagine an A record for blog.example.com pointing at 198.51.100.20 with a TTL of 3600 seconds. You decide to move the blog to a new server at 198.51.100.45 and update the record at 12:00.

A resolver that last looked up the name at 11:50 cached the old answer with one hour to live, so it will keep returning 198.51.100.20 until 12:50.
A resolver doing its first lookup at 12:05 gets the new address right away.
A visitor whose resolver still holds the stale record reaches the old server until the cache expires.

This is why DNS changes are described as needing time to propagate. Nothing literally spreads across the world. Instead, scattered caches simply expire on their own schedules. A common trick before a planned change is to lower the TTL to a small value a day in advance, so caches turn over quickly when the real change lands.

DNS over HTTPS

Traditional DNS queries travel in plain text over the network, which means anyone between you and your resolver can see which names you look up, and in principle could tamper with the answers. DNS over HTTPS, abbreviated DoH, addresses the visibility problem by wrapping DNS queries inside an encrypted HTTPS connection to the resolver.

With DoH, an observer on the local network sees an ordinary encrypted web connection rather than a readable list of the domains you visit. Many modern browsers and operating systems can use DoH directly. The trade-offs are worth knowing: encryption hides your queries from the local network and your provider, but the resolver you send them to still sees every name you request, so the choice of resolver matters. DoH also does not hide the destination IP address your connection ultimately goes to, only the name lookup itself.

A related protocol, DNS over TLS, achieves similar privacy on a dedicated port rather than riding inside HTTPS.

Why the hierarchy is so resilient

The split between root, top-level domain, and authoritative servers is not just an organizational nicety. It is what makes DNS robust at internet scale. The root zone is small and changes rarely, so its data can be copied to hundreds of physical servers spread across the world using a technique called anycast, where many machines share the same address and the network simply routes you to the nearest one. That redundancy means a single failure, or even a large regional outage, does not take the root offline.

The same delegation model means responsibility is spread out. The operators of the .com zone never need to know the address of any individual website. They only need to know which name servers are authoritative for each registered domain. The domain owner, in turn, controls only their own records. No single party has to hold or update the entire internet's data, which removes the central bottleneck that a literal phone book would create.

This layering also explains why a misconfiguration usually affects only one domain rather than the whole system. If the authoritative server for one domain returns a wrong answer, every other domain keeps resolving normally, because each branch of the tree is independent.

What happens when a name does not exist

Not every lookup succeeds. When you query a name that has no record, the authoritative server returns a specific response known as NXDOMAIN, meaning the name does not exist. Resolvers cache these negative answers too, for a period controlled by a field in the SOA record, so a flood of requests for a missing name does not hammer the authoritative servers. This is why a typo in a domain name can sometimes keep failing briefly even after you correct the underlying record: the negative answer was cached. Understanding negative caching saves a lot of confusion when troubleshooting.

Common pitfalls

Expecting instant changes. Because of TTL caching, a record change can take as long as the old TTL to be visible everywhere. Lower the TTL before planned changes.
Pointing a CNAME at the apex. A CNAME cannot coexist with other records at the root of a domain, which causes errors if attempted.
Forgetting the trailing dot. In raw zone files, a fully qualified name ends with a dot. Leaving it off can cause the domain to be appended unexpectedly.
Blaming DNS for everything. Many connection problems look like DNS failures but are caused elsewhere. Use the dns-lookup tool to confirm what records actually resolve before assuming DNS is at fault.

With a clear picture of the resolution path, record types, and caching, DNS stops being mysterious and becomes a system you can reason about and troubleshoot.

DNS Explained: How Domain Name Resolution Works