> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/concepts/how-dns-works.md).

# How DNS Works

You type `example.com` and a page appears. But computers route data by number, not by name. Who does the translation, and can you trust the answer?

That translation is the Domain Name System, or DNS. It is one of the oldest and most load-bearing parts of the internet, and almost everything you do online begins with a DNS question.

## The phone book comparison

Think of a printed phone book. You know a person's name; you need their number. You look the name up, find the number, and place the call.

DNS does the same for the internet. You know `example.com`; your computer needs `93.184.215.14`. DNS is the lookup step, and it happens before any connection to the website is made.

The difference is that this phone book is far too large for any one book. No single machine holds every name on the internet. So the system is split into layers, and the lookup walks down them.

## Who answers the question

Four kinds of participant appear in a lookup.

* **Caches on your own machine.** Your browser keeps recent answers, and so does your operating system. If the answer is already there, no question leaves your device at all.
* **The recursive resolver.** This is the assistant that does the legwork for you. Your device asks it one question and expects one answer. It is usually run by your internet provider, but it can also be a public service or something you run yourself.
* **Root and TLD servers.** These do not know the final answer. They know who to ask next. The root servers know who handles `.com`, `.org`, `.de` and every other top-level domain. The `.com` servers know who handles each `.com` name.
* **The authoritative server.** The one that actually holds the record for the domain, published by whoever operates it.

Here is the full chain for a name your resolver has never seen:

```mermaid
sequenceDiagram
    participant B as Your browser
    participant R as Recursive resolver
    participant Ro as Root server
    participant T as .com servers
    participant A as example.com<br/>authoritative server
    B->>R: Where is example.com?
    R->>Ro: Where is example.com?
    Ro-->>R: Ask the .com servers
    R->>T: Where is example.com?
    T-->>R: Ask example.com's own servers
    R->>A: Where is example.com?
    A-->>R: 93.184.215.14
    R-->>B: 93.184.215.14
```

Only now does your browser open a connection to the website.

The whole exchange usually finishes in well under a second, and most of the time it is far shorter than the diagram suggests — because of caching.

## Caching and TTL

Asking the full chain every time would be wasteful. So every answer arrives with an expiry attached, called the **TTL** — time to live, measured in seconds.

A resolver that receives an answer with a TTL of 300 will reuse that answer for the next five minutes without asking again. Your operating system and browser do the same. Popular names are cached almost everywhere, which is why most lookups feel instant.

TTL is also why domain changes are not immediate. When a site moves to a new address, the old answer keeps being served from caches until it expires. This is the real meaning of "DNS propagation" — nothing is being propagated, old answers are simply expiring at different times in different places.

It also explains a common confusion: after you change your DNS settings, your device may keep using old answers for a while. Clearing the cache, or simply waiting, resolves it.

## Who your resolver usually is

Unless you have changed something, your recursive resolver is your **internet provider's**. Your router receives its address automatically when the connection comes up, and hands it to every device in your home.

This is convenient and usually fast, because the resolver is close to you. It also means your provider sees every domain name you look up, in order, with timestamps — even for sites you visit over HTTPS, because the lookup happens before the encrypted connection begins.

The alternatives are public resolvers run by other operators, or a resolver you run yourself. Changing resolver changes *who* sees your lookups. It does not make them invisible.

## Encrypted DNS: DoH and DoT

Traditional DNS travels in plain text. Anyone on the path — the local network, the provider — can read the questions and, in principle, alter the answers. Two standards fix the reading part by wrapping DNS in encryption: **DNS over HTTPS** (DoH), which makes lookups look like ordinary web traffic, and **DNS over TLS** (DoT), which uses a dedicated encrypted channel. Most modern browsers and operating systems support at least one, sometimes on by default. Both protect your lookups from observers between you and your resolver, and both make tampering much harder — but neither hides anything from the resolver itself, which still sees every question you ask. Encrypted DNS is a question of *who* can watch, not whether anyone can.

## Where things go wrong

DNS is a trust chain, and each link can fail or be interfered with.

* **Hijacking.** Something on the path answers instead of your chosen resolver. A hotel network redirecting you to a login page is a benign version. A network silently redirecting all lookups to its own resolver is less benign — your carefully chosen resolver setting is simply ignored.
* **Pollution or poisoning.** The answer that comes back is deliberately wrong, pointing you at a blocking page, a dead address, or a different server entirely. This is a common censorship mechanism, because it is cheap and works on every device at once.
* **Split answers.** The same name legitimately returns different addresses depending on who asks. Large services do this on purpose, to send you to a nearby server. So two resolvers disagreeing is not automatically evidence of tampering — but a wildly implausible answer, like a foreign site suddenly resolving to a local address, usually is.
* **Leaks.** You connect to a VPN, but your DNS questions still go to your provider's resolver outside the tunnel. The traffic is protected; the list of names you looked up is not. See [Am I Leaking My Real IP?](/knowledge-base/diagnose/am-i-leaking-my-real-ip.md).
* **Plain outages.** If your resolver stops answering, everything appears broken even though your connection is fine. "The internet is down" is often "DNS is down".

## Common misconceptions

**"HTTPS protects my DNS lookups."** It does not. HTTPS starts *after* the lookup finishes. Unless you use encrypted DNS, the names you visit travel in the clear.

**"Changing DNS makes browsing faster."** Sometimes marginally, because a nearer or better-cached resolver answers sooner. But DNS is a small fraction of page load time, and a resolver that is geographically distant can make things worse by sending you to a far-away copy of a website.

**"A different answer means someone is attacking me."** Not necessarily. Large sites return different addresses by design. Look for implausible answers, not merely different ones.

**"Private browsing hides my lookups."** It clears local history. The lookups still go to the same resolver.

{% hint style="info" %}
**See it yourself on MyIP**

[DNS Resolver](/knowledge-base/lookup-privacy/dns-resolver.md) asks the same domain from a set of well-known resolvers around the world at the same time, and lays the answers side by side. If one region's answer looks nothing like the others, you are seeing interference rather than ordinary load balancing.

If you suspect something is rewriting your answers, [Is My DNS Hijacked or Polluted?](/knowledge-base/diagnose/is-my-dns-hijacked.md) walks through the checks in order.
{% endhint %}

## Related concepts

* [What Is an ASN?](/knowledge-base/concepts/what-is-an-asn.md) — the networks your lookups travel across
* [GeoIP: How IP Geolocation Works](/knowledge-base/concepts/geoip-explained.md) — why nearby servers are chosen for you
* [Browser Fingerprinting Explained](/knowledge-base/concepts/browser-fingerprinting.md) — another way you are recognised without cookies
* [DNS Leak Test](/knowledge-base/connection-tools/dns-leak-test.md) — check which resolver you are really using


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ipcheck.ing/knowledge-base/concepts/how-dns-works.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.