You’ve spent hours hardening your firewall rules, segmenting your VLANs, and ensuring every web service you run is behind a reverse proxy with a valid certificate. You feel secure. But here’s the uncomfortable truth we need to discuss over this virtual coffee: your ISP still knows exactly where you’re going. Every time you type a URL into your browser, your devices send out a plain-text request—a digital postcard—asking for the IP address of that domain. Even if the website itself is encrypted via HTTPS, the DNS request that got you there was likely shouted across the wire for any middleman to see, log, and potentially sell.

It’s a massive privacy hole that most practitioners overlook because “it just works.” We’ve been conditioned to accept port 53 as an immutable fact of networking. But in a modern threat landscape, leaving your DNS queries unencrypted is like locking your front door but leaving the blueprints to your house sitting on the curb. If you are running OPNsense, you have the professional-grade tools to shut this door permanently. We aren’t just changing a setting; we are re-architecting how your network communicates with the outside world.

Why Is My ISP Still Seeing My Traffic After I Changed DNS?

I see this mistake constantly in the field. A sysadmin switches their OPNsense “System: Settings: General” DNS servers to 1.1.1.1 or 9.9.9.9 and thinks the job is done. It isn’t. By default, those queries are still sent over UDP port 53. This means your ISP, or anyone sitting on the transit path, can use Deep Packet Inspection (DPI) to see that you are resolving `medical-specialist-site.com` or `crypto-exchange.io`.

The “Costly Trap” here is a false sense of anonymity. Changing the destination of your DNS doesn’t change the visibility of the transport. Furthermore, many modern “smart” devices (think TVs and cheap IoT cameras) are hardcoded to ignore your DHCP-assigned DNS settings. They will try to reach out to Google (8.8.8.8) or their manufacturer’s DNS directly. If you haven’t built a “No Escape” rule in your firewall, your privacy policy is essentially a suggestion that your devices are free to ignore.

DNS over TLS (DoT) solves this by wrapping the DNS query inside a TLS tunnel. It’s the same cryptographic security that protects your banking traffic, applied to the very first step of every connection you make. By using OPNsense’s native Unbound integration, we can centralize this encryption, so your individual devices don’t have to support DoT themselves—the firewall handles the heavy lifting.

How Do I Configure Unbound for DNS over TLS?

The beauty of OPNsense is that it uses Unbound as its core resolver. Unbound is a highly performant, security-focused recursive DNS server that supports DoT natively. To set this up correctly, we need to move away from the “Recursive” model (where OPNsense talks to the root servers itself) and move toward a “Forwarding” model (where OPNsense sends queries to a trusted, encrypted upstream provider).

Step 1: The Foundation in Unbound General Settings

Navigate to Services: Unbound DNS: General. First, ensure that “Enable Unbound” is checked. Under “Network Interfaces,” I recommend selecting “All” or specifically selecting your LAN and Trusted VLAN interfaces. Crucially, ensure “DNSSEC Support” is enabled. While DNSSEC doesn’t provide privacy, it ensures the data you receive hasn’t been tampered with.

Now, look for the “Query Forwarding” section. You must check “Enable Forwarding Mode.” Without this, Unbound will try to contact the root hints directly over port 53, bypassing our encryption goals entirely.

Step 2: Configuring the TLS Upstream Servers

Navigate to Services: Unbound DNS: DNS over TLS. This is where the magic happens. You aren’t just entering IP addresses; you are establishing a trust relationship. Click the “+” button to add a new server.

For a gold-standard privacy setup, I recommend Quad9. They are a non-profit based in Switzerland with excellent privacy protections.
– Server IP: 9.9.9.9
– Server Port: 853
– Verify CN: dns.quad9.net

The “Verify CN” (Common Name) field is vital. It prevents a “Man-in-the-Middle” attack where an attacker might intercept your port 853 traffic and present their own certificate. By specifying the hostname, OPNsense will only trust the connection if the certificate presented matches the one owned by Quad9. Repeat this process for their secondary IP (149.112.112.112) to ensure redundancy.

Step 3: Hardening the System Settings

Even with Unbound configured, OPNsense itself might try to use its system-level DNS for its own updates or plugin lookups. Go to System: Settings: General. Clear out any DNS servers listed there if you want OPNsense to use the local Unbound instance, or ensure that the “Do not use the local DNS service as a nameserver for this system” box is unchecked. Also, ensure “Allow DNS server list to be overridden by DHCP/PPP on WAN” is unchecked. We do not want your ISP pushing their DNS servers back onto your firewall.

The “No Escape” Playbook: Forcing Compliance

You’ve built the secure tunnel, but your devices are like teenagers—they’ll try to find a way around your rules if it’s easier. Many IoT devices have 8.8.8.8 hardcoded into their firmware. If you don’t stop them, they will simply bypass Unbound and send plain-text queries straight out your WAN.

We solve this with a NAT Port Forward rule. This is the “4:00 PM Resolution”—the final step that ensures your configuration is bulletproof before you log off for the day.

1. Navigate to Firewall: NAT: Port Forward.
2. Add a new rule:
– Interface: LAN (and any other internal VLANs).
– Protocol: TCP/UDP.
– Destination / Invert: Checked (This means “Any destination that is NOT…”).
– Destination: LAN address (The IP of your OPNsense gateway).
– Destination Port Range: 53 (DNS).
– Redirect Target IP: 127.0.0.1 (The local Unbound service).
– Redirect Target Port: 53.
– Description: Force Local DNS (No Escape).

This rule intercepts any packet destined for any DNS server on the internet and transparently redirects it to OPNsense’s local Unbound instance. Unbound then takes that plain-text query, wraps it in a TLS tunnel, and sends it out securely via port 853. Your devices think they talked to Google; in reality, they were secured by your firewall.

Verifying Your Privacy: Is It Actually Working?

Never trust a green checkmark in a UI without verifying the traffic. To confirm your setup is working, go to Interfaces: Diagnostics: Packet Capture. Select your WAN interface and set the port filter to 53. Start the capture and browse a few new websites on your computer. You should see zero traffic.

Next, change the port filter to 853. You should see a flurry of encrypted TCP traffic between your WAN IP and 9.9.9.9. This is the sound of privacy. If you see traffic on port 53, go back and check your “Forwarding Mode” in Unbound and your NAT redirection rules.

Finally, visit a site like dnsleaktest.com. Run the extended test. You should only see the IP addresses of your chosen DoT provider (Quad9, Cloudflare, etc.). If you see your ISP’s name anywhere in that list, you have a leak that needs to be plugged.

Frequently Asked Questions

Does DNS over TLS slow down my internet connection?
There is a negligible overhead during the initial TLS handshake (a few milliseconds). However, Unbound caches DNS responses locally. Once a domain is resolved and cached, subsequent requests from any device on your network are nearly instantaneous, often making your internet feel faster than using ISP defaults.

What happens if Quad9 or my DoT provider goes down?
If your only configured upstream servers are unreachable, DNS resolution will fail across your network. This is why it is critical to configure at least two different providers (e.g., Quad9 and Cloudflare) or multiple IPs from the same provider to ensure high availability.

Can I use DNS over HTTPS (DoH) in OPNsense instead?
While Unbound primarily focuses on DoT, you can implement DoH using the https-dns-proxy plugin or a specialized setup. However, for a firewall-level implementation, DoT is generally preferred as it is more efficient for a dedicated resolver and easier to monitor via port 853.