DNS for ISPs: Recursive Resolvers, Caching and Why They Matter
Every web page, app and stream begins with a DNS lookup. It is the most-used service on your network and, ironically, one of the most overlooked — a piece of infrastructure that runs invisibly until it stutters, at which point your customers experience it as “the internet is slow.” They do not call the website; they call you. That perception gap is the whole reason DNS deserves engineering attention out of proportion to the traffic it carries.
The frustrating part is that DNS is almost never the bottleneck in raw terms. The queries are tiny and the answers are tiny. But because nothing happens on the network until a name resolves, a slow or flaky resolver taxes every single action a customer takes. Add a hundred milliseconds to DNS and you have added it to the start of every page load, every app launch, every video. Good DNS is one of the highest-leverage, lowest-cost investments an ISP can make in perceived speed.
What a recursive resolver actually does
Most ISPs run recursive resolvers for their subscribers. When a customer's device asks for a name, it is not asking the resolver to know the answer — it is asking the resolver to go find it. The resolver walks the DNS hierarchy on the customer's behalf: it asks the root which servers handle the top-level domain, asks those which servers are authoritative for the domain, and asks those for the actual record. That recursion is several round trips across the internet, and the customer's device waits the whole time. This is why a resolver doing cold lookups feels sluggish.
The thing that makes it fast is caching. Once the resolver has an answer, it holds it for the duration of the record's TTL (time-to-live) and serves it instantly to the next customer who asks. At ISP scale this is enormously effective: thousands of subscribers hammer the same few hundred popular destinations, so the overwhelming majority of queries are answered from cache in well under a millisecond, never leaving your network. A healthy resolver might satisfy the large majority of queries from cache. The recursion only happens for the cold misses — a long tail of less-popular names.
The TTL is the lever the rest of the internet hands you, and respecting it matters. Short TTLs let content owners move services quickly — failover, load balancing, CDN steering all depend on records expiring fast — but they also push more recursion onto your resolver because cached answers go stale sooner. Long TTLs cache beautifully but mean your customers can keep hitting a destination's old address for a while after it moves. You do not get to choose other people's TTLs, but you do get to respect them rather than overriding them, because aggressively clamping TTLs to squeeze a better hit rate is how you end up sending customers to an address that no longer serves them.
Why running your own resolvers pays off
- Speed: a resolver physically near your customers, with a warm cache full of the destinations they actually visit, answers far faster than a distant public resolver doing recursion from scratch. Proximity plus cache hit rate is most of the win.
- Reliability: you own it, so you can make it redundant, monitor it, and fix it. Depending entirely on someone else's resolver means their outage becomes your outage, and you have no visibility into why.
- Control and troubleshooting: you can implement lawful filtering or safe-browsing options where you are required to, and — just as importantly — you can see what is happening when a customer reports a name not resolving, instead of shrugging at a third party's black box. When a popular destination changes its records or an authoritative server misbehaves, an operator who runs the resolver can inspect what was cached and why; an operator who outsourced it can only wait.
Keeping them fast, reliable and safe
A resolver is deceptively simple to stand up and surprisingly easy to run badly. The non-negotiables:
- Redundancy: run at least two resolvers on separate infrastructure, ideally in separate failure domains, and hand both to customers. If DNS dies, the internet effectively dies for your subscribers even though packets still flow perfectly — there is no more total-feeling outage than working links with dead DNS.
- Capacity: resolvers field a relentless query rate, and it spikes at peak hours. Size them for the busy evening, not the quiet afternoon, and watch latency as your leading indicator — rising response time is the early warning before outright failure.
- Cache-poisoning defence: a resolver tricked into caching a forged answer sends every customer asking for that name to an attacker. Modern source-port and transaction randomisation, and validating answers where you can, are the baseline defences.
- Do not run an open resolver: a resolver that answers queries from the whole internet, not just your subscribers, will be conscripted into amplification attacks against others. Restrict it to your own address space. This is one of the most common and most damaging misconfigurations on the internet.
Do and don't
| Do | Don't |
|---|---|
| Run at least two resolvers in separate failure domains | Depend on a single resolver, or on a third party with no fallback |
| Restrict service to your own subscriber IP ranges | Leave the resolver open to the entire internet |
| Monitor query latency and cache hit rate as health signals | Watch only up/down and miss creeping slowness |
| Respect record TTLs so caching actually works | Override TTLs so aggressively that cache value collapses |
| Place resolvers close to customers for low round-trip time | Backhaul every lookup to a distant central site |
How DNS fails in production
The instructive failures are rarely “DNS is down.” They are the grey ones. A resolver under-capacity at peak does not stop answering — it just gets slow, and the whole network feels heavy for two hours every evening while the daytime tests look fine. A cache that is not warming properly turns too many queries into full recursions, multiplying latency. An upstream path to the authoritative servers degrades and a subset of domains intermittently fail to resolve, generating a baffling stream of “some sites don't load” tickets that no link graph explains. And the open-resolver case can flip from invisible to catastrophic overnight when your boxes are used to attack someone else and the abuse traffic saturates your own links.
Encrypted DNS: DoH and DoT
Increasingly, devices, operating systems and browsers can send DNS encrypted — DNS over HTTPS (DoH) or DNS over TLS (DoT) — and some do so to a third-party resolver by default, quietly routing your customers' lookups off your network to a distant provider. That hands away the speed benefit of your local cache and your visibility for troubleshooting. The constructive response is to offer your own fast, privacy-respecting resolvers and support encrypted DNS to them where you can, so customers keep their lookups local and quick rather than bouncing them halfway across the world. Fighting encrypted DNS is a losing battle; offering a good encrypted resolver of your own is not.
Common mistakes
The recurring errors are predictable: running a single resolver and discovering the redundancy gap during its first outage; leaving a resolver open to the world; sizing for average load and getting buried at peak; treating DNS as a fire-and-forget service with no latency monitoring; and ignoring encrypted DNS until a default setting has already shifted your customers' traffic elsewhere. None of these are exotic. They are simply the consequences of treating the most-used service on the network as an afterthought.
The takeaway
DNS is cheap to run well and expensive to run badly. A pair of fast, well-cached, monitored recursive resolvers — restricted to your subscribers, sized for peak, and reachable over encrypted DNS — is among the highest-leverage things you can do for perceived speed, and it pairs naturally with sound capacity planning and network monitoring. Because to your customers, slow DNS is a slow internet, and they will never know the difference.