How DNS Resolution Works: Step by Step, Server Types, Caching, and Failure Modes Explained

When your browser needs an address for a name such as pudgycat.io, DNS helps find it. Sometimes the answer is already cached; sometimes a resolver has to ask other servers. This guide explains that process, why answers can change, and how to distinguish a lookup problem from a website that is having a bad day. The internet’s address book is surprisingly busy for something nobody remembers opening.

Table of Contents

• What Is DNS and Why Do We Need It
• How DNS Resolution Works, Step by Step
• The Four Types of DNS Servers
• DNS Record Types You Should Know
• DNS Caching and TTL
• Recursive vs Iterative DNS Queries
• DNS Security: DNSSEC, DoH, and DoT
• When DNS Breaks: Common Failure Modes
• Frequently Asked Questions

What Is DNS and Why Do We Need It

The Domain Name System associates names with typed records, including IP addresses. A browser can use an address to contact a service, but DNS also supports mail routing and other purposes. It does not fetch the web page itself. Think “find the destination,” then “make the connection”: two related jobs that can fail independently.

Early internet host-name mappings were distributed in a central HOSTS.TXT file. Paul Mockapetris’s DNS specification describes why that approach became difficult to scale. DNS distributes responsibility across a hierarchy instead. Its history is a gradual deployment and evolution, not a single day when the entire world changed its settings.

Names vs IP Addresses

A service’s address can change without its name changing. A name can also have several address records. That flexibility helps separate the name visitors remember from the machines or network locations serving them. DNS does not guarantee one permanent number for one website.

How DNS Resolution Works, Step by Step

Here is a simplified lookup path, consistent with the Cloudflare DNS explainer. Browser, operating-system, and network settings can alter it; it is not an eight-stop journey repeated on every page load.

1. Local lookup. The browser or operating system may already have a usable cached answer.
2. Local configuration. Hosts files and application settings can affect name resolution. Their exact precedence depends on the system.
3. Choose a resolver. The device may use its network’s resolver, a configured public service, or a browser’s encrypted-DNS provider.
4. Ask for an answer. A recursive resolver can reply from its cache or pursue the lookup.
5. Find the relevant delegation. If needed, the resolver asks a root server where to find the top-level domain’s servers.
6. Follow the next referral. A TLD server can direct it toward the domain’s authoritative servers.
7. Get the record. An authoritative answer may contain an address, an alias requiring another lookup, or a negative result.
8. Return the result. The resolver responds, and eligible records can be cached. The browser can then attempt a connection.

There is no universal lookup time. Cache state, network distance, retries, server load, and configuration all matter. DNS is also only one part of loading a page; a quick answer cannot make a slow application server hurry up.

The Four Types of DNS Servers

These are useful roles to recognize. Root and TLD servers are themselves authoritative for their respective zones; the categories describe where a server sits and what service it provides, not four unrelated species of machine.

1. Recursive Resolver

A recursive resolver pursues answers on a client’s behalf, often using cached information and sometimes another upstream resolver. A home router may forward queries rather than do the full work itself. Public resolver providers also have different filtering and retention policies; “public DNS” is not a uniform promise of speed or privacy.

2. Root Name Server

There are 13 named root-server identities, A through M, operated by 12 organizations across many distributed instances. The root-server operators’ site describes that system. These servers serve the root zone, including TLD delegations. “Thirteen roots” does not mean thirteen physical computers with the entire internet queued outside.

3. TLD Name Server

A TLD’s authoritative servers serve its zone, including delegations for names beneath it. They do not retain a live directory of every domain ever registered, nor do they necessarily contain the final address of each website. A referral tells the resolver where to ask next.

4. Authoritative Name Server

An authoritative server serves data for a zone. Domain administrators publish changes through their DNS provider or their own system; redundant servers can serve the same zone. “Authoritative” describes responsibility for that data, not ownership of the website or a guarantee that the operator configured it correctly.

DNS Record Types You Should Know

DNS uses different record types for different purposes. The IANA registry lists them and their specifications. Common examples include:

• A record: maps a name to an IPv4 address.
• AAAA record: maps a name to an IPv6 address. Pronounced “quad-A”.
• CNAME record: an alias. Points one name to another name (for example, www.example.com as an alias for example.com).
• MX record: mail exchange. Tells email servers where to deliver mail for the domain.
• TXT record: arbitrary text. Used for SPF, DKIM, domain ownership verification, and (in the wild west of internet plumbing) sometimes for service configuration.
• NS record: name server. Lists the authoritative DNS servers for a domain.
• PTR record: points to another domain name; reverse-DNS zones use it to associate an address with a name. It need not exactly invert a website’s A record.
• SRV record: service location. Defines the hostname and port for a specific service (used by SIP, XMPP, Minecraft, and similar).
• CAA record: certificate authority authorisation. Tells the world which certificate authorities are allowed to issue HTTPS certificates for the domain.

You can inspect any of these from a terminal. On Linux and macOS, dig pudgycat.io returns the A record. dig -t MX pudgycat.io returns the mail records. On Windows, nslookup does the same job.

DNS Caching and TTL

DNS resource records carry a TTL, measured in seconds, which ordinarily limits how long they can be reused from a cache. RFC 1035 defines the field. These example durations illustrate the trade-off, rather than mandatory settings:

• 300 seconds: five minutes.
• 3600 seconds: one hour.
• 86400 seconds: one day.

Changing an authoritative record does not immediately erase cached copies. Lowering the TTL beforehand can help with a planned change, but copies cached under the old TTL still need time to age out. Negative answers can also be cached, as described in RFC 2308. Some resolvers support serving expired data under defined failure conditions, so TTL is not a universal stopwatch for every observable result.

Recursive vs Iterative DNS Queries

People often conflate these two terms. They describe different roles in the same chain.

A recursive query asks a resolver to obtain the answer rather than leave the client to pursue referrals. A small client-side resolver is often called a stub resolver. “Resolver” therefore does not always mean a public recursive service.

With iterative queries, the querying resolver can follow referrals itself. It may already have enough cached delegation information to skip the root or TLD step. The hierarchy explains who is responsible, not a fixed itinerary.

Delegation spreads responsibility; caching avoids repeating work. That is the architectural trick, even when the actual path is shortened by information somebody already has.

DNS Security: DNSSEC, DoH, and DoT

Classic DNS has two ugly properties. It is unencrypted, and it does not authenticate the answers. Three modern protocols fix different parts of the problem.

DNSSEC

DNSSEC lets a validating resolver check the authenticity and integrity of signed DNS data through a chain of trust. It does not encrypt queries, certify that a website is harmless, or authenticate unsigned data by magic. A broken validation chain can itself cause resolution to fail.

DNS over HTTPS (DoH)

DNS over HTTPS (DoH) carries DNS messages over an encrypted HTTPS connection. It protects that transport from straightforward eavesdropping and alteration. The selected resolver still processes the query, and encrypted DNS does not conceal every clue about the websites you visit. HTTPS packaging is not a cloak of perfect invisibility.

DNS over TLS (DoT)

DNS over TLS (DoT) uses a TLS-protected DNS connection, conventionally on port 853. Its dedicated port makes that traffic easier to distinguish from ordinary HTTPS. Like DoH, its protection covers the configured encrypted connection, not every stage of a website visit.

Encrypted transport and signed DNS data address different risks. Neither removes the need to choose a resolver you trust. In particular, encrypting a connection to a malicious resolver does not make its answers honest.

When DNS Breaks: Common Failure Modes

DNS is one possible cause of a failed visit, alongside network, TLS, hosting, application, and database problems. Check the symptom before changing settings. Common DNS-related results include:

• NXDOMAIN: the queried name does not exist. An existing name with no record of the requested type is a different negative answer, often called NODATA.
• SERVFAIL: resolution failed. DNSSEC validation errors are one possible cause, alongside other upstream or server problems.
• Cached old answer: an earlier record may still be within its TTL. Flushing a local cache does not flush every resolver upstream.
• Wrong answer: misconfiguration or tampering can direct a lookup incorrectly. DNSSEC validation and encrypted transport have different, limited protective roles.
• Resolver outage: another permitted resolver may help diagnose a local provider problem. It cannot repair a broken authoritative zone or a failed web server.

The October 2016 attacks on Dyn show how disruption to a DNS provider can affect access to many services at once. Dyn’s preserved incident analysis describes attacks on its managed-DNS infrastructure and explicitly says it could not verify reports of a 1.2 Tbps magnitude. The lesson does not require turning an unconfirmed number into a fact.

For the next part of the journey from a name to something playing on screen, see our video-streaming explainer. Resolving an address starts the trip; it does not deliver the video by itself.

Frequently Asked Questions

How long does DNS resolution take?

It depends on caching, network conditions, and whether retries are needed. A local cached result can be very quick, but there is no dependable universal maximum for a cold lookup.

What is the difference between a DNS resolver and a DNS server?

A DNS server answers DNS queries. A resolver is the component that obtains answers; it may be a small client-side stub or a recursive service. Root and TLD servers usually supply authoritative zone data rather than perform recursion for your browser.

How do I flush my DNS cache?

On Windows, ipconfig /flushdns clears the DNS client resolver cache. Other systems and applications have their own procedures, which vary by version. Clearing one cache does not change authoritative records or clear a provider’s cache.

Should I change my DNS resolver?

It can be useful for troubleshooting, but performance and privacy vary by provider and network. Work or school devices may depend on a particular resolver for internal services. Check the applicable settings and policies, and record the original configuration before changing it. A different resolver is not a universal cure for a slow connection.

Can DNS be used to block websites?

Yes. A resolver can refuse or alter answers, but DNS filtering is only one blocking method. Directly entering an IP may not work with shared hosting and HTTPS. Encrypted DNS and DNSSEC are not guaranteed ways around restrictions; other network controls can still apply.

The Takeaway

DNS is easy to overlook until a name stops resolving. The useful model is a hierarchy of responsibility supported by caches, not an inflexible chain that runs on every visit. When a site fails, DNS deserves a check—not an automatic conviction. Even the internet’s address book cannot fix a database that has gone out for lunch.

🐾 Curiosity looks good on you. Explore the Goodies, or find our illustrated books on Amazon.