Every time you open a browser, send an email, stream a video, or check the weather on your phone, something happens before nearly 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 remains one of the most critical pieces of infrastructure on any network.

DNS is not just plumbing. It is the first step in nearly every modern connection. It is also one of the most powerful and underused security controls available to network administrators. If you are not thinking about DNS as a security boundary, you are leaving a major 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 current best practices, 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” 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 such as SPF, DKIM, and DMARC, certificate validation paths, 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 or some other name resolution process. Before malware can phone home to a command-and-control server, it usually has to resolve that server’s 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 connection attempts before they fully establish. This is the idea behind protective DNS: a DNS service enhanced with security capabilities to analyze queries and block threats in real time.

Protective DNS can block access to known malicious domains before a connection ever starts. It can filter categories of content that violate policy. It can generate logs that are invaluable for incident response and forensics. And it can do this at scale across every device on the network without installing agents or modifying endpoints.

A single infrastructure change at the DNS layer can protect workstations, servers, phones, tablets, IoT devices, printers, and cameras without touching each device individually.

The Problem with Traditional DNS#

Traditional DNS has a critical flaw: in its legacy form, it is unencrypted. Queries sent over classic DNS on port 53 can be read or tampered with by anyone positioned between your device and the resolver. That includes an ISP, a hostile actor on a compromised segment, or a rogue access point on an untrusted network.

This is not theoretical. DNS hijacking, cache poisoning, and man-in-the-middle attacks against DNS are well documented and actively exploited. Even if the website you visit uses HTTPS, the DNS query happens first.

That is why encrypted DNS matters. DNS over TLS, DNS over HTTPS, and DNS over QUIC help prevent observers from reading or modifying your DNS lookups in transit.

But this is where many discussions stop too early.

Encrypted DNS Helps, but It Does Not Make Browsing Fully Private#

A lot of people assume that once DNS is encrypted, their ISP can no longer tell which websites they visit. That is not entirely true.

Encrypted DNS hides the DNS query itself, which is a major improvement. But after DNS resolution, your browser still has to connect to the destination server and begin a TLS session. In most cases, the hostname is exposed in the TLS ClientHello through a field called Server Name Indication (SNI).

That means an ISP or anyone on the wire may not see the DNS request, but they can still often infer or directly read the destination hostname during the TLS handshake.

This is an important correction because people often describe this as something visible in the “server hello” packet. In practice, the hostname is usually exposed by the client, not the server. The leak is normally in the ClientHello SNI, not the ServerHello.

Even beyond SNI, an observer can still learn quite a bit from:

  • the destination IP address
  • the TLS certificate presented by the site
  • traffic timing and size patterns
  • known CDN or cloud provider IP mappings

So encrypted DNS is absolutely worth deploying, but it does not fully hide where users are going.

ECH Changes the Privacy Conversation#

There is an important development here: Encrypted Client Hello (ECH).

ECH is designed to encrypt the sensitive parts of the TLS ClientHello, including the real hostname that would otherwise be exposed through SNI. When ECH is supported by the browser, the operating environment, and the destination service or CDN, it significantly reduces one of the biggest metadata leaks left in modern HTTPS.

That is a big deal.

Without ECH:

  • DNS can be encrypted
  • the site content can be encrypted
  • but the hostname may still be visible in the TLS ClientHello

With ECH:

  • the DNS lookup can be encrypted
  • the site content is encrypted
  • and the real hostname in the ClientHello can also be concealed

That said, ECH is not universal. Support depends on the browser, resolver behavior, and whether the destination infrastructure actually publishes and supports it. So while ECH materially improves privacy, it is not yet something you can assume is protecting all traffic all the time.

Encrypted DNS: DoT, DoH, and DoQ#

Three major protocols exist to encrypt DNS traffic.

DNS over TLS (DoT) wraps DNS queries inside TLS on TCP port 853. It is mature, clean, and broadly supported by infrastructure platforms such as pfSense.

DNS over HTTPS (DoH) sends DNS traffic over standard HTTPS on port 443. That makes it blend into ordinary web traffic and gives it broad endpoint support, including native support on many modern operating systems and browsers.

DNS over QUIC (DoQ) runs DNS over QUIC and offers lower-latency connection behavior in some cases. It is newer and less widely deployed, but it is technically strong.

For a network-level deployment behind pfSense, DoT is often the most straightforward choice because of its supportability, firewall visibility, and mature implementation in Unbound.

Quad9: Protective DNS with Real Security Value#

Quad9 is a strong option for security-conscious environments. Its primary addresses are 9.9.9.9 and 149.112.112.112, and its default service includes threat blocking backed by aggregated intelligence feeds.

When your network resolves a domain through Quad9, that query can be checked against malicious-domain intelligence. If the domain is associated with malware, phishing, or known command-and-control infrastructure, the resolver can refuse to resolve it. The connection never starts.

Quad9 also performs DNSSEC validation by default, helping protect against tampering and forged DNS responses.

For small business, branch office, or MSP-managed deployments, that delivers a meaningful layer of protective DNS without licensing overhead.

Configuring pfSense for Encrypted and Controlled DNS#

The right design remains the same: use pfSense as the local resolver and forward upstream queries to a trusted provider such as Quad9 over DNS over TLS.

That gives you:

  • a single internal DNS control point
  • encrypted upstream resolution
  • malicious-domain blocking
  • DNSSEC validation upstream
  • enforceable firewall policy to prevent bypass

The pfSense workflow is still sound:

  1. Configure upstream DNS servers under System > General Setup
  2. Use the provider hostname for TLS certificate validation
  3. Disable ISP DNS override from WAN
  4. Set pfSense to use its local resolver
  5. Enable DNS Resolver with forwarding mode
  6. Enable SSL/TLS for outgoing DNS queries
  7. Disable any competing DNS forwarder service
  8. Enforce DNS policy with LAN firewall rules

The firewall enforcement piece is what makes the design operationally strong. If clients can still send DNS or DoH/DoT directly to the internet, they can bypass your protective controls.

Why Firewall Enforcement Still Matters#

If you want DNS to act as a genuine security control, you have to enforce it.

That means:

  • clients should use pfSense as their DNS server
  • outbound port 53 to the internet should be blocked from LAN clients
  • outbound port 853 should be blocked unless explicitly required
  • browser-level or application-level DNS bypass should be monitored and controlled where practical

This is especially important because some devices hardcode external DNS, and some applications try to establish their own encrypted DNS sessions to third-party resolvers.

If your security model depends on policy enforcement, logging, and threat blocking, those bypass paths matter.

ISP-Provided Routers: Better Than Default, but Still Limited#

If you only have an ISP-provided modem/router, you can still improve things.

The best first move is to point the router’s upstream DNS to a protective resolver such as Quad9 instead of the ISP’s default resolver. That gives you better threat filtering and DNSSEC validation immediately.

The next step is to enable encrypted DNS directly on endpoints that support it:

  • Windows 11 with DoH
  • macOS with a trusted encrypted DNS profile
  • iOS with a trusted encrypted DNS profile
  • Android Private DNS using dns.quad9.net

That improves privacy per device, but it is still not the same as a properly enforced firewall design. Consumer gateways usually cannot block all DNS bypass methods, cannot log centrally, and cannot enforce consistent policy across every client and IoT device.

The Privacy Reality Most People Miss#

Here is the bottom line.

Encrypted DNS protects the DNS query. HTTPS protects the web content. ECH can protect the hostname in the TLS ClientHello when it is supported. All of those are important, and all of them should be used where possible.

But none of that guarantees complete privacy from the ISP or another observer on the path. The destination IP is still visible. Traffic analysis still exists. ECH is not universal. Certificates and infrastructure patterns can still reveal a lot.

So if the goal is not just better DNS security but practical privacy from the ISP regarding where traffic is going, the most effective mainstream option is still to tunnel your traffic through a trusted VPN. That does not make you invisible, and it does not eliminate trust concerns, but it does move website visibility away from the ISP and onto the VPN provider.

That is the real distinction:

  • Encrypted DNS improves lookup privacy and integrity
  • HTTPS protects content
  • ECH helps hide the requested hostname when supported
  • A VPN is the most practical way to stop the ISP from directly seeing the destinations of your internet traffic in everyday use

Tying It All Together#

DNS remains one of the highest-value security controls you can deploy. It is foundational, centralized, and effective.

On a properly configured pfSense network, every client uses a single controlled resolver, upstream queries are encrypted, known malicious domains are blocked, and firewall policy prevents bypass.

On an ISP gateway network, you can still make meaningful gains by switching to a protective resolver and enabling encrypted DNS on devices that support it, even if you cannot achieve full enforcement.

Just be clear-eyed about what each control does.

Encrypted DNS is worth deploying. Protective DNS is worth deploying. ECH is a major improvement. But if your definition of “private internet” is that your ISP cannot directly see what websites you are connecting to, then in practical day-to-day use, a VPN is still the main tool that gets you there.

DNS is not just plumbing. It is a control plane, a choke point, and one of the most powerful defensive layers in any network. Treat it that way.