Why use/not use your own DNS resolver

In this guide we explain what a DNS resolver is, how it relates to a DNS forwarder and an authoritative name server, and in which scenarios a local resolver is beneficial for home and business environments. As basic background, we recommend first briefly reading what DNS and name servers are.

What is a DNS resolver?

A DNS resolver is the component that answers DNS queries on behalf of a client (for example your laptop or server). Say you go to google.com in your browser: your browser sends a DNS query to a DNS resolver to find out which IP address belongs to the google.com website.

A recursive resolver walks the DNS hierarchy if needed (root > TLD > authoritative) and temporarily stores answers in a cache. Thanks to caching, repeated lookups are answered extremely quickly and the resolver generates far less external traffic. For example, when you visit a random website, the first DNS query to find the matching IP address might take 100 ms, but due to caching a repeat visit will only take a few milliseconds. 

Many operating systems include a simple ‘stub’ resolver. In this guide, however, we focus on a local recursive resolver on your own network that serves all clients in your LAN — for example a pfSense VPS acting as DNS resolver for multiple VPSs in a private network, or a DNS resolver at router level that acts as DNS resolver for all physical devices (computers, laptops) on your local network. 

DNS hierarchy at a glance

The DNS system is built as a hierarchy:

• DNS starts at the Root: this is the starting point of DNS (the ‘.’ zone). Root name servers know where to find the TLD name servers, but do not contain DNS data for specific domain names.
• TLD (Top Level Domain): name servers for zones such as .nl, .com or .org. They refer to the name servers that are responsible for the DNS data of individual domains within a zone, such as example.com.
• Authoritative DNS server: the source of truth for a specific DNS zone (e.g. example.com). This server manages the zone file and provides definitive answers for names within that zone (such as A/AAAA, MX, CNAME, TXT and NS records). It does not perform recursive lookups.

Resolver vs forwarder vs authoritative server

In the DNS landscape, at the level of the authoritative DNS servers, you can distinguish three roles:

• Resolver (recursive): answers DNS queries by walking through the DNS hierarchy and caching the results. A resolver can validate answers using DNSSEC.
• Forwarder: accepts DNS queries from clients (e.g. your PC) and forwards them to one or more upstream DNS resolvers (e.g. Cloudflare), often via DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH), while still keeping local caching and policy.
• Authoritative DNS server: is the source of truth for one or more zones (e.g. example.com) and provides definitive answers about DNS records in those zones.

Schematically, a DNS request follows these steps: Client (your computer/laptop) > Local resolver > Root > TLD > Authoritative server. 
The steps Root > TLD > Authoritative server only come into play if the local resolver in your operating system, or the DNS resolver between your OS and the public internet, does not yet have an answer to the DNS queries. If the local resolver can already answer, the rest of the hierarchy is not consulted. 

When using a forwarder, the forwarder sends traffic directly to a trusted upstream, usually one or more authoritative servers. 

Why use a local DNS resolver?

1. Faster home / (small) office network thanks to caching

You have multiple devices (PCs, phones, TVs, IoT devices) using your local DNS resolver. The resolver (e.g. Unbound) retrieves answers to DNS queries recursively and caches them. The first lookup for example.com might take around 100 ms; subsequent lookups from any device are answered in milliseconds from cache. 

• Faster repeated lookups; browsing feels more responsive.
• Less upstream traffic to your ISP or public DNS.
• A central cache also helps ‘stubborn’ IoT devices without their own configuration options to execute commands faster.

2. Maximum privacy (‘trust-no-one’)

Don’t want a third party (ISP, Google, Cloudflare) to see all DNS queries from your network? In recursive mode, your resolver talks directly to root, TLD and authoritative servers. That way there is no single log with one external party. Add Query Name Minimisation and other Unbound privacy options to limit unnecessary metadata and protect your privacy even further.

• Better privacy: your DNS resolver performs the resolution, so your internet provider has no visibility of those queries.
• Combine with DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH) towards specific upstreams if you (temporarily) use a DNS forwarder.

3. Internal hostnames and split DNS (homelab/office)

For internal services such as a NAS, office network or printer, you define ‘host overrides’ and ‘domain overrides’ in the resolver. Internal clients receive internal IPs in response; the rest of the world is resolved recursively. Split-horizon DNS (different internal vs external answers) also works cleanly this way.

• No more per-device hosts-file hacks.
• NAT-free and faster internal traffic by answering with internal IPs.
• Works well across multiple VLANs and with DHCP integration.

4. Central DNS filtering / ad blocking

Combine your resolver with blocklists (for example pfBlockerNG on pfSense) or your own overrides so that ads, trackers and malware domains are answered with NXDOMAIN or a sinkhole IP. Because all clients use the resolver, filtering applies across the entire network. 

• Ad/malware blocking for every device (including TVs and guest Wi-Fi, but not YouTube, as YouTube serves its ads over the same YouTube domain).
• Unwanted lookups never leave your network.
• No need for separate ad blockers on each device.

5. DNSSEC validation at the edge

A validating DNS resolver checks DNSSEC signatures and only serves validated answers. Clients do not need to understand DNSSEC themselves; the resolver takes care of it.

• Extra protection against spoofing/injection and ‘NXDOMAIN hijacking’ by intermediaries.
• You are not blindly relying on the DNSSEC implementation of an external resolver.

6. More control over upstreams (forwarding, DoT/DoH)

Do you deliberately want to use specific upstreams (such as Cloudflare) or encryption via DoT/DoH? Run your resolver in forwarder mode towards those endpoints. You keep local caching, overrides and filtering; only the recursive ‘heavy lifting’ is done upstream.

• A single central place to manage policy and trusted upstreams.
• Changing upstreams is done once on the resolver; all clients benefit immediately.

7. Less dependent on outages at your ISP’s DNS

In recursive mode, your resolver is independent of your provider’s DNS servers. If you use forwarders, configure multiple upstreams (e.g. Cloudflare) and set sensible time-outs/failover.

• Less impact when ‘DNS is down’ at the ISP.
• No more ‘helpful’ search pages instead of proper NXDOMAIN answers.

8. Large or ‘chatty’ networks & IoT

Lots of clients or very noisy IoT devices? Repeated lookups are answered from the local cache and you have central insight into what is being queried. Apply filtering per VLAN if desired.

• Less wasted bandwidth and lower latency for apps with many DNS calls.
• Faster troubleshooting: a single place for logs and cache inspection.

9. Clean integration with DHCP and multiple VLANs

Let DHCP hand out the address of your resolver to every network zone. The resolver automatically registers DHCP leases so that names like laptop1 or phone-<colleague-name> work straight away. Restrict access using access lists (for example only LAN/Servers may use your resolver, not guests).

• Internal naming ‘just works’ across VLANs.
• Fine-grained access control per network segment.

When is a local DNS resolver less useful?

• A tiny network (one PC + one router) where privacy/filtering is not important: using your ISP/public DNS directly is often “good enough”. A few hours of downtime is not a disaster.
• If each device deliberately uses its own DoH (hard-coded in the browser/app): local policies and caching are then largely bypassed.

Practical tips

• Use a proven resolver such as Unbound (on your router, pfSense firewall or VPS).
• Enable Query Name Minimisation and, where applicable, DNSSEC validation.
• Need forwarding? Choose trusted upstreams and use DoT/DoH where possible.
• Lock down your resolver from the internet with strict access lists; see Securing a DNS resolver.
• If your resolver runs on a Linux server and you want to change system-wide resolvers, follow our article ‘Changing the DNS resolver’.