You type github.com into your browser, hit Enter, and the page appears. No thought required. But somewhere in those few hundred milliseconds, a machine asked another machine a question in a language you never see, got an answer, and handed you a website. That middleman is DNS — and when it misbehaves, you don't get a slow website. You get a website that doesn't exist at all.
I've debugged this on my own machines more times than I care to admit, and I'll say it plainly: DNS is the single most misunderstood piece of plumbing on the internet. Everyone uses it. Almost nobody knows what it's doing. And your choice of DNS server quietly shapes how fast you browse, what you can reach, and who gets to watch you reach it.
What is DNS, and why does it affect your browsing?
DNS stands for Domain Name System. It's a naming system that translates human-readable domain names into IP addresses that computers actually use to find each other. When you type example.com, your browser doesn't know where that lives. It needs an address, something like 93.184.216.34, before it can open a connection. DNS is what supplies it.
The classic comparison is a phonebook, which is fine as far as it goes — but a phonebook doesn't try to reach a number, fail, and then try five other directories in sequence before it gives up. DNS does. It's a distributed, hierarchical lookup that usually completes in milliseconds, and you notice it only when it stops working.
Here's the part that actually matters for you: every single thing you load — every image, every font, every third-party script on a page — needs a name resolved before it can download. A homepage with 60 external resources can trigger dozens of DNS lookups. If each one adds 40 ms, that's over two seconds spent just figuring out where things are. The browsing itself hasn't started yet.
Key Takeaways
- DNS converts domain names into IP addresses. Without it, your browser has no idea where to connect.
- Resolution time is real latency. A slow resolver can add a second or more to a single page load.
- Your DNS server is chosen by your router or ISP by default — and it's very likely not the fastest option for you.
- Switching resolvers is a two-minute change that affects speed, privacy, and access to blocked content.
- Most "my internet is down" complaints are actually DNS failures. The connection works fine.
- DNS over HTTPS and DNS over TLS encrypt your lookups, which your ISP's resolver does not do by default.
How DNS actually works under the hood
There are four layers in a typical lookup, and knowing them is what lets you fix problems instead of restarting your router and hoping.
Your device and the local cache
Before anything hits the network, your operating system and browser check their own cache. If you visited the site recently, the answer is already there. This is why a site you use daily feels instant while a brand-new domain feels sluggish on first load. It's not the server — it's the lookup.
The recursive resolver
When your cache misses, your machine asks a recursive resolver. This is the DNS server you'll see in your network settings — the one your ISP gave you, or the one you set manually. It does the legwork: it queries the root servers, then the top-level domain servers (the ones handling .com, .org, .io), then finally the authoritative nameserver that holds the actual record for the domain.
The resolver then caches the answer for a period called the TTL, and hands it back to you. Next time, it already knows.
Why this explains your symptoms
If your resolver is slow, every uncached site is slow. If your resolver is unreachable, every site fails — even though your connection is perfectly healthy. And if a resolver has a bad cached record, you can get sent to the wrong place entirely for as long as the TTL lasts.
Should I turn DNS on or off?
You can't. There's no DNS setting to switch off, and if there were, you'd lose the web the moment you did. Browsing by IP address would be the only option left — typing 142.250.185.78 instead of google.com, for every site, every time. The internet would technically function and be practically unusable.
What you can turn off is your ISP's resolver. You can point your device at a different DNS provider. That's the switch people mean when they talk about "turning DNS on or off," and it's a change worth making.
One genuine exception: some routers and operating systems let you disable encrypted DNS (DoH) if it's causing conflicts with local network tools. If you run a home server, a Pi-hole, or a corporate VPN, encrypted DNS can sometimes route around your local resolver unexpectedly. That's a real reason to turn it off. For everyone else, leaving it on is the better call.
How do I fix my DNS problem?
Start by confirming it's DNS at all. The tell is simple: if you can reach a site by IP address but not by name, the connection is fine and the resolver is the problem. If neither works, you have a different issue entirely.
Once you're reasonably sure it's DNS, here's the order I'd work through, from cheapest to most disruptive:
- Flush your DNS cache. On Windows: ipconfig /flushdns. On macOS: sudo dscacheutil -flushcache. On Linux with systemd: sudo resolvectl flush-caches. This clears stale, wrong, or corrupted records in seconds.
- Change your resolver. Switch from your ISP's default to a public one, then check whether the problem persists. This solves the majority of "DNS server not responding" errors.
- Restart the router. Obvious, annoying, and effective more often than it should be. Your router caches DNS too, and it can go stale.
- Check your hosts file. A leftover entry from an old project can override DNS entirely and send you somewhere unexpected. It's the first place I look now, after losing an afternoon to exactly this.
- Test with a different network. Tether to your phone. If it works there, the issue is your router, your ISP, or your local configuration.
If none of it works, look at the exact error. DNS_PROBE_FINISHED_NXDOMAIN means the name doesn't resolve at all — often a typo, sometimes a genuinely dead domain. DNS_PROBE_FINISHED_NO_INTERNET usually means the network is down, not DNS. Reading the message saves time.
Can the internet work without DNS?
Mechanically, yes. Practically, no. The underlying network — routers, cables, servers — doesn't need DNS to move packets. It moves them by IP address. DNS is a convenience layer on top.
But remove it and the web as you know it collapses. Email delivery relies on MX records, which are DNS. Many APIs, cloud services, and CDN routing decisions resolve names before anything else happens. If you've ever typed an IP into your browser to bypass a broken DNS, you've seen the ceiling: it works for one site, and only if you already know the address.
Non-attributed reality check: most consumer traffic depends on DNS for essentially every connection it opens. There's no meaningful browsing experience without it.
Which DNS is best for browsing?
There's no single winner, because "best" depends on which of three things you care about: speed, privacy, or filtering. Here's how the main public options compare.
| Resolver | Primary address | Best for | Notable trade-off |
|---|---|---|---|
| Cloudflare (1.1.1.1) | 1.1.1.1 | Raw speed and privacy | Logs are minimal but anonymised data is retained |
| Google (8.8.8.8) | 8.8.8.8 | Reliability and global anycast coverage | Everything resolves through Google |
| Quad9 | 9.9.9.9 | Security — blocks known malicious domains | Aggressive blocking can flag legitimate sites |
| Your ISP's resolver | varies | Lowest latency if it's well-maintained | Often logs your full query history |
My own position, and I'll defend it: for general browsing, 1.1.1.1 wins. I switched from my ISP's resolver two years ago and shaved roughly 30 to 60 ms off uncached first loads on sites I visit rarely. On a fast fibre connection that's marginal. On a congested mobile network, it was the difference between a page feeling snappy and feeling broken.
If you want malicious-domain blocking without installing anything, Quad9 is the better pick. If privacy is your priority above all, look for a provider that publishes an audited no-logging policy rather than taking a marketing page at face value.
An example worth knowing
You're at a conference. The venue Wi-Fi loads your email fine, but your client's website times out. You assume the site is down. Nine times out of ten it's the venue's resolver failing to reach an authoritative nameserver for that domain. Switch to a public resolver and the page loads instantly. That single test — trying a second resolver — has saved me more support tickets than any other diagnostic step.
DNS is invisible by design, which is exactly why it's worth understanding. The next time a site won't load and your connection looks fine, you'll know where to look first — and you'll probably fix it in two minutes instead of waiting on hold. Which resolver you trust with every name you type is a small decision with an outsized footprint. Most people never make it consciously. You now have the option to.
