Running your own DNS resolver
A resolver on the box is one of those things that costs almost nothing and improves latency, privacy and predictability at the same time. It is also the kind of service that fails silently at 3am if you treat it as set-and-forget.
Why bother
- Repeated lookups are answered from a local cache, so the second request is free.
- Your queries are not all visible to a single upstream provider.
- You can pin behaviour: no search-domain surprises, predictable timeouts.
Cache sizing is the whole game
Too small and the cache never warms up; too large and stale entries outlive the record's intent. Watch the hit rate rather than guessing — if it is not clearly above the noise after a day, the cache is either undersized or the traffic is too varied to benefit.
# example: unbound
cache-max-ttl: 86400
cache-min-ttl: 60
prefetch: yesThe failure modes to expect
A local resolver turns a shared upstream problem into a local outage. If it stops, everything on the host loses name resolution at once — which looks like a network failure and wastes time. Two habits make that survivable:
- Always list at least two upstreams, and know which is preferred.
- Monitor the resolver specifically, not just "the network".
Keep it boring
Bind it to loopback unless you have a reason not to. If other machines need it, decide deliberately who may query it — an open resolver is a liability, not a feature. Then leave it alone: a resolver you never think about is a resolver that is working.