Introduction

This article is a slightly re-written version of the June 2022 version. It explains how DoH (DNS over https) can be blocked with OPNsense using FQDN (fully qualified domain name) lists which is an undocumented feature in OPNsense. Blocking DoH reliably is almost impossible without fully breaking up TLS and all encompassing deep packet packet inspection which is just not realistic for average home use setups. The approach below is therefore simple, efficient and capable of at least capturing a significant chunk of DoH traffic based on the assumption that the used DoH server blocklist contains the in practice most relevant DoH servers.

Why blocking DoH

Many IoT devices and mobile applications try to use 3rd party DNS servers to bypass local DNS servers for serving ads or sending usage data. This can easily be prevented by blocking outgoing DNS traffic from clients directly and only allow DNS resolution via a pi-hole or other privacy aware solution.

Recently some devices started "phoning home" by using DoH, therefore circumventing local DNS servers. This has a shady taste and that is reason enough to block it.

But how can DoH be blocked? The answer is that it can't really be blocked easily. Since DoH traffic from a Layer 3/4 firewall perspective is almost identical to legitimate https traffic it can't easily be distinguished from legitimate traffic without deeply inspecting every single network traffic packet. The latter might be feasible in a corporate enterprise setup but will be beyond the capabilities of most home use setups.

A pragmatic but still somewhat effective approach is to block well known DoH servers. While this may not catch advanced malware providing their own DoH servers it may still catch the majority of average IoT devices which want to bypass local DNS servers using DoH.

A static IP blocklist would not be ideal for this since the underlying IP addresses of DoH servers may change over time and one would have to keep track of this in near real-time to still have an effective IP based blocklist. Using a FQDN based list is a much more flexible approach to this challenge. Also many DoH servers are only provided as FQDN name lists.

FQDN blocklists with PF / OPNsense

While it is not officially stated in the OPNsense documentation the following statement in the OpenBSD PF documentation hints us at the fact that is indeed possible to use fqdn lists as input for PF rules.

src_addr, dst_addr
    The source/destination address in the IP header. Addresses can be specified as:

        A single IPv4 or IPv6 address.
        A CIDR network block.
        A fully qualified domain name that will be resolved via DNS when the ruleset is loaded. All resulting IP addresses will be substituted into the rule. 
...

Since OPNsense also uses PF it is as simple as creating a new firewall rule of the type URL Table (IPs) and provide the blocklist URL as the rule content.

DoH blocklist

For blocking of DoH the best list I was able to find so far is:

DoH blocklist with OPNsense by just using the URL Table (IPs) type for an alias in OPNsense.

Which is generated based on the by curl maintained DNS over http list

After creating a rule with the above list we can verify that it works in the Firewall -> Diagnostics -> Aliases section, where we see that the fqdns get resolved into IPs. The FQDNs get resolved into IP addresses everytime the list is loaded therefore the fetching frequency should be at least daily.

Result

With the provided DoH blocklist and the undocumented OPNsense feature of using FQDNs in firewall rules we now have a basic DoH blocking capabability established. While it is by its very nature not bulled proof it should still be able to capture average IoT devices trying to bypass the local DNS for phoning home or reaching out to adservers.