no offense intended, but I think this is a goal which becomes more and more unrealistic.
Ironically, the IT security scene itself has worked towards making this impossible, since technologies such as DNS over TLS/HTTPS, encrypted SNI, and in a way HTTPS are a double-edged sword: On the one hand, they are great for keeping things confidential and improving everyone’s privacy, on the other hand, they make it harder and harder for IT security departments to filter traffic in a centralised manner.
Any DNS-based security mechanism that tampers with DNS responses breaks DNSSEC on systems using it (since the DNSSEC signatures no longer match the actual DNS reply, which has been altered by the service). This is bad, especially because DNSSEC validation errors are usually security-relevant. If they are caused en masse due to a filtering DNS service, it makes spotting any actual attacks rather difficult.
Also, “blocking clients from using other DNS service providers” does not work well anymore: With DNS over HTTPS (DoH), there is a technology available that has been designed to make it hard to spot, and even harder to block. With popular operating systems (such as Windows 11) and applications (such as Firefox in some parts of the world) using DoH, it does not really come as a surprise that malware starts using it as well.
From a firewall perspective, all you see is a TLS connection being established to an IP address on port 443. There is no way of telling whether its HTTPS or DoH. - Bummer, but that’s the beast we (as the IT security scene) summoned.
This means the filtering does not happen on a centralised entity, but locally on every IPFire system. While it still introduces lies to the DNS, it is a bit better since IPFire at least can validate DNSSEC beforehand - however, clients behind IPFire will experience DNSSEC validation errors, if they validate DNSSEC as well (which is desirable from a security perspective).
The differences between DNS-based filtering and a proxy are:
- DNS is application-agnostic, hence not limited to certain protocols such as HTTP(S).
- DNS filtering is transparent to the client, whereas when using a (non-transparent) web proxy the client knows it talks to a piece of software that can filter the traffic. The latter makes things more easy to debug and troubleshoot.
- A web proxy has more detailed insight than a DNS resolver, at least on protocols it handles. Additional information such as the client’s user-agent are available as well as additional authentication methods.
- From a puristic perspective, DNS-based filtering means tampering with a protocol. Web proxies do not have to do that, since they can operate fully RFC-/standard-conformant.
Indeed, it is not, and it was not intended to be one.
As you probably read between the lines, I am not really a fan of DNS-based filtering. But given our current situation, where no accurate blocklist source is available, it does not really matter which protocol we favour for filtering. First of all, we need to find blocklists that are accurate, free and usable for IPFire - the best filtering technique is useless if there is no information on what to block and what to permit.
Thanks, and best regards,