Block SecureDNS (DoH, DoT, DNSCrypt)

Some applications use a custom DNS to bypass DNS filters.
Blocking these is as simple as adding an IP-Tables rule to permit outgoing queries to port 53 (except Pi-hole). However, in the near future, I expect many applications to use DNS protocols, like DNS over HTTPS or DNS over TLS to serve ads.

Because I couldn’t find one I created a blacklist of SDNS servers. One block list containing IP addresses and another one containing SDNS domains.

I also created a (probably pretty ugly script, though it got fancy error handling) with which you can create and update those lists yourself.

https://github.com/Trigus42/Block-SecureDNS

What are typical applications that would use custom DNS (any examples?), and how do one add an IP-tables rule to block them? (Sorry for noob questions, trying to learn :slight_smile: )

At the moment there are few applications that use a custom DNS, especially encrypted DNS. However, altought I unfortunately don’t exactly remember which ones were using it, almost all browsers have implemented an SDNS solution which is not set by default yet, but in Chrome, for example it’s most likely going to be soon.

If you are able to set firewall rules on your router (which can also be your Raspberry) you can easily block ordinary DNS requests on Port 53 by simply blocking forwarding of those requests for all devices except your PiHole. The problem with DOH, DoT and DNS-Crypt in this case is that they are using Port 433 by default which is also the Port used by the HTTPS protocol.

To fully block those requests you would have to perform deep packet inspection, checking for encrypted DNS requests, for what you would need to install a custom certificate on every device in your network and have a pretty beefy router if you don’t want it to have a huge impact on your network speed, especially latency.

So the simplest solution I could think of was to block ordinary DNS requests using a simple iptables rule and block the domains of SDNS servers in PiHole.

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.

edit
Another problem, using IP blocklists (example, used to explain the possible problem): you have, added 1.0.0.1 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 @1.0.0.1 -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.
/edit