Choosing Between pfSense DNS Resolver and DNS Forwarder: A Decision Guide

Decision Overview

When configuring DNS on pfSense you must decide whether to run the built‑in Unbound resolver (recursive, DNSSEC‑validating) or the dnsmasq‑based forwarder (simple UDP/TCP forwarding). The choice hinges on three practical constraints:

1. Security requirement – Do you need DNSSEC‑validated answers?
2. Resource availability – How much CPU and RAM can the firewall spare?
3. Privacy preference – Should queries stay inside the firewall or be allowed to go to external resolvers?

If any of the first two constraints demand a lightweight service and DNSSEC is not required, the forwarder is a viable option. Otherwise, the resolver is the only supported way to get DNSSEC validation inside pfSense.

Option Comparison

Feature	Unbound Resolver	dnsmasq Forwarder
Service type	Recursive caching resolver with DNSSEC validation	Simple UDP/TCP forwarder (no validation)
Port binding	Binds to UDP/TCP 53 on the firewall host (requires root)	Can run as an unprivileged process; still listens on 53
Upstream protocol	Supports plain UDP/TCP and TLS (DoT) on port 853	Only plain UDP/TCP; no TLS support
Resource usage	Higher CPU and RAM due to caching and validation	Low CPU/RAM footprint
DNSSEC	Full validation, sets AD flag on verified responses	No validation; AD flag never set
Privacy	Queries can be resolved locally or sent to TLS‑protected upstream resolvers	Queries are forwarded to configured upstream servers (often ISP or public resolvers) without encryption

Trade‑offs

• Resolver – Pros: DNSSEC validation, ability to use DoT for encrypted upstream, local caching reduces repeated external queries.
• Resolver – Cons: Higher memory consumption (typically 50‑150 MB depending on cache size), slightly higher latency per query (≈1‑2 ms) due to validation work.
• Forwarder – Pros: Minimal resource use (<10 MB RAM), sub‑millisecond latency for cached forwards, simple to enable/disable.
• Forwarder – Cons: No DNSSEC, queries leave the firewall in plaintext, privacy depends on upstream resolvers.

Configuration Example: Enabling the Resolver with DNSSEC and DoT

Assume you have admin access to the pfSense WebGUI or can SSH into the firewall as root. The steps below switch the DNS service from the default forwarder to the resolver, configure DNSSEC validation, and point Unbound to a TLS‑protected upstream resolver (e.g., Cloudflare 1.1.1.1 over DoT).

1. Backup current DNS config (optional but recommended):
   

   # From SSH or Diagnostics > Command
   cp /conf/configdns_resolver.xml /conf/configdns_resolver.xml.bak

2. Disable the forwarder:
   Navigate to Services → DNS Forwarder and uncheck Enable DNS forwarder. Click Save.
3. Enable the resolver:
   Go to Services → DNS Resolver, check Enable DNS resolver. Under Network Interfaces select the interfaces that should listen (usually LAN and optionally localhost).
4. Activate DNSSEC:
   In the same page, check DNSSEC Query Forwarding and DNSSEC. This tells Unbound to perform validation and set the AD flag.
5. Configure TLS upstream (DoT):
   Scroll to DNS Over TLS, check Enable DNS over TLS. Add an upstream server, e.g., 1.1.1.1 with port 853 and hostname cloudflare-dns.com. Save.
6. Apply changes:
   Click Apply Changes at the bottom. The GUI will rewrite /conf/configdns_resolver.xml and reload Unbound.

Permissions & Risks: The WebGUI requires admin privileges. Changing the DNS service will cause a brief interruption (typically <1 second) as the resolver restarts; ensure no critical lookups are in flight. If you lose DNS connectivity after the change, you can revert by restoring the backup file or re‑enabling the forwarder via the GUI.

Verification

After applying the configuration, verify that the resolver is active and DNSSEC is working.

1. GUI status check:
   Visit Status → DNS Resolver. The page should show the service as Running, display the Unbound version, and report a non‑zero cache size after a few queries.
2. Command‑line test (AD flag):
   From any host on the LAN (or via SSH on the firewall) run:

   dig @192.168.1.1 example.com +dnssec

   Replace 192.168.1.1 with the LAN IP of the pfSense box. Look for the ad flag in the answer section; its presence indicates DNSSEC‑validated data.
3. Unbound control status:
   Via SSH (root) execute:

   unbound-control status

   The output includes the number of recursive queries, cache size, and whether DNSSEC validation is enabled.
4. TLS upstream test:
   If you configured DoT, you can confirm TLS usage with:

   unbound-control lookup @1.1.1.1 example.com

   If the resolver is using TLS, the query will succeed without falling back to plain UDP.

Limitations and Practical Checks

Even with the resolver enabled, consider these limits:

• Cache size is bounded by the Cache MB setting; excessive growth can trigger evictions. Monitor via Status → DNS Resolver or unbound-control stats.
• Firmware upgrades may overwrite /conf/configdns_resolver.xml. Before a major version upgrade, back up the file and, after upgrade, verify that your resolver settings remain intact.
• If you rely on external DNS for split‑horizon scenarios, ensure the resolver’s access control lists (ACLs) under Access Control allow the necessary subnets.

A quick practical check after any change is to run a series of dig queries against known DNSSEC‑signed domains (e.g., sigok.verteiltesysteme.net) and confirm the ad flag is set each time. If the flag is missing, revisit the DNSSEC enable checkbox and verify that upstream resolvers support DNSSEC.