After installing DNSFilter on your network, it is also important to prevent users from bypassing your filter by setting custom DNS entries into their network devices. This article assists network administrators with blocking the most common methods.
Circumvention of content filtering can be prevented by:
- Denying users the ability to change network settings on their device.
- Creating firewall rules that force DNS traffic only to DNSFilter.
If these methods are not applied, users will be able to circumvent your content and security filtering by changing their DNS settings. The diagrams below show what traffic flow is like without and with firewall rules.
Implementing Firewall Rules
In order to prevent endusers from utilizing 3rd-party DNS servers, you can implement a compensating firewall rule in your network’s firewall which will transparently redirect any outbound DNS request to DNSFilter.
There are several ways to accomplish this, but the examples below are the simplest. Your firewall may offer additional options, such as destination-based round robin, that would allow you to enter multiple destinations and therefore load balance the two DNSFilter AnyCast IPs (184.108.40.206, 220.127.116.11).
You can implement a firewall rule via either the
iptables.conf file or shell commands:
*nat :PREROUTING ACCEPT [2:143] :INPUT ACCEPT [2:143] :OUTPUT ACCEPT [0:0]<br>:POSTROUTING ACCEPT [2:134] -A OUTPUT -p udp -m udp --dport 53 -j DNAT --to-destination 18.104.22.168:53 -A OUTPUT -p tcp -m tcp --dport 53 -j DNAT --to-destination 22.214.171.124:53
iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 126.96.36.199:53 iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 188.8.131.52:53
The pfSense section in our transparent proxying articles provides an explanation of how to create rules for DNSFilter.
Testing Firewall Rules
Below is the method for testing your firewall rules to ensure that users cannot circumvent the policies that you have set for DNSFilter.
- Add a domain to the policy Block list associated with your site.
- Perform an
dig(MacOS/Linux) to that site over DNSFilter’s Anycast IP addresses
nslookup YOURTESTSITE.com. 184.108.40.206 dig +short YOURTESTSITE.com. @220.127.116.11
- Copy the resulting IP address (in Windows
non-authoritative answer) for the domain into your browser and attempt to visit it, there should be a block page as below.
- Now, perform the same test, but using Google’s public DNS resolver:
nslookup YOURTESTSITE.com. 18.104.22.168 dig +short YOURTESTSITE.com. @22.214.171.124
If your firewall rule is set correctly, you should receive the same answer as the previous query. This is evidence that your firewall rule is operative and DNS queries are being sent to DNSFilter. This means users will be blocked according to policy, no matter what they have set on their device.
You may also want to look at our Addressing Conflicts article, which details devices/software that may conflict with DNSFilter’s operation.
DNS-over-HTTPS (DoH) is great, if all you can do is implement encryption at the browser level. The preferred solution is DNS-over-TLS, which covers the entire OS (not just browser traffic). We support DoT in all our Roaming Clients and our Relay.
We plan to offer DNS-over-HTTPS functionality in the near future; check our Roadmap for more details.
Firefox recognizes when a computer is using the DNSFilter resolvers and will automatically disable DNS-over-HTTPS, which is built-in to the Firefox browser.browser works differently in that is checks to see if the configured DNS server supports DNS-over-HTTPS, and if so, will use it accordingly.
For other browsers, organizations that want to ensure their filtering policies are not circumvented can do this by blocking access to DoH providers. DNSFilter has contributed to a community-maintained list of DoH providers which can be blocked by your firewall. Download the list here.
For more details, check out out blog on DNS-over-HTTPS.