For the various adblock techniques, based on DNS, to work for most/all clients, it is necessary to block DoH. In case, this is done on the router using firewall, any negative side effects noticed ?
I have chrome.cloudflare-dns.com blocked in Pi-hole for some time and didn't see any issues with that.
Good to know, thanx. But this does not block DoH directly for the IP. AFAIK, some apps on mobiles (can/will) do DoH directly to 1.1.1.1, for example. Thats the reason, to block using firewall on router.
I don't think so. AFAIK, that is the case for DoT, but not for DoH.
See How to configure https-dns-proxy to give the nearest DNS Resolvers? - #4 by AndrewZ
DoH might need to be blocked by IP.
have you seen https://openwrt.org/docs/guide-user/firewall/fw3_configurations/intercept_dns ?
which points to https://openwrt.org/docs/guide-user/services/banip#blocking_doh, it's using banIP, but you could simply create an IPset for the IPs (it's what banIP is doing, I'm guessing), and dnsmasq for the FQDNs.
1.1.1.1 might be bad example. However, I have seen DOH directly to 8.8.8.8 , from Android app. Was blocked on firewall, then.
Sorry, but my question was not how to do it, but whether neg side effects have shown up somewhere. Because there must be blocks of https:/8.8.8.8, for example. And blocks of https://1.1.1.1
Agree, with Google it is different. I doubt the app goes directly to the IP, so I would start from blocking dns.google name either in dnsmasq directly or in any adblock solution that is used.
You can use canary domains to turn clients away from doh
/etc/config/dhcp
...
config dnsmasq
...
list server '/use-application-dns.net/'
list server '/mask-h2.icloud.com/'
list server '/mask.icloud.com/'
1 Like
I used to block DoH using banIP.
When i visited a website i couldn't load video player on the website.
It turns out they share same IPs as one of the blocked DoHs.
So i whitelisted those IPs.
2 Likes
And that is why DNS based blocking is tricky in the age of CDNs and multiplexed to hell and back IP addresses 
I use banip to block DoH. The first time I ran into an issue was just some days ago when I couldn't access a cloudflare-hosted domain. I just whitelisted it (by domain).
2 Likes
I have blocking of DoH enabled via dns name lists and IP sets in firewall rules. I've had this setup stable for 3 (maybe 4?) years now...
Like @andyboeh, I have just one specific IP ban that I whitelist, as it's used for both a DoH host and an actual website of interest to me: 76.76.21.21
Some stats:
Fri Mar 14 03:07:17 2025 user.info update-doh[7915]: IPv4 block list contains 2523 entries, resulting set contains 2735 elements.
Fri Mar 14 03:07:32 2025 user.info update-doh[7915]: IPv6 block list contains 1812 entries, resulting set contains 1917 elements.
And counts on the rules for about a week of traffic:
meta l4proto { tcp, udp } th dport 443 ip daddr @doh_ipv4 counter packets 924 bytes 48048 update @doh_ipv4 { ip daddr } reject with icmp port-unreachable
meta l4proto { tcp, udp } th dport 443 ip6 daddr @doh_ipv6 counter packets 410 bytes 29520 update @doh_ipv6 { ip6 daddr } reject with icmpv6 port-unreachable
1 Like
The fact, that your firewall rules catch DoH traffic, despite your DNS name lists, might confirm, some apps are trying to use direct, IP-based DoH. Thus, there is some sense in doing IP based DoH block. Unfortunately, I noticed, that nft sets are terribly slow, compared to ipsets used in iptables. FYI, I am using iptables+ipsets to do DoH blockage, in table "raw". And nft rules, for all the rest. No issues, until now.
That's my assumption, too, although I've never gotten around to chasing down who is doing it. There are a handful of Windows boxes on our lan, most likely suspect is wife's laptop, although it could be some weird apps on her phone.
My whole refresh takes about 30 seconds each night at 0307 (the timestamps above show the finish time for the two set updates), so I've never even thought about a speed as an issue.
I was pointing at the speed for the lookup of the DoH IP in the respective NFT set, in your case it happens here: meta l4proto { tcp, udp } th dport 443 ip daddr @doh_ipv4 counter packets 924 bytes 48048 update @doh_ipv4 { ip daddr } reject with icmp port-unreachable
This rule to be checked for every packet. And this checking for an IP in the nft set is terribly slow. Its easy to do a simple benchmark just for this rule. Both for a hit and a miss, slowing down your traffic remarkably.