This tutorial shall be displaying you learn how to override public DNS data in your BIND DNS resolver with response coverage zone (RPZ) on Debian/Ubuntu.

What’s Response Coverage Zone?

Response coverage zone (RPZ) permits a DNS resolver to switch DNS data. It was initially developed as a approach to block entry to harmful web sites. For instance, if a pc queries the IP handle of a recognized harmful website that spreads malware, the DNS resolver can return 127.0.0.1 because the DNS response, so the pc can’t hook up with the harmful website. That is the unique use case. As such, response coverage zone is also referred to as DNS firewall.

You should utilize RPZ in different methods. For instance,

  • If in case you have self-hosted companies like Nextcloud within the native community, you should use RPZ to level your Nextcloud area (nextcloud.your-domain.com) to the native IP handle, so that you don’t should exit to the Web after which return to your native community to entry the Nextcloud server.
  • Mother and father can use RPZ to dam their youngsters from accessing porn websites.
  • You possibly can block undesirable advertisements.
  • I set up many internet functions on my VPS. When the online app isn’t meant for public entry, I add DNS report in BIND RPZ solely and don’t publish DNS report at my area registrar to forestall hacking.

Sure, you’ll be able to create a DNS entry within the /and so forth/hosts file on the native pc to override public DNS data, but it surely doesn’t scale properly. Moreover, iOS and Android don’t assist you to create native DNS entries. Wouldn’t it’s good if the BIND DNS resolver overrides the general public DNS report, so all gadgets within the community utilizing the BIND resolver can use the customized DNS report?

Conditions

To observe this tutorial, it’s assumed that you’ve got a BIND DNS resolver operating in your Debian/Ubuntu server. If not, please learn one of many following tutorials to arrange BIND resolver.

As soon as your BIND Resolver is up and operating, observe the directions beneath.

Set Up BIND Response Coverage Zone on Debian/Ubuntu Server

First, edit the named.conf.choices file.

sudo nano /and so forth/bind/named.conf.choices

Add the next strains within the choices {…} clause to allow response coverage zone. (The primary line is a remark.)

//allow response coverage zone.
response-policy ;

Set up the Response Policy Zone (RPZ) in the Debian / Ubuntu BIND Resolver

Save and shut the file. Then open the named.conf.native file.

sudo nano /and so forth/bind/named.conf.native

Add a RPZ zone on this file.

zone “rpz.native” {
kind grasp;
file “/and so forth/bind/db.rpz.native”;
allow-query { localhost; };
allow-transfer { 12.34.56.78; };
};

Notes:

  • It’s important that you just use an absolute path as an alternative of a easy file identify within the file directive, or BIND would assume the file is in /var/cache/bind/.
  • RPZ zones ought to permit queries from localhost solely.
  • Exchange 12.34.56.78 with the IP handle of the slave BIND DNS resolver, which is allowed to do zone switch. If there’s just one DNS resolver, you should use localhost like this: allow-transfer { localhost; };

Save and shut the file. Then we have to create the zone file. As an alternative of making a zone file from scratch, we will use a zone template file. Copy the content material of db.empty to a brand new file.

sudo cp /and so forth/bind/db.empty /and so forth/bind/db.rpz.native

Then edit the db.rpz file.

sudo nano /and so forth/bind/db.rpz.native

There is no such thing as a want to alter the prevailing content material. We simply add our customized DNS data. For example, in case you have a Nextcloud server on the native community with an IP handle 192.168.0.103, then you definitely add the next DNS report, so Nextcloud purchasers don’t should exit to the Web with a purpose to hook up with the Nextcloud server.

nextcloud.your-domain.com      A   192.168.0.103

For those who don’t need your youngsters to go to porn websites like pornhub.com, add the next line on this file to dam the entire pornhub.com area.

*.pornhub.com          CNAME  .

For those who don’t wish to see Google Adsense advertisements on internet pages, you’ll be able to add the next line to dam the doubleclick.web area, which is used to ship Adsense Advertisements.

*.doubleclick.web CNAME .

To override the MX report for a site identify, add a line like beneath.

instance.com         MX     0    mail.instance.com.

Word that every one left-hand names should NOT finish with a dot and all right-hand names should finish with a dot.

Set up the Response Policy Zone (RPZ) in the Debian / Ubuntu BIND Resolver
Save and shut the file. It’s advisable to make use of a separate log file for RPZ to raised analyze the log. To configure, edit the BIND fundamental configuration file.

sudo nano /and so forth/bind/named.conf

Add the next strains to the file.

logging {
channel rpzlog ;
class rpz { rpzlog; };
};

Save and shut the file. Then create the /var/log/named/ listing and make bind because the proprietor.

sudo mkdir /var/log/named/
sudo chown bind:bind /var/log/named/ -R

Subsequent, run the next command to verify if there are syntax errors in the primary configuration file. A silent output signifies no errors are discovered.

sudo named-checkconf

Then verify the syntax of the RPZ zone recordsdata.

sudo named-checkzone rpz /and so forth/bind/db.rpz.native

If no errors are discovered, then restart BIND9.

sudo systemctl restart bind9

Now you’ll be able to run the dig command on the BIND server to see if RPZ is working. For instance, question a DNS report of a site identify which is included within the response coverage zone.

dig A nextcloud.your-domain.com @127.0.0.1

It is best to see one thing like beneath within the command output, which signifies the DNS response was served from native RPZ.

;; AUTHORITY SECTION:
rpz.native 86400 IN NS localhost.

You may also verify the BIND9 question log.

sudo tail /var/log/named/rpz.log

You’ll see one thing like beneath, which means the response was served from native RPZ.

(instance.com): rpz QNAME Native-Information rewrite instance.com by way of instance.com.rpz.native

Utilizing RPZ with Forwarders

For those who add a fowarders directive like beneath within the choices clause within the /and so forth/bind/named.conf.choices file, then your BIND resolver turns into a forwarder, which can ahead DNS requests to an upstream DNS resolver like 8.8.8.8.

choices {
listing “/var/cache/bind”;

// If there’s a firewall between you and nameservers you need
// to speak to, chances are you’ll want to repair the firewall to permit a number of
// ports to speak. See http://www.kb.cert.org/vuls/id/800113

// In case your ISP offered a number of IP addresses for steady
// nameservers, you most likely wish to use them as forwarders.
// Uncomment the next block, and insert the addresses changing
// the all-0’s placeholder.

forwarders {
8.8.8.8;
8.8.4.4;
};

};

Response coverage zone works with this forwarder setup. Bind will question the native response coverage zone first. If DNS report just isn’t discovered within the RPZ, then the request shall be forwarded to an upstream DNS resolver.

Configure Zone Switch

If in case you have one other BIND DNS resolver, you’ll be able to configure it as a slave resolver to mechanically obtain updates from the grasp DNS resolver.

First, that you must edit the /and so forth/bind/named.conf.native file on the grasp DNS resolver.

sudo nano /and so forth/bind/named.conf.native

Add the IP handle of the slave DNS resolver to the allow-transfer directive.

zone “rpz.native” {
kind grasp;
file “/and so forth/bind/db.rpz.native”;
allow-query { localhost; };
allow-transfer { 12.34.56.78; };
also-notify { 12.34.56.78; };
};

If in case you have a number of slave DNS resolver, then add a number of IP addresses like beneath.

allow-transfer { 12.34.56.78; 12.34.56.79; };

The also-notify directive will make the grasp DNS resolver ship a notification message to the slave resolver when the RPZ zone is modified. Save and shut the file. Restart BIND for the adjustments to take impact.

sudo systemctl restart bind9

If there’s a firewall operating on the grasp DNS resolver, that you must permit the slave DNS resolver to hook up with port 53. For instance, for those who use UFW firewall, run the next command.

sudo ufw insert 1 permit in from 12.34.56.78 to any port 53

Subsequent, edit the named.conf.choices file on the slave DNS resolver.

sudo nano /and so forth/bind/named.conf.choices

Add the next strains within the choices {…} clause to allow response coverage zone. (The primary line is a remark.)

//allow response coverage zone.
response-policy ;

Save and shut the file. Then edit the named.conf.native file.

sudo nano /and so forth/bind/named.conf.native

Add a slave RPZ zone on this file. Exchange 11.22.33.44 with the IP handle of the grasp DNS resolver.

zone “rpz.native” {
kind slave;
file “db.rpz.native”;
masters { 11.22.33.44;};
allow-notify { 11.22.33.44; };
allow-transfer { none; };
allow-query { localhost; };
};

Save and shut the file.

You additionally have to configure the slave resolver’s firewall to permit the grasp DNS resolver to ship notify messages.

sudo ufw insert 1 permit in from 11.22.33.44 to any port 53

Subsequent, run the next command to verify if there are syntax errors in the primary configuration file. A silent output signifies no errors are discovered.

sudo named-checkconf

If no errors are discovered, then restart BIND9.

sudo systemctl restart bind9

After BIND9 restarts, zone tranfer will begin instantly. Verify the BIND9 log with the next command.

sudo journalctl -eu bind9

or

sudo journalctl -eu named

You possibly can see messages like beneath, which signifies the zone switch is profitable.

switch of ‘rpz.native/IN’ from xx.xx.xx.xx#53: Switch standing: success
switch of ‘rpz.native/IN’ from xx.xx.xx.xx#53: Switch accomplished: 1 messages, 34 data, 899 bytes, 0.248 secs (3625 bytes/sec)

Word: Everytime you modify the RPZ zone on the grasp resolver, that you must replace the serial quantity. Make it greater, in order that slave resolvers know the RPZ zone is modified.

Creating A number of RPZ Zones

Typically you won’t need sure DNS data to be transferred to slave resolvers. You possibly can create a separate RPZ zone. Edit the named.conf.choices file.

sudo nano /and so forth/bind/named.conf.choices

Add a brand new RPZ zone.

//allow response coverage zone.
response-policy ;

Save and shut the file. Then open the named.conf.native file.

sudo nano /and so forth/bind/named.conf.native

Add a definition for the brand new zone on this file.

zone “rpz.native.notransfer” {
kind grasp;
file “/and so forth/bind/db.rpz.native.notransfer”;
allow-query { localhost; };
allow-transfer { localhost; };
};

Save and shut the file. Then we have to create the zone file. As an alternative of making a zone file from scratch, we will use a zone template file. Copy the content material of db.empty to a brand new file.

sudo cp /and so forth/bind/db.empty /and so forth/bind/db.rpz.native.notransfer

Then edit the db.rpz file and add customized DNS data.

sudo nano /and so forth/bind/db.rpz.native.switch

Wrapping Up

I hope this tutorial helped you arrange response coverage zone/DNS firewall on Debian/Ubuntu. As all the time, for those who discovered this publish helpful, then subscribe to our free e-newsletter to get extra suggestions and tips. Take care 🙂

Charge this tutorial

[Total: 0 Average: 0]

bind response policy zone,bind rpz whitelist,bind response-policy view,bind rpz-passthru,bind rpz wildcard,unknown option 'response-policy',bind return nxdomain,rpz file example