What Is DNS: Think of It First When a Page Won't Load

DNS translates a domain name into an IP address. The name typed into a browser's address bar cannot reach any server on its own; it has to be looked up first, and that lookup is what "DNS" refers to day to day.

Suspecting DNS first when a page won't load makes sense: it is the step that has to happen before the request even sets off, and if it goes wrong, no amount of network health downstream will get you to the right place. This article covers how DNS actually works, and whether it deserves to be the first suspect when something won't load.

Worth separating out first: what an IP address actually is covers the address itself. This article covers the lookup that finds it. The two are consecutive steps in the same process, not competing explanations.

What DNS actually is

Every site has a domain name that is easy for a person to remember, but what devices actually use to find each other is a numeric IP address. DNS is the system that translates a domain name into the matching address; without that step, a device has no idea where to send a request once a domain name is typed in.

Here's an analogy: a domain name is like the name printed on a business card, and an IP address is that person's actual street number. Someone who knows the name can recall who it is; a courier delivering a parcel still needs the street number. DNS is what gets you from the name to the number.

This translation is invisible day to day, because the whole process usually finishes in tens of milliseconds, and the result gets cached for a while. Visiting the same domain again shortly after often reuses that cached answer instead of looking it up fresh every time.

How DNS actually does its job

Looking up a domain roughly follows this order, moving to the next step only if the one before comes up empty:

1. Check the browser's own cache first — if this domain was looked up recently, use the remembered answer.
2. Check the system's cache next — the browser may not remember, but the system layer might.
3. Only once both come up empty does a request actually go out to the resolver the local network or carrier has specified.
4. If that resolver does not have the answer either, it asks a server further up the chain, all the way up to whichever one can give a definitive answer, then carries the result back down.

Those layers of caching exist to skip the last two steps as often as possible — they take the longest, and they are the most exposed to whatever happens along the way. That is also why "I just changed a setting and it looks like nothing happened" is often just a cache that has not expired yet, not a setting that failed to take.

For the person using it, that caching is mostly a good thing: the same site loads faster on repeat visits because the answer is often already at hand, skipping the two slowest steps entirely. It only turns into a problem once the cached answer itself is the wrong one, at which point the same caching that usually helps ends up slowing down the diagnosis.

Why suspect DNS first when a page won't load

A page failing to load can trace back to any of several layers, and DNS is only one of them. Still, checking it first makes sense, because it is the earliest step in the chain — if domain resolution never succeeds, the connection that follows never gets a chance to start.

One fairly recognisable signal: the page spins until it times out, rather than failing immediately with something like "unable to connect." That "stuck, not failing" pattern looks more like the resolution step never got an answer, leaving the device with nowhere to send the request and nothing to do but wait.

Another signal is reaching the same service directly by its IP address. If the IP address works and the domain name does not, that is fairly strong evidence the problem sits in domain resolution specifically, not in the network being down or the destination server having an issue.

A third signal is the same domain loading fine the moment you switch networks, say from home broadband to mobile data. That points at how much domain resolution depends on which network you are on: different networks specify different resolvers, and the same lookup can come back with different results depending on which one answers.

Does a DNS lookup reveal which sites I visit

A DNS query itself is usually unencrypted, so whoever can see that request along the way, a network's operator, for instance, can see which domain got looked up, even when the content opened afterward is itself encrypted. The domain name is a separate record, and it can still be visible on its own.

That is exactly why "the page content is encrypted" and "my browsing record cannot be seen" are not the same claim. Content encryption solves "the transmitted content cannot be read." A DNS lookup travelling on its own, outside that protection, can still leave a trace of "this domain got looked up." The two sit at different points in the chain. VPN encryption, the basics draws that boundary more precisely.

That is also why circumvention tools tend to advertise "DNS goes through the tunnel too" as a separate claim. Encrypting page content while leaving the DNS lookup outside the tunnel still exposes that record; the protection is incomplete without covering both.

Where you actually run into this

The scenario that comes up most is "DNS pollution" or "DNS hijacking": the lookup gets interfered with, the address that comes back is wrong, and the device happily connects to somewhere unreachable or somewhere it should not. It looks a lot like an ordinary network fault, except switching networks can make the same domain resolve correctly, because different networks specify different resolvers. DNS leaks, and how to check for one yourself covers the fuller self-check.

Another common claim is that switching to a public DNS server fixes circumvention problems on its own. Changing the resolver really can make lookups more accurate, but if the actual problem is a routing rule or the node itself, changing DNS will not touch it. DNS is one layer in the chain, not a master key. VPN connected but no internet: fix it in order works through DNS, routing rules, the system proxy, and the node in that order, with DNS as only the first of the four.

The DNS setting on a router affects every device connected to it, too. A phone or laptop that has not specified its own resolver inherits whatever the router hands out. Switch networks and the same device can get different resolution results, not because anything is wrong with the device, but because it inherited a different network's settings.

What DNS cannot do

DNS's job is translating domain names, nothing more. The following get mistaken for its responsibility fairly often.

• It does not carry the content itself. Once an address is resolved, the actual page content travels down a separate path; DNS's job ends the moment the address comes back.
• It does not encrypt anything. The lookup and its response usually travel unencrypted, which is exactly the source of the tracing issue covered above — not a deliberately left gap, but a job DNS was never designed to cover.
• It cannot make an unreachable destination reachable. If the destination server itself cannot be reached, or the network is blocked at a deeper level, resolving the correct address still will not connect you. DNS only handles "resolve the right address."
• It is not the only reason a page fails to load. Routing rules, a leftover system proxy from another tool, or the node itself can all produce the exact same "won't load" symptom. DNS is simply the layer worth checking first, not the only suspect.
• It never actively warns you when something goes wrong. A wrong or polluted resolution usually raises no prompt at all; the device just quietly connects to the wrong place, which is exactly why this layer tends to surface only through an indirect signal like a page stuck spinning.

In summary

DNS translates a domain name into an IP address, the step that has to succeed before a page can load, and the layer worth suspecting first when one does not, simply because it happens earliest. It does not carry content, does not encrypt anything, and is not the only reason a page can fail to load — treat it as the first layer in the diagnosis, not the only possible answer.

FastOrange's client takes over DNS lookups the moment it connects, routing them through a resolver inside the tunnel, with no need to change system or router settings by hand, and far less exposed to a resolver being polluted along the way. See what it does for the fuller picture. Every registered account gets free trial time daily, so connect once and see for yourself.