Every time you open a browser, send an email, stream a video, or check the weather on your phone, something happens before any of that traffic moves across the wire. A query fires off to a system so fundamental to the internet that most people never think about it. That system is the Domain Name System, and it is the single most critical piece of infrastructure on any network.

DNS is not just plumbing. It is the first thing that happens in nearly every network connection. It is also one of the most powerful and underutilized security tools available to network administrators. If you are not thinking about DNS as a security control, you are leaving a massive gap in your defenses.

This article covers three things: why DNS matters far more than most people realize, how to configure pfSense to use encrypted DNS aligned with the latest NIST guidance, and how to get the best possible DNS security out of an ISP-provided modem or router when a dedicated firewall is not in the picture.

What DNS Actually Does#

At its core, DNS translates human-readable domain names into machine-readable IP addresses. When you type example.com into a browser, your device has no idea what to do with that string of characters. It needs an IP address like 93.184.216.34 to establish a connection. DNS provides that translation.

But calling DNS a “phone book for the internet” drastically understates what it does. DNS is a globally distributed, hierarchical database that handles billions of queries per day. It resolves mail routing information, service discovery records, authentication policies for email (SPF, DKIM, DMARC), certificate validation, and much more. It is the foundation on which virtually all other network services depend.

If DNS stops working, everything stops working. Web browsing fails. Email delivery halts. Cloud applications become unreachable. VPN tunnels cannot establish. Authentication systems break. DNS is not just important. It is mission-critical infrastructure.

Why DNS Is a Security Goldmine#

Here is the part that changes how you think about your network: DNS is not just a service to protect. It is a service that provides protection.

Every network connection starts with a DNS query. Before malware can phone home to a command-and-control server, it has to resolve that server’s domain name. Before a phishing site can load in a user’s browser, the browser has to look up the site’s IP address. Before data can be exfiltrated through a DNS tunnel, those queries have to pass through a resolver.

This means DNS sits at a unique chokepoint. If you control the resolver, you can see and act on every connection attempt before it happens. This is the concept behind what NIST SP 800-81r3 calls Protective DNS – a DNS service enhanced with security capabilities to analyze queries and take action to block threats in real time.

Protective DNS can block access to known malicious domains before a connection ever establishes. It can filter categories of content that violate organizational policies. It can generate query logs that are invaluable for incident response and forensic investigation. And it does all of this at scale, across every device on the network, without installing agents or modifying endpoints.

Think about that. A single infrastructure change at the DNS layer protects every device on your network – workstations, servers, phones, tablets, IoT devices, printers, security cameras – without touching any of them individually.

The Problem with Traditional DNS#

Traditional DNS has a critical flaw: it is completely unencrypted. Every query your devices send travels across the network in plaintext on UDP port 53. Anyone positioned between your device and the DNS server – your ISP, a threat actor on a compromised network segment, a rogue access point – can see every domain you resolve. They can also tamper with the responses, redirecting you to malicious sites without your knowledge.

This is not a theoretical risk. DNS hijacking, cache poisoning, and man-in-the-middle attacks against DNS are well-documented and actively exploited. Your ISP can see every domain you visit even if the sites themselves use HTTPS, because the DNS query happens before the encrypted HTTPS connection is established.

NIST SP 800-81r3, published in March 2026, addresses this directly. The document recommends encrypting DNS traffic wherever technically feasible and deploying protective DNS as a foundational layer of network defense. These are not aspirational suggestions. For federal agencies, encrypted DNS is now a requirement. For everyone else, it is a best practice that has become straightforward to implement.

Encrypted DNS: DoT, DoH, and DoQ#

Three protocols exist to encrypt DNS traffic:

DNS over TLS (DoT) wraps traditional DNS queries inside a TLS session on TCP port 853. It is the most mature of the three and has the broadest support among network equipment, including pfSense. The dedicated port makes it easy to manage with firewall rules.

DNS over HTTPS (DoH) sends DNS queries over standard HTTPS on TCP port 443. This makes it harder to distinguish from normal web traffic, which is both an advantage (harder to block by censors) and a disadvantage (harder for network administrators to manage). Windows 11 has native support for DoH in its network settings.

DNS over QUIC (DoQ) runs DNS over the QUIC transport protocol on UDP port 853. It is the newest of the three and offers lower latency than DoT due to QUIC’s connection establishment efficiency.

For a network-level deployment behind pfSense, DoT is the right choice. pfSense’s built-in Unbound resolver has native support for it, it uses a dedicated port that is easy to control, and every major DNS provider supports it.

Quad9: Protective DNS That Does Not Cost a Dime#

Quad9 is a free, nonprofit DNS service operated by the Quad9 Foundation based in Switzerland. Their primary addresses are 9.9.9.9 and 149.112.112.112. What makes Quad9 particularly compelling for security-conscious deployments is that their default service includes built-in threat intelligence blocking.

When your network resolves a domain through Quad9, the query is checked against aggregated threat intelligence from over 25 security industry partners. If the domain is associated with malware, phishing, command-and-control infrastructure, or other malicious activity, Quad9 refuses to resolve it. The connection never starts. The malware never phones home. The phishing page never loads.

Quad9 also performs DNSSEC validation on every query by default. DNSSEC adds digital signatures to DNS records, allowing resolvers to verify that the response has not been tampered with in transit. This protects against cache poisoning and response forgery attacks.

Quad9 supports DoT on port 853 with the TLS hostname dns.quad9.net, DoH at https://dns.quad9.net/dns-query, and DNSCrypt. They do not log personally identifiable information, do not sell data, and operate under Swiss privacy law.

For an MSP or small business environment, Quad9 delivers enterprise-grade protective DNS at zero cost.

Configuring pfSense 2.8.1 for NIST-Compliant Encrypted DNS#

The following walkthrough configures pfSense 2.8.1 as a local DNS forwarder that sends all upstream queries to Quad9 over DNS over TLS. This is the architecture recommended by NIST SP 800-81r3 Section 2.1 and illustrated in Figure 1 of the document: a local enterprise recursive service forwarding encrypted queries to a cloud-based protective DNS provider.

Step 1: Configure Upstream DNS Servers#

Navigate to System > General Setup. Under DNS Server Settings, remove all existing entries and add:

AddressHostnameGateway
9.9.9.9dns.quad9.netYour WAN gateway
149.112.112.112dns.quad9.netYour WAN gateway

The hostname field is critical. It allows Unbound to validate the TLS certificate presented by Quad9, confirming that the server responding is genuinely Quad9 and not a man-in-the-middle. Without this, the connection is encrypted but unauthenticated.

If your ISP has provided you with an IPv6 gateway, you can add Quad9’s IPv6 addresses (2620:fe::fe and 2620:fe::9) with the IPv6 gateway. If you only have an IPv4 static IP and no IPv6 gateway, do not add IPv6 DNS entries. Doing so will cause intermittent resolution failures.

Uncheck “Allow DNS server list to be overridden by DHCP/PPP on WAN.” This prevents your ISP’s DNS servers from being injected into pfSense. ISP-provided DNS servers do not support DoT, are not protective DNS, and would send your queries in plaintext.

Set DNS Resolution Behavior to “Use local DNS (127.0.0.1), ignore remote DNS Servers.” This forces pfSense itself to use Unbound for all DNS queries. The “ignore remote” part is key – it prevents pfSense from falling back to plaintext DNS on port 53 if Unbound is momentarily unavailable. Without this setting, a brief Unbound restart would leak unencrypted queries on the WAN.

Click Save.

Step 2: Configure the DNS Resolver#

Navigate to Services > DNS Resolver. Configure the following:

  • Enable DNS Resolver: Checked
  • Network Interfaces: Select your LAN interface(s) and Localhost
  • Outgoing Network Interfaces: WAN
  • Enable DNSSEC Support: Unchecked

That last one catches people off guard. When Unbound is in forwarding mode, it sends queries to an upstream resolver rather than walking the DNS hierarchy itself. DNSSEC validation in forwarding mode is problematic because Unbound does not have direct access to the full chain of trust. Quad9 handles DNSSEC validation on every query by default, so this is already covered upstream.

  • Enable Forwarding Mode: Checked
  • Use SSL/TLS for outgoing DNS Queries to Forwarding Servers: Checked

This is the setting that enables DNS over TLS. Unbound will now send all forwarded queries to the upstream servers on TCP port 853 using TLS, with the dns.quad9.net hostname for certificate validation.

Ensure the DNS Forwarder (dnsmasq) is disabled under Services > DNS Forwarder. Only one service can bind to port 53.

Click Save, then Apply Changes.

Step 3: Lock Down DNS at the Firewall#

This is where NIST SP 800-81r3 Section 4.2.2 compliance happens. The goal is to ensure that every DNS query from every device on your network goes through pfSense and nowhere else.

Navigate to Firewall > Rules > LAN. Create the following rules in this exact order (rule order matters – pfSense evaluates top-down, first match wins):

Rule 1 – Allow DNS to pfSense:

  • Action: Pass
  • Protocol: TCP/UDP
  • Source: LAN subnets
  • Destination: LAN address (pfSense’s LAN IP)
  • Destination Port: 53 (DNS)
  • Log: Enabled
  • Description: Allow DNS to pfSense

This ensures LAN clients can query pfSense for DNS resolution.

Rule 2 – Block External DNS:

  • Action: Block
  • Protocol: TCP/UDP
  • Source: LAN subnets
  • Destination: Any
  • Destination Port: 53 (DNS)
  • Log: Enabled
  • Description: Block external DNS port 53

Any device attempting to reach an external DNS server on port 53 will be blocked. This catches malware with hardcoded DNS, IoT devices that ignore DHCP-assigned DNS (Google Nest, Roku, and many smart TVs hardcode 8.8.8.8), and misconfigured workstations.

Rule 3 – Block External DoT/DoQ:

  • Action: Block
  • Protocol: TCP/UDP
  • Source: LAN subnets
  • Destination: Any
  • Destination Port: 853
  • Log: Enabled
  • Description: Block outbound DoT/DoQ

This prevents devices or applications from establishing their own encrypted DNS tunnels to external resolvers, bypassing your protective DNS entirely. Some browsers (notably Firefox) ship with DoH enabled by default to Cloudflare, which would completely bypass pfSense’s filtering.

These three rules must appear above the default “Allow LAN to any” rule. If the allow-all rule is above the block rules, it matches first and the blocks never fire.

Enable logging on all three rules. Rule 1 gives you visibility into which clients are making DNS queries. Rules 2 and 3 give you alerts when something on your network is trying to bypass your DNS infrastructure – a high-value security signal.

Step 4: Configure DHCP#

Navigate to Services > DHCP Server for each LAN interface. Ensure the DNS Servers field is either blank (pfSense automatically pushes its own LAN IP) or explicitly set to the pfSense LAN IP. Do not list any external DNS servers.

All clients should receive only the pfSense LAN IP as their DNS server via DHCP. No Quad9 addresses, no Cloudflare addresses, no ISP addresses. Everything goes through pfSense, which forwards encrypted to Quad9.

Step 5: Verify the Configuration#

From a Windows workstation on the LAN, open PowerShell and run these tests:

Confirm DNS is working through pfSense:

Resolve-DnsName -Name example.com -Type A

The Server field in the response should show your pfSense LAN IP.

Confirm Quad9 DoT is the upstream path:

Resolve-DnsName -Type txt proto.on.quad9.net.

The NameHost field should return dot, confirming queries reach Quad9 over DNS over TLS.

Confirm protective DNS is active:

Resolve-DnsName -Name isitblocked.org -Type A

This should return NXDOMAIN or fail to resolve, confirming Quad9’s threat intelligence blocking is in the resolution path.

Confirm external DNS is blocked:

nslookup example.com 8.8.8.8

This must time out. If it returns a result, your firewall rules are not in the correct order.

Confirm external DoT is blocked:

Test-NetConnection -ComputerName 8.8.8.8 -Port 853

TcpTestSucceeded should return False.

Confirm DNSSEC validation:

Resolve-DnsName -Name sigfail.verteiltesysteme.net -Type A

This domain has an intentionally broken DNSSEC signature. Quad9 should refuse to resolve it, returning a SERVFAIL.

Resolve-DnsName -Name sigok.verteiltesysteme.net -Type A

This domain has a valid DNSSEC signature and should resolve normally.

From the pfSense GUI, navigate to Diagnostics > Packet Capture. Capture on the WAN interface, filter for UDP port 53, and generate DNS traffic from the LAN. You should see zero outbound packets on port 53. Repeat the capture for TCP port 853 – you should see TLS sessions to Quad9’s IP addresses.

Configuring an ISP-Provided Modem or Router for NIST-Compliant DNS#

Not every network has a pfSense box, a SonicWall, or any dedicated firewall. Small offices, home offices, and branch locations sometimes operate with nothing more than the modem or gateway that the ISP dropped off. If that describes your situation, you are not locked out of better DNS security. You cannot achieve full NIST SP 800-81r3 compliance with consumer-grade ISP equipment alone – the document explicitly recommends dedicated DNS servers, encrypted DNS, and firewall-level enforcement – but you can make significant improvements that move you in the right direction.

Here is how to get the most out of what you have.

Understand What You Are Working With#

ISP-provided devices generally fall into two categories: standalone modems (DOCSIS for cable, ONT for fiber) that only convert the ISP’s transport to Ethernet, and gateway combos that include a modem, router, firewall, DHCP server, DNS forwarder, Wi-Fi access point, and sometimes a phone adapter all in one box.

If you have a standalone modem, it does not handle DNS at all. Your computers, phones, and other devices are either getting DNS from a separate router or using whatever is configured on the device itself. If you have a gateway combo, it almost certainly has a built-in DNS forwarder that your devices use by default via DHCP.

The problem with the gateway’s DNS forwarder is that it sends all queries upstream to the ISP’s DNS servers in plaintext over port 53. The ISP’s DNS servers provide no threat intelligence blocking, no DNSSEC validation, and no encryption. Your ISP can see every domain every device on your network resolves. Some ISPs actively intercept and redirect DNS queries for their own purposes, including injecting ads into failed lookups or redirecting traffic through monitoring infrastructure.

Step 1: Change the Gateway’s Upstream DNS to Quad9#

Log into the gateway’s admin interface. This is typically accessible at 192.168.1.1, 192.168.0.1, or 10.0.0.1 – check the label on the device. The default credentials are usually printed on the device as well (change them while you are in there).

Find the DNS settings. These are often under WAN settings, Internet settings, or a dedicated DNS page. Replace whatever DNS servers are configured (usually the ISP’s own servers, auto-populated via DHCP from the ISP) with Quad9:

  • Primary DNS: 9.9.9.9
  • Secondary DNS: 149.112.112.112

Save the settings. This single change means every device on your network that uses the gateway for DNS (which is every device that gets its settings via DHCP) now has its queries forwarded to Quad9 instead of the ISP. Quad9 provides threat intelligence blocking and DNSSEC validation on every query. This is not encrypted DNS – the gateway is still forwarding on port 53 in plaintext – but the upstream resolver is now performing protective DNS functions that the ISP’s servers do not.

This is the single highest-impact change you can make on an ISP gateway. It takes two minutes and immediately provides protective DNS coverage for the entire network.

Step 2: Configure Individual Devices for Encrypted DNS#

The ISP gateway cannot encrypt DNS upstream, but your individual devices can. Windows 11, macOS, iOS, and Android all support DNS over HTTPS (DoH) or DNS over TLS (DoT) natively. By configuring this on each device, the DNS queries from that device are encrypted end-to-end between the device and Quad9, even though the gateway itself does not support encryption.

Windows 11:

Open Settings > Network & Internet > Wi-Fi (or Ethernet) > Hardware properties > Edit DNS settings. Switch from Automatic to Manual. Under IPv4:

  • Preferred DNS: 9.9.9.9
  • DNS over HTTPS: On (automatic template)
  • Alternate DNS: 149.112.112.112
  • DNS over HTTPS: On (automatic template)

Click Save. Verify by opening PowerShell and running:

Resolve-DnsName -Type txt proto.on.quad9.net.

The NameHost field should return doh, confirming queries are reaching Quad9 over encrypted HTTPS.

macOS (Big Sur and later):

Quad9 provides a configuration profile for macOS that enables DNS over HTTPS system-wide. Download the profile from the Quad9 documentation site, open it, and approve the installation in System Settings > Privacy & Security > Profiles. This configures the entire operating system to use Quad9 DoH without modifying individual network interface settings.

iOS (14 and later):

Same approach as macOS. Install the Quad9 DoH configuration profile from the Quad9 documentation site. Once installed, all DNS queries from the device are encrypted to Quad9, regardless of which Wi-Fi or cellular network the device is connected to.

Android (9 and later):

Navigate to Settings > Network & Internet > Private DNS. Select “Private DNS provider hostname” and enter dns.quad9.net. This enables DNS over TLS system-wide on the device.

Step 3: Disable the Gateway’s Built-In DNS Forwarder (If Possible)#

Some ISP gateways allow you to disable the built-in DNS forwarder or DHCP server. If you can disable the DHCP DNS assignment and instead configure each device individually with Quad9 DoH/DoT as described above, you eliminate the plaintext upstream forwarding from the gateway entirely.

However, this approach has a significant drawback: every new device that joins the network must be manually configured, and IoT devices, smart TVs, and other embedded devices often cannot be configured for DoH or DoT. They will either fail to resolve DNS or fall back to hardcoded servers like 8.8.8.8.

For most ISP gateway environments, the practical approach is to keep the gateway’s DHCP and DNS forwarder active with Quad9 as the upstream (Step 1), and layer encrypted DNS on top for devices that support it (Step 2). This gives you protective DNS for everything on the network via Quad9’s threat blocking, plus encrypted DNS for the devices that can handle it.

Step 4: Disable DNS Rebinding Protection Bypass and UPnP#

While you are in the gateway’s admin interface, look for and disable UPnP (Universal Plug and Play). UPnP allows devices on the network to automatically open ports on the router without administrator approval. Malware actively exploits this. Disable it.

Also look for any setting related to “DNS rebinding protection” and ensure it is enabled if available. DNS rebinding attacks trick a browser into making requests to internal network addresses by manipulating DNS responses. Not all ISP gateways expose this setting, but if yours does, enable it.

What This Configuration Achieves and What It Does Not#

With Quad9 configured as the upstream DNS on the gateway and DoH/DoT configured on individual devices, you have achieved the following NIST SP 800-81r3 recommendations:

  • Protective DNS (Section 2.1): Quad9’s threat intelligence blocking is active on all queries, whether forwarded by the gateway or sent directly by devices using DoH/DoT.
  • DNSSEC validation (Section 4.2.5): Quad9 validates DNSSEC on every query by default.
  • Encrypted DNS on supported devices (Section 4.2.1): Devices configured with DoH or DoT encrypt their queries end-to-end.

What you do not have:

  • Encrypted DNS for all traffic (Section 4.2.1): The gateway’s forwarding to Quad9 is still plaintext. Only individually configured devices get encryption.
  • Firewall-level DNS enforcement (Section 4.2.2): ISP gateways generally do not allow you to create firewall rules that block outbound port 53 or 853 to prevent DNS bypass. Devices with hardcoded DNS (IoT, smart TVs) can still reach external servers directly.
  • Centralized DNS logging (Section 2.1.3): ISP gateways do not provide DNS query logging for forensic or compliance purposes.
  • Separation of authoritative and recursive functions (Section 2.3.1): Not applicable on consumer equipment.

This is why NIST SP 800-81r3 recommends dedicated DNS infrastructure. The ISP gateway approach is a best-effort configuration for environments where a proper firewall is not yet deployed. If the network handles any business data, client information, or regulated workloads, the right move is to deploy a dedicated firewall – whether that is pfSense, OPNsense, or a commercial appliance – and implement the full encrypted DNS architecture described earlier in this article.

When to Upgrade#

If you find yourself managing an ISP-gateway-only network and any of the following are true, it is time to put a real firewall in front of it:

  • The network handles business or client data
  • Compliance requirements exist (HIPAA, PCI-DSS, CMMC, NIST 800-171)
  • More than five users or devices are on the network
  • IoT devices are present that cannot be configured for DoH/DoT
  • You need centralized DNS logging for incident response
  • You need to enforce DNS policy and prevent bypass

A pfSense box running on modest hardware with Quad9 DoT costs less than a few hours of incident response time. The economics are clear.

Tying It All Together#

When you step back and look at what these configurations achieve, the picture is compelling. On a pfSense network, every DNS query from every device flows through a single controlled resolver that encrypts every upstream query using TLS, checks it against real-time threat intelligence through Quad9, validates DNSSEC signatures, and logs everything for forensic and compliance purposes. Firewall rules prevent any device from bypassing this infrastructure.

On an ISP gateway network without a dedicated firewall, you can still get protective DNS and DNSSEC validation for every device by pointing the gateway at Quad9, and you can layer encrypted DNS on top for every device that supports DoH or DoT natively. It is not the full architecture that NIST envisions, but it is a dramatic improvement over the default configuration that most networks ship with.

The gap between those two configurations is the argument for deploying a real firewall. But regardless of where you are on that spectrum, the first step is the same: point your DNS at a protective resolver and start treating DNS as the security control it was always meant to be.

DNS is not just plumbing. It is the first and last line of defense on any network. Treat it accordingly.

This article references NIST Special Publication 800-81r3: Secure Domain Name System (DNS) Deployment Guide, published March 2026. The full document is available at https://doi.org/10.6028/NIST.SP.800-81r3.