When you need custom DNS rules and content filtering for different subnets inside your network.

Different rules for different subnets

A common question we get via email from CleanBrowsing users is asking how one can configure their internal DNS resolver to use our porn/adult filtering on a portion of their network, allowing other subnets to remain unfiltered. There are multiple ways to split your DNS per location (subnets) and on this guide we will show you how to configure views on Bind (the most popular DNS software) to create different rules per subnet.

This type of setup can be very useful for Schools trying to fulfill CIPA requirements to filter explicit and adult content out of the students subnets, without restricting any site for teachers. It allows to create custom rules for elementary students that may not apply to high school ones. It can also be used for Business with different audit and security requirements on different subnets.

This guide assumes that you are running your own DNS resolver with custom DNS zones to be used internally. If you do not have a custom resolver, this guide is not necessary as you can force the nameservers on all the devices directly via DHCP (or manually via a management software). For all simpler cases, you can follow these steps to change the DNS.

Step 1: Configuring your resolver.

We are assuming you have your own resolver and Bind configured. The default configuration will be at /etc/bind/named.conf or /etc/named.conf on most Linux distributions, so that’s where we will do all of our changes in this guide.

First, we need to create a separation per subnet. Bind (aka Named) offers the concept of views, where it will split your DNS configuration and cache based on the views rules. Inside each view, you can use multiple options to specify what traffic goes to what views. For our guide, we will try to emulate a school (k12) network, with these 3 views:

students . Subnet: 192.168.10.0/24. This subnet is the one used by all students laptops and ipads.

. Subnet: 192.168.10.0/24. This subnet is the one used by all students laptops and ipads. teachers . Subnet: 192.168.20.0/24. This subnet is restricted only to the teachers laptops.

. Subnet: 192.168.20.0/24. This subnet is restricted only to the teachers laptops. Tech team. Subnet: 192.168.30.0/24. This subnet is restricted to the IT team and their servers and laptops.

For that, we will split our DNS resolver into these 3 zones. A very basic configuration would look like:

view "students" { recursion yes; match-clients { 192.168.10.0/24; }; include "/etc/bind/school.zones"; } view "teachers" { recursion yes; match-clients { 192.168.20.0/24; }; include "/etc/bind/school.zones"; } view "tech" { recursion yes; match-clients { 192.168.30.0/24; }; include "/etc/bind/school.zones"; }

This initial configuration is very simple. We named each view and assigned the traffic to them based on the source IP address by using the match-clients directive. That will force all traffic from 192.168.10.0/24 to go to the students view, for example. Also, noticed that we added a include “/etc/bind/school.zones”;. I am assuming that you had previous zones configured, so you have to move them inside each view. If you do not have custom zones (say for your intranet), you can remove that line.

If you are restaring Bind by using rndc reload and getting this error in the logs: “when using ‘view’ statements, all zones must be in views” . It means that you have some zone configured outside of a view. A simple way to fix it is by copying the same zone to all views (or the ones that need it).

Step 2: Configuring your Filters per view.

Once you get your views configured properly, you can move on to enable the filters for them. Let’s say we want to filter all Adult and Explicit content out of the students subnet by using the CleanBrowsing service. To do that, you can configure that view as a Forwarder to our CleanBrowsing IP addresses: 185.228.168.168 and 185.228.169.168:

view "students" { recursion yes; forward only; forwarders { 185.228.168.168; 185.228.169.168; }; match-clients { 192.168.10.0/24; }; include "/etc/bind/school.zones"; }

Once you restart Bind (by using rndc reload), all DNS requests for that view, will be resolved by CleanBrowsing, which will return a NXDOMAIN for any adult or pornographic domains. You still get to keep the logs internally (if you want) and get the benefits of a strong filter.

For your teachers subnet, you may want some less agressive filtering, which can be done with our For Adults service that only blocks access to pornographic content, keeping the rest of the web unfiltered:

view "teachers" { recursion yes; match-clients { 192.168.20.0/24; }; forward only; forwarders { 185.228.168.10 }; include "/etc/bind/school.zones"; }

Note that the “tech” view can still access the Internet without any filtering, which might be necessary for the IT team.

Step 3: Save and apply to production

That’s all you need to create custom filters per subnet. Bind allows you to have as many views as you want and you can expand your configuration to cover even bigger networks with minimal work. Once you have it tested, save your config, apply to production and you are set.