DNS: The Invisible Backbone of Your Network and Why Securing It Changes Everything

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 is still one of the most critical pieces of infrastructure on any network.

DNS is not just plumbing. It is the first thing that happens in nearly every modern 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.

But there is another reason DNS matters now, and it is one that a lot of people misunderstand. Many users have heard about encrypted DNS and assume that once they enable DNS over HTTPS or DNS over TLS, their ISP can no longer tell what websites they are visiting. That is only partially true. Encrypted DNS hides the DNS lookup itself, which is absolutely worth doing, but it does not automatically hide the destination of the connection from the ISP. In many cases, the hostname can still be exposed elsewhere in the TLS handshake, and even when that is reduced, the destination IP address is still visible.

This article covers four things: why DNS matters far more than most people realize, how to configure pfSense to use encrypted DNS aligned with current best practices, 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, and what encrypted DNS does and does not do for privacy on the modern internet.

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 web destinations, mail routing information, service discovery records, authentication policies for email such as SPF, DKIM, and DMARC, certificate validation dependencies, 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. Software updates fail. Mobile applications hang on splash screens. DNS is not just important. It is mission-critical infrastructure.

That is why DNS deserves to be treated like core network infrastructure instead of an afterthought.

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 another form of name resolution. 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 exfiltration over DNS tunneling can happen, 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 the connection fully establishes. This is the concept behind 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 starts. It can filter categories of content that violate organizational policies. It can generate query logs that are invaluable for incident response and forensic investigation. It can surface compromised hosts trying to reach suspicious domains long before endpoint protection throws an alert.

And it does all of this at scale, across every device on the network, without installing agents or modifying endpoints.

Think about that for a second. A single infrastructure change at the DNS layer can improve security for workstations, servers, phones, tablets, IoT devices, printers, cameras, and guest devices without touching any of them individually. There are not many controls in networking that give you that kind of leverage.

The Problem with Traditional DNS#

Traditional DNS has a critical flaw: in its original form, it is unencrypted. Classic DNS queries are typically sent over UDP port 53, and sometimes TCP port 53, in plaintext. Anyone positioned between your device and the DNS server can read those queries and tamper with the responses. That could be your ISP, a hostile actor on a compromised network segment, a rogue access point, or any middlebox sitting in the path.

This is not a theoretical risk. DNS hijacking, response forgery, cache poisoning, and man-in-the-middle manipulation of DNS have all been well documented for years. Even when the site you ultimately visit uses HTTPS, the DNS resolution step happens before that encrypted session is established.

That means if your DNS is plaintext, the domain lookup itself is exposed. For many users, that alone is enough to reveal a great deal about browsing habits, software usage, cloud services, and business activity.

This is why encrypted DNS matters.

Encrypted DNS: DoT, DoH, and DoQ#

Three major protocols are used to encrypt DNS traffic today.

DNS over TLS (DoT) wraps DNS queries inside a TLS session on TCP port 853. It is mature, well understood, and widely supported by infrastructure platforms, including pfSense through Unbound. Because it uses a dedicated port, it is relatively easy to allow, deny, monitor, and troubleshoot with firewall rules.

DNS over HTTPS (DoH) sends DNS queries over standard HTTPS on TCP port 443. This makes DNS traffic harder to distinguish from ordinary web traffic. That can be an advantage from a privacy perspective, but it also makes it harder for administrators to manage and control because it blends into normal HTTPS. Modern browsers and operating systems support DoH natively.

DNS over QUIC (DoQ) runs DNS over QUIC, generally using UDP port 853. It is newer and can reduce latency in some cases due to QUIC’s transport behavior, but it is still less common in enterprise and SMB infrastructure than DoT or DoH.

For a network-level deployment behind pfSense, DoT is often the best fit. pfSense’s built-in Unbound resolver supports it cleanly, the dedicated port simplifies policy enforcement, and major DNS providers support it.

What Encrypted DNS Actually Fixes#

Encrypted DNS solves a real problem. It prevents anyone on the path from reading or modifying the DNS query itself. That means your ISP can no longer see the exact plaintext DNS names your device is asking the resolver to translate. It also makes response tampering more difficult because the session to the resolver is protected.

That is important. It protects confidentiality and integrity for the name-resolution step.

But this is where a lot of discussions become misleading.

Encrypted DNS does not automatically make the rest of your internet activity private.

Once the DNS query is complete, your browser or application still has to connect to the destination server. That connection usually begins with a TLS handshake. In traditional TLS, the client often sends the target hostname in the ClientHello message using Server Name Indication (SNI). That is what lets a shared server or CDN know which site the client is trying to reach.

That means even if your DNS lookup is encrypted with DoT or DoH, an observer may still be able to see the hostname later in the TLS handshake.

This is one of the most commonly misunderstood parts of modern internet privacy.

The TLS Handshake Detail Most People Get Wrong#

A lot of people describe this as something visible in the “server hello packet.” That is not usually correct.

The hostname is generally exposed in the TLS ClientHello, not the ServerHello.

That distinction matters because it explains where the privacy leak really lives.

Here is the sequence in simplified form:

1. Your device resolves the domain name using DNS
2. Your browser opens a TCP or QUIC connection to the destination IP
3. Your browser sends a ClientHello
4. In many cases, that ClientHello includes SNI, which identifies the hostname being requested
5. The server replies with a ServerHello
6. Certificate exchange and session establishment follow

So if someone on the wire is trying to learn where you are going, the hostname is often visible because the client announces it. The server is not usually the packet that gives the site name away. The ClientHello SNI is.

That means a user can encrypt DNS and still expose the destination hostname in TLS metadata unless additional protections are in place.

The Certificate Problem and Other Metadata Leaks#

Even if you deal with DNS and even if SNI becomes less visible, metadata leakage does not disappear completely.

An observer can still often infer or identify websites using:

• the destination IP address
• the TLS certificate presented by the server
• certificate Subject Alternative Names in some cases
• traffic size and timing patterns
• HTTP/2 and HTTP/3 behavior
• known IP allocations for major CDNs and cloud providers

This is especially true for sites hosted on unique infrastructure or for services with easily identifiable IP ranges.

So the privacy picture is more nuanced than “turn on DoH and your ISP can no longer tell what site you visited.” That is not how it works in practice.

ECH: The Fix for the SNI Problem#

There is, however, 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. This is a major step forward because SNI has been one of the biggest remaining metadata leaks in otherwise encrypted web traffic.

Without ECH, the flow often looks like this:

• DNS query may be encrypted
• website content is encrypted with HTTPS
• but the hostname may still be visible in the TLS ClientHello through SNI

With ECH, the flow improves:

• DNS query can be encrypted
• website content is encrypted
• the real hostname inside the ClientHello can also be concealed

That is a meaningful improvement in privacy.

But there is an important caveat: ECH is not universal. It depends on browser support, platform behavior, resolver interactions, and whether the destination service or CDN actually supports it. Some traffic will benefit from it. Some will not. You cannot assume every connection on the public internet is protected by ECH.

So ECH reduces an important metadata leak, but it does not eliminate all observable information.

Why This Matters for Security Practitioners#

For security practitioners, this distinction matters for two reasons.

First, it helps you explain encrypted DNS accurately to users and stakeholders. DoH and DoT are valuable. They protect the DNS layer. But they are not a magic invisibility switch.

Second, it affects how you design controls. If your objective is DNS security, protective DNS plus encryption is a strong and worthwhile architecture. If your objective is true privacy from the ISP or from observers on the wire, you have to think beyond DNS and look at the whole connection path.

These are related goals, but they are not identical.

Quad9: Protective DNS That Delivers Real Value#

Quad9 remains one of the most compelling choices for security-conscious deployments. Its primary addresses are 9.9.9.9 and 149.112.112.112, and its default service includes threat intelligence blocking.

When your network resolves a domain through Quad9, the query can be checked against malicious-domain intelligence aggregated from multiple security sources. If the domain is associated with malware, phishing, botnet infrastructure, or other known malicious activity, Quad9 can refuse to resolve it. The connection never starts. The malware does not phone home. The phishing page does not load.

Quad9 also performs DNSSEC validation by default. DNSSEC uses digital signatures to help verify that DNS answers have not been tampered with in transit. That adds another layer of integrity protection.

Quad9 supports DoT, DoH, and other secure resolution methods. For MSP environments, small businesses, branch offices, and home labs, it provides meaningful protective DNS capabilities without direct cost.

Configuring pfSense 2.8.1 for Encrypted and Controlled DNS#

The following design configures pfSense as a local DNS resolver and forwarder that sends all upstream queries to Quad9 over DNS over TLS. The goal is straightforward:

• all clients use pfSense for DNS
• pfSense handles local resolution and forwarding
• upstream queries are encrypted
• malicious domains are blocked upstream by Quad9
• clients are prevented from bypassing your DNS infrastructure

This is the architecture you want if you care about both control and supportability.

Step 1: Configure Upstream DNS Servers#

Navigate to System > General Setup.

Under DNS Server Settings, remove existing entries and add the following:

If you have working IPv6 and an IPv6 gateway, you can also add:

The hostname field matters. It allows pfSense and Unbound to validate the TLS certificate presented by the upstream provider. Without that, you might have encryption, but you do not have proper identity validation of the remote resolver.

Uncheck Allow DNS server list to be overridden by DHCP/PPP on WAN. This prevents the ISP from injecting its own DNS servers into your firewall configuration.

Set DNS Resolution Behavior to Use local DNS (127.0.0.1), ignore remote DNS Servers. That ensures pfSense itself uses the local resolver and does not fall back to plaintext remote resolvers if Unbound is briefly unavailable.

Click Save.

Step 2: Configure the DNS Resolver#

Navigate to Services > DNS Resolver.

Set the following:

• Enable DNS Resolver: Checked
• Network Interfaces: Select LAN interface(s) and Localhost
• Outgoing Network Interfaces: WAN
• Enable Forwarding Mode: Checked
• Use SSL/TLS for outgoing DNS Queries to Forwarding Servers: Checked

In a forwarding design, Quad9 handles the upstream recursive work and DNSSEC validation. That means you generally do not need pfSense doing full recursive traversal itself for this architecture.

Make sure DNS Forwarder under Services > DNS Forwarder is disabled so only one service is binding to port 53.

Click Save, then Apply Changes.

Step 3: Lock Down DNS at the Firewall#

This is where the design becomes enforceable rather than merely advisory.

Navigate to Firewall > Rules > LAN and create rules in this order.

Rule 1: Allow DNS to pfSense#

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

Rule 2: Block External DNS#

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

This catches devices trying to query public resolvers directly.

Rule 3: Block External DoT and DoQ#

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

This prevents clients from standing up their own encrypted DNS sessions to external providers and bypassing your local resolver.

These rules must sit above the general allow rule. Rule order matters in pfSense.

Step 4: Account for DoH Bypass#

Here is where things get more nuanced. Blocking port 53 and 853 is necessary, but it does not fully stop DNS bypass because DoH uses port 443, the same port as normal HTTPS.

That means clients and browsers can sometimes bypass your DNS controls by sending encrypted DNS to external providers over ordinary web traffic. This is not a pfSense weakness. It is how DoH is designed.

What you can do:

• manage browser settings through policy where possible
• disable application-managed secure DNS in browsers if your environment requires central DNS enforcement
• use endpoint management to standardize DNS behavior
• monitor outbound traffic to known public DoH providers if your environment justifies that level of control

This is one of the reasons a dedicated firewall plus endpoint management is more effective than relying on network controls alone.

Step 5: Configure DHCP#

Navigate to Services > DHCP Server for each LAN interface.

Ensure the DNS Servers field is blank or explicitly set to the pfSense LAN IP. Do not hand out external DNS servers to clients.

The model should be simple: every client sends DNS to pfSense, and pfSense securely forwards upstream to Quad9.

Step 6: Verify the Configuration#

From a Windows workstation on the LAN, run the following tests.

Confirm DNS is working through pfSense#

Resolve-DnsName -Name example.com -Type A

The server shown should be the pfSense LAN IP.

Confirm Quad9 DoT is the upstream path#

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

A response indicating dot confirms DNS over TLS to Quad9.

Confirm protective DNS is active#

Resolve-DnsName -Name isitblocked.org -Type A

This should fail or return a blocked response path, depending on the resolver behavior.

Confirm external DNS is blocked#

nslookup example.com 8.8.8.8

This should time out or fail.

Confirm external DoT is blocked#

Test-NetConnection -ComputerName 8.8.8.8 -Port 853

TcpTestSucceeded should be False.

Confirm packet behavior on pfSense#

Use Diagnostics > Packet Capture on the WAN interface.

• Capture outbound UDP port 53 traffic while generating name lookups from a LAN client
• You should see no plaintext DNS leaving the firewall
• Capture TCP port 853
• You should see encrypted sessions to Quad9

That is the validation that matters operationally.

Configuring an ISP-Provided Modem or Router When No Firewall Exists#

Not every network has pfSense, OPNsense, Fortinet, Palo Alto, or a proper edge appliance. Small offices, home offices, and temporary branch locations are often running off nothing more than the ISP gateway.

If that is your situation, you can still improve DNS security significantly. You just need to be honest about the limitations.

You will not get the same level of enforcement, logging, or consistency as you would with a real firewall. But you can absolutely do better than the out-of-the-box configuration most ISP routers ship with.

Step 1: Replace the ISP’s DNS with Quad9#

Log into the ISP router or gateway. This is commonly at 192.168.1.1, 192.168.0.1, or 10.0.0.1.

Find the DNS settings under WAN, Internet, or LAN/DHCP depending on the device and set:

• Primary DNS: 9.9.9.9
• Secondary DNS: 149.112.112.112

This change does two important things:

1. it stops the gateway from sending queries to the ISP’s default resolvers
2. it gives the entire network the benefit of Quad9’s protective DNS and DNSSEC validation

This does not mean the gateway is now doing encrypted DNS. Most ISP devices still forward upstream on plaintext port 53 unless they explicitly support DoH or DoT. But it is still a high-value improvement because the upstream resolver is now protective rather than passive.

Step 2: Enable Encrypted DNS on Individual Devices#

If the gateway cannot encrypt DNS upstream, your endpoints still can.

Windows 11#

Go to Settings > Network & Internet > Wi-Fi or Ethernet > Hardware properties > Edit DNS settings.

Set:

• Preferred DNS: 9.9.9.9
• Alternate DNS: 149.112.112.112
• Enable DNS over HTTPS if available for the resolver template

Validate in PowerShell:

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

A result indicating doh confirms DoH is in use.

Android#

Go to Settings > Network & Internet > Private DNS and set:

dns.quad9.net

That enables DoT for the device.

macOS and iOS#

Use a trusted encrypted DNS profile or native encrypted DNS settings, depending on OS version and management model.

This per-device approach improves privacy and integrity for supported devices, even if the router itself is still using plaintext upstream.

Step 3: Understand the Limitations#

This is where you need to be realistic.

With an ISP gateway, you typically do not get:

• firewall-level enforcement to block all external DNS
• good centralized DNS logging
• strong visibility into bypass attempts
• consistent handling for IoT devices and embedded clients
• full control over browser-based DoH usage
• strong segmentation or policy enforcement

That means this setup is better than default, but it is not equivalent to a dedicated firewall architecture.

Step 4: Disable Risky Defaults#

While you are in the ISP router, disable UPnP if it is enabled. UPnP allows internal devices to open ports automatically, and that is an unnecessary risk in most environments.

If the router offers DNS rebinding protection, leave it enabled.

Also change the admin password if the ISP shipped the unit with defaults or something printed on the label.

When It Is Time to Upgrade#

If any of the following are true, it is time to put a real firewall in front of the ISP gateway:

• the network handles business data
• compliance requirements exist
• you need logging for troubleshooting or investigations
• you have more than a handful of devices
• IoT devices are present
• you need policy enforcement
• you need to stop DNS bypass attempts in a supportable way

A basic pfSense appliance or equivalent costs far less than the operational pain of trying to retrofit enterprise control into an ISP gateway.

Privacy Expectations: What the ISP Can Still See#

Now we come back to the privacy question.

Let us say you have done everything right with DNS:

• you enabled DoT or DoH
• you chose a trusted resolver
• you prevented plaintext DNS
• maybe some of your traffic even uses ECH

What can the ISP still see?

At minimum, the ISP still sees:

• that you connected to a specific IP address
• when you connected
• how much data moved
• timing, duration, and flow patterns
• sometimes enough metadata to infer the service or site

If the traffic does not use ECH, the ISP may also see the destination hostname in the TLS ClientHello SNI.

If the site has unique infrastructure, the IP alone may effectively identify it.

So encrypted DNS is not fake. It solves a real problem. But it does not by itself create “private internet.”

Why a VPN Changes the Equation#

A VPN changes who can see your traffic destinations.

Without a VPN:

• your device talks directly to the destination service
• the ISP can see the destination IP
• depending on the handshake and site support, the ISP may infer or identify the destination hostname

With a VPN:

• your device establishes an encrypted tunnel to the VPN provider
• the ISP sees the VPN server IP
• the ISP no longer directly sees the individual websites and services you are connecting to beyond that tunnel

That is why, in practical everyday use, a VPN is the main tool for keeping your ISP from directly seeing what sites you visit.

This does not make the VPN magical. It shifts trust from the ISP to the VPN provider. If the VPN provider logs aggressively, monetizes traffic, or has poor security, you have simply changed who can see your activity. That is why provider trust still matters.

But in terms of the narrow question, “What keeps the ISP from directly seeing the sites I visit?” the answer is straightforward: a VPN is the practical answer.

The Real Distinction#

This is the cleanest way to think about the stack:

• Protective DNS blocks malicious destinations
• Encrypted DNS hides DNS lookups from observers
• HTTPS encrypts the content of web sessions
• ECH helps hide the requested hostname in the TLS ClientHello when supported
• A VPN hides your destination traffic from the ISP by tunneling it through another provider

Each control solves a different part of the problem.

The mistake is expecting one layer to do the job of all the others.

Tying It All Together#

When you step back and look at what these configurations achieve, the picture becomes clear.

On a pfSense network, every DNS query from every device can flow through a single controlled resolver that encrypts upstream DNS, uses protective filtering through Quad9, validates integrity, and gives you a point of enforcement. Firewall rules can prevent clients from using plaintext DNS and opportunistic encrypted DNS over port 853. Endpoint policy can reduce DoH bypass. That is a strong, supportable architecture.

On an ISP gateway network without a dedicated firewall, you can still improve things dramatically by switching to a protective resolver and enabling encrypted DNS on supported devices. It is not the same as full enforcement, but it is far better than the default state most consumer networks live in.

And on the privacy question, the answer is now much clearer than it used to be.

Encrypted DNS is worth deploying. ECH is a major improvement. HTTPS protects content. But if your goal is true practical privacy from your ISP regarding what websites you visit, the only mainstream way to get there consistently is to use a VPN.

DNS is not just plumbing. It is a control plane, a choke point, a visibility layer, and one of the highest-leverage defensive technologies 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.