pfSense's built-in DNS Resolver — powered by Unbound — is one of the most capable DNS engines you can run on a home or business network, but out-of-the-box it ships with a configuration that leaves real performance and security gains on the table. Whether you're migrating from the older DNS Forwarder (dnsmasq), setting up a fresh pfSense installation, or chasing a stubborn resolution failure, this guide covers exact menu paths, CLI verification commands, and every gotcha that trips up even experienced admins.

DNS Resolver vs. DNS Forwarder: Which One Are You Running?

pfSense ships with two DNS services and only one should be active at a time. The DNS Resolver (Unbound) performs full recursive resolution — it contacts root servers, walks the delegation chain, and validates DNSSEC signatures without relying on an upstream forwarder. The DNS Forwarder (dnsmasq) simply passes queries to whatever DNS servers are configured under System > General Setup.

Most guides written before pfSense 2.2 (released 2015) described the Forwarder as the default. Since pfSense 2.2, the Resolver has been the default. If you upgraded from an old config, you may have both enabled simultaneously — which causes unpredictable behavior and is the single most common source of DNS complaints on pfSense forums.

💡 Not sure which service is answering queries on your network? Use our DNS Propagation Checker to verify what your public DNS record looks like, and use dig or nslookup pointed at your pfSense LAN IP to confirm local resolution is working.

Step 1: Disable the DNS Forwarder Before Touching the Resolver

Navigate to Services > DNS Forwarder. If Enable DNS Forwarder is checked, uncheck it and click Save. Then scroll down and click Apply Changes. Running both services will cause port 53 conflicts and intermittent failures.

Step 2: Core DNS Resolver Settings

Go to Services > DNS Resolver. Here is every field that matters, with the recommended value and why it exists.

General DNS Resolver Options

  • Enable DNS Resolver — Check this. Without it, Unbound won't start.
  • Listen Port — Leave at 53 unless you have a specific reason (e.g., running Pi-hole on the same box).
  • Network Interfaces — Select your LAN interface(s). Avoid selecting WAN here; you don't want external clients querying your resolver. If you have multiple VLANs, add each one.
  • Outgoing Network Interfaces — Select WAN (or your multi-WAN gateway group). This controls which interface Unbound uses to reach root servers.
  • System Domain Local Zone Type — Set to Static. This makes Unbound authoritative for your local domain and prevents it from leaking internal hostname queries to the internet.
  • DNSSEC — Check Enable DNSSEC Support. This validates cryptographic signatures on DNS responses. See the DNSSEC section below for caveats.
  • DNS Query Forwarding — Leave unchecked for full recursive resolution. If you check this, Unbound forwards to the DNS servers under System > General Setup instead of resolving recursively. Both modes are valid; recursive is more private.
  • DHCP Registration — Check Register DHCP leases in the DNS Resolver. This allows devices to resolve each other by hostname on your LAN.
  • Static DHCP — Check Register DHCP static mappings in the DNS Resolver as well.

Advanced Resolver Options (Custom Configuration)

The Custom options text box at the bottom of the DNS Resolver page accepts raw Unbound configuration directives. This is where you unlock features the GUI doesn't expose. Paste each directive on its own line. Common high-value options:

server: # Reduce attack surface — refuse queries from non-LAN addresses access-control: 0.0.0.0/0 refuse access-control: 127.0.0.1/32 allow access-control: 192.168.1.0/24 allow # Cache tuning cache-min-ttl: 300 cache-max-ttl: 86400 neg-cache-size: 4m # Privacy — minimize query data sent upstream qname-minimisation: yes # Prefetch popular records before TTL expires prefetch: yes prefetch-key: yes # Harden against DNS rebinding attacks private-address: 192.168.0.0/16 private-address: 172.16.0.0/12 private-address: 10.0.0.0/8 private-address: 169.254.0.0/16 harden-dnssec-stripped: yes harden-glue: yes harden-referral-path: yes # Threading (set to number of CPU cores) num-threads: 2 msg-cache-slabs: 4 rrset-cache-slabs: 4 infra-cache-slabs: 4 key-cache-slabs: 4 # Increase cache sizes (in bytes) rrset-cache-size: 256m msg-cache-size: 128m

After pasting, click Save and then Apply Changes. Unbound will restart. If it fails to start, the custom options contain a syntax error — check Status > System Logs > DNS Resolver for the exact line number.

Step 3: System General Setup — Critical Alignment

Navigate to System > General Setup. Under DNS Server Settings, you have two critical checkboxes:

  • Do not use the DNS Forwarder/DNS Resolver as a DNS server for the firewall itself — Leave this unchecked unless you have a specific reason. When unchecked, pfSense itself uses Unbound (127.0.0.1) for its own DNS queries, which is the correct behavior.
  • DNS Server Override — If your ISP pushes DNS servers via DHCP, this allows them to override your configured servers. For a self-resolving Unbound setup, this is irrelevant since you're not forwarding, but uncheck it to be safe.

If you are running Unbound in forwarding mode, add your preferred upstream resolvers (e.g., 9.9.9.9 for Quad9, or 1.1.1.1 for Cloudflare) in the DNS Server fields here.

Step 4: DHCP Server — Point Clients at pfSense

Go to Services > DHCP Server and select your LAN interface. Under Servers, set the DNS Servers field to your pfSense LAN IP address (e.g., 192.168.1.1). Leave the second DNS field blank, or enter a fallback only if you intentionally want clients to bypass Unbound when pfSense is unreachable. Save and apply. Existing clients won't update until their DHCP lease renews; you can force a renewal with:

# Windows ipconfig /release && ipconfig /renew # macOS sudo ipconfig set en0 DHCP # Linux (systemd-networkd) sudo systemctl restart systemd-networkd # Linux (dhclient) sudo dhclient -r && sudo dhclient

Step 5: Host Overrides and Domain Overrides

Host Overrides

Host overrides let you create manual A/AAAA records for internal devices — essential for split-DNS setups where an internal server shares a name with a public record. Navigate to Services > DNS Resolver > Host Overrides and click Add. Fill in:

  • Host — the hostname portion (e.g., nas)
  • Domain — your local domain (e.g., home.arpa or local)
  • IP Address — the internal IP
  • Description — optional label

Domain Overrides

Domain overrides tell Unbound to forward queries for a specific domain to a different DNS server — useful when you have an Active Directory domain controller that is authoritative for your internal AD domain. Navigate to Services > DNS Resolver > Domain Overrides and add:

  • Domain — e.g., corp.example.local
  • IP Address — your AD DNS server IP

This is the correct way to integrate pfSense with Active Directory DNS — not by forwarding all queries to the DC, which would break public resolution for everything else.

Step 6: DNS over TLS (DoT) with Forwarding Mode

If you prefer to forward queries over an encrypted channel rather than resolving recursively, pfSense 2.5+ supports DNS over TLS natively in the Resolver. Enable DNS Query Forwarding in the Resolver settings, then add your upstream servers under System > General Setup. To force DoT, add the following to the Custom Options box:

forward-zone: name: "." forward-tls-upstream: yes forward-addr: 9.9.9.9@853#dns.quad9.net forward-addr: 149.112.112.112@853#dns.quad9.net forward-addr: 1.1.1.1@853#cloudflare-dns.com forward-addr: 1.0.0.1@853#cloudflare-dns.com

Port 853 is the standard DoT port per RFC 7858. The #hostname suffix enables TLS certificate name verification — without it, DoT is encrypted but unauthenticated.

⚠️ When using DoT forwarding, disable DNSSEC in the GUI if your upstream provider doesn't return DNSSEC-signed responses — Unbound will refuse to answer queries it can't validate, causing widespread failures. Quad9 and Cloudflare both support DNSSEC, so the combination above is safe.

Step 7: Enabling DNSSEC Properly

DNSSEC validation in Unbound requires a current root trust anchor. pfSense manages this automatically via the unbound-anchor utility. If DNSSEC validation is failing, run from the pfSense shell (Diagnostics > Command Prompt or SSH):

unbound-anchor -v # Should output: success: the anchor is ok # If the anchor file is missing or stale: unbound-anchor -a /var/unbound/root.key -r /var/unbound/root.hints

A common DNSSEC failure mode: ISPs that perform DNS-level ad injection (NXDOMAIN hijacking) break DNSSEC validation. If you see SERVFAIL responses for DNSSEC-signed domains, your ISP is likely intercepting DNS on port 53 and returning unsigned answers. The fix is to use DoT on port 853 (above) or switch to full recursive resolution which bypasses your ISP's DNS entirely.

CLI Verification: Confirming the Resolver Works

After saving and applying all settings, verify resolution from multiple angles. From a client on your LAN:

# Basic A record query — response should come from 192.168.1.1 dig @192.168.1.1 example.com A # Check DNSSEC validation — look for 'ad' flag in the flags line dig @192.168.1.1 dnssec-failed.org +dnssec # A DNSSEC-validating resolver should return SERVFAIL for this domain # Check a local host override nslookup nas.home.arpa 192.168.1.1 # Verify no DNS leaks to external resolvers dig @192.168.1.1 whoami.akamai.net TXT # Windows alternative nslookup example.com 192.168.1.1 Resolve-DnsName example.com -Server 192.168.1.1

From the pfSense shell itself:

# Check Unbound is running service unbound status # View Unbound statistics unbound-control stats_noreset | head -30 # Test local resolution host example.com 127.0.0.1 # Dump Unbound config to verify custom options parsed correctly unbound-checkconf /var/unbound/unbound.conf

Use our DNS Lookup tool to cross-reference that your public-facing DNS records match what you expect, especially after making split-DNS or domain override changes.

Common Misdiagnoses and Their Real Fixes

"DNS isn't working" but the real problem is firewall rules

If clients can't reach pfSense on port 53, Unbound doesn't matter. Check Firewall > Rules > LAN — there must be a pass rule allowing TCP/UDP port 53 from LAN net to LAN address (not WAN). pfSense creates this rule by default, but custom lockdown configs sometimes remove it.

Clients ignoring pfSense DNS

Modern devices (especially Android 9+, Windows 11, iOS 14+) have Private DNS / DNS over HTTPS settings that bypass your DHCP-assigned resolver entirely. Android uses Cloudflare or Google DoT by default if it detects an internet connection. Fix: either configure a firewall rule redirecting all outbound port 53 traffic to pfSense (NAT port forward), or configure a DNS sink for DoH/DoT traffic on ports 443 and 853.

NAT redirect for DNS (forces all LAN DNS through pfSense):

Navigate to: Firewall > NAT > Port Forward Add rule: Interface: LAN Protocol: TCP/UDP Destination: invert match, LAN address Destination port: 53 Redirect target IP: 127.0.0.1 Redirect target port: 53 Description: Redirect all DNS to Unbound

Slow first query, fast subsequent queries

This is normal behavior for a cold recursive resolver — the first query for an uncached domain walks the full delegation tree. Enable prefetch: yes in custom options (already included in the block above) to have Unbound refresh cache entries before they expire. Also increase rrset-cache-size if you have available RAM.

SERVFAIL for everything after enabling DNSSEC

Usually a clock synchronization issue. DNSSEC signatures have validity windows; if your pfSense clock is wrong, all signatures will fail validation. Check Services > NTP and ensure at least one NTP server is configured and reachable. Run ntpdate -q pool.ntp.org from the pfSense shell to check time offset.

IPv6 Considerations in 2026

If your ISP provides IPv6, configure Unbound to listen on your LAN IPv6 interface as well. Under Services > DNS Resolver > Network Interfaces, add your LAN6 interface. Add corresponding access-control lines in custom options for your IPv6 prefix (e.g., 2001:db8::/32 allow). Unbound will automatically handle AAAA record resolution for dual-stack clients. Verify with:

# Query via IPv6 transport dig @2001:db8::1 example.com AAAA # Check Unbound is listening on IPv6 ss -lnup | grep :53

With the wider adoption of DNS over HTTPS (DoH) in 2026, consider also deploying a local DoH endpoint using Nginx reverse-proxy in front of Unbound. This allows browsers configured for DoH to use your pfSense resolver without bypassing it — a more sustainable solution than blocking DoH wholesale.

How to Confirm Everything Is Working

  1. Client receives pfSense LAN IP as DNS server via DHCP — verify with ipconfig /all (Windows) or cat /etc/resolv.conf (Linux).
  2. dig @192.168.1.1 example.com returns a valid A record with status: NOERROR.
  3. dig @192.168.1.1 dnssec-failed.org returns status: SERVFAIL (DNSSEC validation is working).
  4. Local hostnames registered via DHCP resolve: nslookup mypc.home.arpa 192.168.1.1 returns the correct IP.
  5. Status > DNS Resolver shows Unbound running with no error messages.
  6. unbound-control stats_noreset | grep total.num.queries shows incrementing query counts.

Preventing Recurrence

  • After every pfSense upgrade, review Services > DNS Resolver — major version upgrades occasionally reset custom options or change default behaviors. Keep a copy of your custom options block in a text file.
  • Enable System > Backup & Restore automatic backups to the Netgate portal or a local SFTP server. Your DNS config is included in the XML backup.
  • Monitor Unbound with Status > Monitoring — graph DNS query rates. A sudden drop to zero means Unbound crashed; set up a package notification alert if you're running pfSense Plus.
  • Keep the root hints file current. Unbound ships with a bundled hints file, but updating it annually prevents slow resolution if root server IPs change. Download the latest from IANA and upload to /var/unbound/root.hints.