The current problem with this method (blocking the DOH servers) is the following:
When searching GitHub for DOH repositories, you find a lot of lists, however, non of these lists appear to be complete, nor well maintained.
examples, not limited to these lists, there are many more, here (7 months old), here (updated a week ago, but incomplete) and here (15 months old).
As long as there isn’t an initiative to create a well maintained list of DOH servers, this is a fight, users will never win.
On reddit, there is a topic, discussing code, added to suricata, to detect, among other things, DOH connections. GitHub code here. This would be a far better solution, unfortunately, in order to get this into the pfsense suricata package, the code needs to find it’s way into the upstream release of suricata. This hasn’t happened yet, see here.
I think, making lists for DOT servers is pointless, simply block port 853. Blocking DOH is the challenge.
Another problem, using IP blocklists (example, used to explain the possible problem): you have, added 22.214.171.124 to your list. This server is considered a DOH server (this guy is trying to use it), however the server also responds to port 53 (normal DNS - dig @126.96.36.199 -p 53 google.com). When using unbound as a recursive resolver, unbound might be requesting data from this server, but the request will fail due to the IP blocking. Companies, willing to embrace DOH, may host their domain info on a DNS server that responds to both port 53 and DOH. Blocking that server may cause problems with DNS resolution.