DNS query filtering
Starting with version 9.8.1 of the bind DNS server, a new feature has appeared - DNS RPZ. This is an interesting tool that can be very useful for many system administrators. Strange, but in the Russian-language segment of the Internet, this topic is completely not covered. I hasten to fill this gap.
The abbreviation RPZ stands for response policy zone. This is a technology developed by ISC that provides telecom operators with an easy way to block DNS queries to certain resources or redirect them to an alternate address. RPZ is a zone that can be transferred between servers (DNS AXFR / IXFR), is protected by transaction signatures (DNS TSIG) and is updated in real time (DNS NOTIFY).
As with any other DNS zone, a SOA record and at least one NS record are required. SOA is a valid record with a serial number and timers, used for zone delegation and indicating record lifetime (TTL). An NS record is never used and is for compatibility purposes. Usually, a single NS record has a dummy localhost value. The rest of the zone are expressions for DNS policies. Policies can be applied to domain names or to their templates.
Simplified RPZ operation can be represented by the following scheme:
The right part shows the scheme of working with a conventional caching DNS server, which returns to the client all the responses from the edge servers, as is. In the case of RPZ, the Security Policy Provider appears - the DNS server from which we take the domain name resolution policies. The presence of a third-party provider is completely optional, we can set our own local policies. More about this later, as an example.
There may be several providers, including we can create our own RPZ server:
For more details on the protocol operation, see the official documentation (links below) - I think those who need details will master it on their own.
Let's show the work of RPZ using the example of working configs. This implies that you already have a configured DNS server, I will only show the options that you need to enable in order for everything to work. The action takes place in Ubuntu 12.10.
First, in the /etc/bind/named.conf.options file with the “response-policy” option, enable the RPZ:
There can be several zones within the "response-policy", and each can have its own policy (see the specification for details).
In the file /etc/bind/named.conf.local we place the description of the zone:
And finally, the zone itself (file /etc/bind/db.rpz.zone):
We apply new settings:
and see what happened:
As you can see from the server’s response, the address is spoofed by habrahabr.ru.
We will see the following in the browser:
Of course, we can make a substitution on our internal server, which, for example, will inform the client that access to the requested domain is prohibited by the security policy.
Here the request remained unanswered. The same thing will happen with any subdomain of gov.by:
It is easy to guess that all subdomains of the blabla.com domain will be replaced with the address 1.2.3.4, and all domains of the xxx zone will be replaced with localhost.
I will explain the last line of the zone separately. Being a small provider in a provincial town, we often encounter the problem of completely tight users, for whom typing the address of our home page is an impossible task (and this is the starting point for all our internal resources).
It sometimes comes to comic cases when technical support beats in hysterics with its head on the table. This is what this record was created for. It is enough for the client to type “1.by” in the address bar of the browser (without quotes), and he gets to where he needs to:
And so that such a disgrace does not excite the eye of more or less literate users, by means of a web server (RewriteRule in Apache) the host “1.by” is redirected to the valid server address.
Links:
ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt
kb.isc.org/category/110/0/10/Software-Products/BIND9/Features/DNSRPZ
What kind of animal is it and what does it eat with?
The abbreviation RPZ stands for response policy zone. This is a technology developed by ISC that provides telecom operators with an easy way to block DNS queries to certain resources or redirect them to an alternate address. RPZ is a zone that can be transferred between servers (DNS AXFR / IXFR), is protected by transaction signatures (DNS TSIG) and is updated in real time (DNS NOTIFY).
Zone Format
As with any other DNS zone, a SOA record and at least one NS record are required. SOA is a valid record with a serial number and timers, used for zone delegation and indicating record lifetime (TTL). An NS record is never used and is for compatibility purposes. Usually, a single NS record has a dummy localhost value. The rest of the zone are expressions for DNS policies. Policies can be applied to domain names or to their templates.
How does it work
Simplified RPZ operation can be represented by the following scheme:
The right part shows the scheme of working with a conventional caching DNS server, which returns to the client all the responses from the edge servers, as is. In the case of RPZ, the Security Policy Provider appears - the DNS server from which we take the domain name resolution policies. The presence of a third-party provider is completely optional, we can set our own local policies. More about this later, as an example.
There may be several providers, including we can create our own RPZ server:
For more details on the protocol operation, see the official documentation (links below) - I think those who need details will master it on their own.
Let's show the work of RPZ using the example of working configs. This implies that you already have a configured DNS server, I will only show the options that you need to enable in order for everything to work. The action takes place in Ubuntu 12.10.
First, in the /etc/bind/named.conf.options file with the “response-policy” option, enable the RPZ:
response-policy {
zone "rpz.zone";
};
There can be several zones within the "response-policy", and each can have its own policy (see the specification for details).
In the file /etc/bind/named.conf.local we place the description of the zone:
zone "rpz.zone" {
type master;
file "/etc/bind/db.rpz.zone";
allow-query {any;};
allow-update {none;};
};
And finally, the zone itself (file /etc/bind/db.rpz.zone):
;RPZ
$TTL 10
@ IN SOA rpz.zone. rpz.zone. (
5;
3600;
300;
86400;
60 )
IN NS localhost.
vk.com CNAME habrahabr.ru.
*.gov.by CNAME .
gov.by MX 0 gmail.com.
*.blabla.com A 1.2.3.4
*.xxx A 127.0.0.1
1.by CNAME abcde-net.by.
We apply new settings:
sudo rndc reload
and see what happened:
dig vk.com
; <<>> DiG 9.8.1-P1 <<>> vk.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11880
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;vk.com. IN A
;; ANSWER SECTION:
vk.com. 10 IN CNAME habrahabr.ru.
habrahabr.ru. 466 IN A 212.24.43.44
;; Query time: 0 msec
;; SERVER: 192.168.3.204#53(192.168.3.204)
;; WHEN: Thu Apr 25 00:56:49 2013
;; MSG SIZE rcvd: 66
As you can see from the server’s response, the address is spoofed by habrahabr.ru.
We will see the following in the browser:
Of course, we can make a substitution on our internal server, which, for example, will inform the client that access to the requested domain is prohibited by the security policy.
dig gov.by
; <<>> DiG 9.8.1-P1 <<>> gov.by
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10961
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;gov.by. IN A
;; AUTHORITY SECTION:
rpz.zone. 10 IN SOA rpz.zone. rpz.zone. 8 3600 300 86400 60
;; Query time: 11 msec
;; SERVER: 192.168.3.204#53(192.168.3.204)
;; WHEN: Thu Apr 25 00:59:18 2013
;; MSG SIZE rcvd: 68
Here the request remained unanswered. The same thing will happen with any subdomain of gov.by:
It is easy to guess that all subdomains of the blabla.com domain will be replaced with the address 1.2.3.4, and all domains of the xxx zone will be replaced with localhost.
I will explain the last line of the zone separately. Being a small provider in a provincial town, we often encounter the problem of completely tight users, for whom typing the address of our home page is an impossible task (and this is the starting point for all our internal resources).
It sometimes comes to comic cases when technical support beats in hysterics with its head on the table. This is what this record was created for. It is enough for the client to type “1.by” in the address bar of the browser (without quotes), and he gets to where he needs to:
And so that such a disgrace does not excite the eye of more or less literate users, by means of a web server (RewriteRule in Apache) the host “1.by” is redirected to the valid server address.
Links:
ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt
kb.isc.org/category/110/0/10/Software-Products/BIND9/Features/DNSRPZ