DNS explained: the phone book that decides where you land

DNS turns a name you can remember into an address a machine can connect to. Every time you open a page or your phone checks for mail, something asks "what is the address for this name" and something answers. That answer decides where your connection lands, so DNS is not just a lookup service, it is the thing that chooses your destination. Change which server answers and you change what you can reach, what gets blocked, and who keeps a record of where you went.

The lookup chain, step by step

Say you type a site name into the address bar. Before any page content moves, this happens.

1. Your device asks its own memory first. Operating systems cache recent answers, and a local hosts file overrides everything.
2. Failing that, it asks the resolver configured for the network. At home your router hands that out automatically, usually pointing at your internet provider.
3. That resolver, called a recursive resolver, does the legwork. It asks a root server which machines handle .com, asks those which machines handle the domain, then asks the domain's own authoritative name servers for the record.
4. The answer comes back as an A record for an IPv4 address or an AAAA record for IPv6. Other types do other jobs, such as MX for mail delivery.
5. Your browser opens a connection to that address and the encrypted handshake begins.

Cold, that chain takes tens of milliseconds. Warm, it is almost instant. One useful detail: DNS resolves only the host part of an address, the piece before the first single slash, and nothing after it ever reaches a DNS server. That is the same boundary that decides whether a link goes where it claims, which the anatomy of a URL makes easy to read.

Caching, TTL and the myth of propagation

Every DNS answer arrives with a time to live, the number of seconds it may be reused before it has to be asked again. Whoever runs the domain picks it, and values commonly sit between five minutes and a day. The answer is cached in the browser, the operating system, often the router, and the resolver itself, where it is shared with everyone else using it. That is why a second visit feels instant.

It also explains the thing people call propagation. When a site moves, nothing spreads outward across the internet. The new record is available at the source immediately, and what you are waiting for is old cached copies elsewhere to expire. That is why administrators drop the time to live to a couple of minutes the day before a planned move, and why you can see the new site while a colleague still sees the old one. Clearing your own cache does nothing when the stale copy sits in your provider's resolver.

Why DNS trouble looks like the internet is down

When DNS stops working, the failure is total and confusing. Every app breaks at the same moment, the wifi icon still shows full bars, pages report that the server cannot be found, and a video call that was already running carries on, because it has its address already and never asks again.

One test separates the cases. If a numeric address loads but no names work, DNS is the problem and the rest of your connection is fine. If neither works, the fault is further down: the router, the line or the provider.

The usual causes are an overloaded resolver, a router up for weeks with a confused cache, a hotel captive portal intercepting lookups until you sign in, and a VPN that changed your DNS settings and never changed them back. If the symptom is slowness rather than failure, use the ordered checks for diagnosing a slow connection, because DNS is rarely why a line is slow.

What your resolver can see about you

A resolver sees one line per lookup: the time, the address of the device asking, and the name requested. Across a day that is a detailed diary, and not only of sites you chose to visit. It captures whatever your hardware talks to on its own: the television, the doorbell camera, the app checking for updates every hour.

It does not see the rest: not the page you opened, not what you typed into a search box, not the contents of anything. Encryption between your browser and the site covers that, which is what the padlock actually proves.

Two things follow. Changing your resolver moves the log rather than deleting it, so the real question is who you would rather have holding it and what their retention period says. And DNS logs are a separate record from the cookies, pixels and identifiers that follow you between websites. No DNS setting touches those.

Encrypted DNS: DoH and DoT

Classic DNS travels unencrypted over port 53. Anyone watching the network can read your lookups, and anyone able to inject traffic can forge an answer. Two fixes are widely supported. DNS over TLS encrypts the query on a dedicated port, which is easy for a network administrator to allow or block on purpose. DNS over HTTPS sends it inside ordinary web traffic on port 443, where a network can barely tell it apart, and a browser can turn it on without the rest of the device knowing.

The last column is the part marketing skips. Even with perfect encrypted DNS, your provider still sees the numeric addresses you connect to, and can usually read the site name announced in plain text as the encrypted handshake starts. An extension called Encrypted Client Hello closes that gap where both browser and site support it. It is also the honest limit of the claim made for a consumer VPN: it moves who sees your lookups rather than making them unseen.

Filtering and hijacking: the same lever twice

Because the resolver chooses the answer, whoever runs it can decline. A filtering resolver checks the name against category lists and returns nothing, or an address showing a block page. That one mechanism powers household content controls, network wide blocking of ad and tracker domains, and the malware blocklists built into many resolvers.

It is useful and it is blunt. Filtering works on whole domains, so it cannot block one video and allow another on the same site, and it breaks things in ways that are hard to diagnose weeks later. Anyone who changes the DNS setting on their device, switches to mobile data, or turns on encrypted DNS in a browser is past it. It also inspects nothing, so a bad file from an allowed domain sails through. Treat it as one layer of a family setup, never the plan.

The same lever in hostile hands is DNS hijacking: a router whose DNS settings were changed after someone reached its admin page with the default password, a rogue server handing out settings on a network you do not control, or an attacker taking over a domain's registrar account and repointing the whole thing. The goal is usually a convincing fake of a bank or mail login, so hijacking is best understood as phishing with no link to click.

Two defenses matter. The practical one is the certificate warning: a redirected connection cannot normally present a valid certificate for the name you asked for, so the warning you were about to click through is the alarm. The structural one is DNSSEC, which lets a domain sign its records so a resolver can check they were not altered. It proves authenticity and provides no privacy.

What to set up today

Start by finding out what you use now. The router admin page shows the resolver your whole house inherits, and the network settings on a computer or phone show whether that device overrides it.

If you change it, pick the level first. A resolver set on the router covers everything, including devices with no settings screen, but stops applying the moment a laptop leaves the house. Set per device, it travels. Many households do both.

Then turn on encrypted DNS. Recent systems expose it plainly: Private DNS on Android, an encrypted DNS setting on current Windows and Apple systems, a secure DNS option in the main browsers. Choose a resolver on the criteria that actually differ: retention policy, whether it filters and what, jurisdiction, and whether it has servers near you.

Finally, write down how to undo it, because a broken resolver looks exactly like a broken connection. While you are in the router, change the admin password if it is still the printed default and check for pending firmware, since an out of date router is where most DNS hijacking starts.