You type a domain name and expect a page. Long before HTML arrives, your device must answer a simpler question: what IP address owns this name? That process — the Domain Name System — runs quietly on every click, app launch and API call. When it is slow or misconfigured, even a gigabit line feels broken.
The resolver chain
Applications do not talk to the global DNS root directly. They ask a recursive resolver — often configured by your router, ISP or a public provider. The resolver walks the hierarchy: root → top-level domain (.com, .it) → authoritative nameserver for the site → final A or AAAA record. Most of that work is cached, but the first visit to a name still costs round trips.
If the resolver is far away, overloaded or filtering aggressively, you pay latency on every cache miss. That is why switching resolvers sometimes feels like a speed upgrade even though your Mbps never changed.
Caching and TTL
DNS answers carry a TTL (time to live). Resolvers reuse cached records until TTL expires. Short TTLs help operators change IPs quickly; long TTLs reduce load and improve repeat-visit speed. When you change hosting, email or CDN settings, propagation delays are often just TTL expirations rippling through millions of caches — not magic, not sabotage.
Why pages feel slow despite fast speed tests
Modern pages call dozens of hostnames: the main site, analytics, fonts, ads, APIs. Each unique name is a potential cache miss. Add 80 ms per miss and a single page spends a second just on naming before bytes flow. Parallelism helps, but only after the resolver returns addresses. Fixing DNS often means:
- •Using a low-latency resolver close to you geographically
- •Reducing the number of third-party domains on your own sites
- •Checking that IPv6 (AAAA) records exist if your network prefers v6
DNSSEC and privacy (briefly)
DNSSEC adds cryptographic signatures so resolvers can detect tampered answers — it does not encrypt queries. For privacy, DNS-over-HTTPS and DNS-over-TLS hide query contents from local networks, but the resolver still sees where you go. Understanding that trade-off matters when you configure VPNs or parental controls: changing resolvers changes who learns your browsing destinations.
Practical checks anyone can run
Compare resolution time for a familiar site versus a random new domain. If the gap is large, caching is working. Query the same name from two networks (home vs mobile) — different answers often mean split-horizon DNS or stale cache, not a broken site. When migrating services, lower TTL before the cutover, then raise it again after traffic stabilises.
The takeaway
DNS is the address book of the internet. It is invisible when it works and infuriating when it does not. Treat resolver choice, TTL planning and cache behaviour as first-class parts of performance — not an obscure admin detail buried under megabits.