Hi Muukalainen,

In my premises, I’m relying on Proxied connectivity for anything that doesn’t belongs to my networks. Meanwhile, I also want local DNS resolutions and this using BIND DNS systems. The idea here is to configure our BIND DNS system to resolve exclusively what we’re tolerating and reply with controlled information upon none tolerated DNS requests…

Response Policy Zones#

Essentially, after having built an up & running BIND resolver, the next step is to implement Response Policy Zones / RPZ . Basically RPZ can be used to create a DNS firewall, thus limiting what domains can be resolved. However, what I wanted here was a total blacklist with only a very small subset of tolerated exceptions.

BIND response-policy configuration#

In my setup, my 1st configuration update was on the /etc/bind/named.conf.options file, adding the following directives:

        # RPZ whitelist
        response-policy { zone "rpz.whitelist"; zone "rpz"; } qname-wait-recurse no;

In the above directives hide’s a little trick, the qname-wait-recurse feature set to no would actually prevent the outbound resolutions of queries not explicitly part of our rpz.whitelist zone. If that feature is left to defaults, every queries get resolved no matter the actual BIND reply to the requesting client.

All queries will here be filtered based on the response policy zones listed above. If a match is found in the first, db.rpz.whitelist then that will be used, otherwise the second one db.rpz will kick in (here, our blacklist over *).

BIND RPZ Zones definitions#

The next configuration need’s are our RPZ Zones definitions, for me held within the /etc/bind/named.conf.localfile:

        zone "rpz.whitelist" {
                type master;
                file "/etc/bind/zones/db.rpz.whitelist";
                allow-query { none; };
        };

        zone "rpz" {
                type master;
                file "/etc/bind/zones/db.rpz";
                allow-query { none; };
        };

BIND RPZ Zones contents#

See update below – This is basically how my RPZ Zones files looks like; here the /etc/bind/zones/db.rpzfile, configured to reply to any hitting requests with the 10.0.0.1 address:

@	          IN	SOA	dns.domain.suffix. admin.dns.domain.suffix. (
                        9
                        3H
                        1H
                        1W
                        1H )

@             IN    NS    localhost.

*            		 A    10.0.0.1

That controlled reply upon untolerated requests is in fact returning a .local IP address of a running host in my networks, host on which I’ve enabled two services, Network Time Protocol as well as a simple web server on both TCP:80 and TCP:443. A simple way to keep NTP locally managed and a walled garden web site handling redirection’s of misbehaving/no proxy hosts.

And here, the contents of the /etc/bind/zones/db.rpz.whitelistfile:

$TTL 60
@       IN      SOA     localhost. root.localhost. (
                        25
                        3H
                        1H
                        1W
                        1H )

rpz.whitelist.  IN      NS      dns.domain.suffix.

*.local                 CNAME   rpz-passthru.

*.archlinux.org         CNAME   rpz-passthru.

*.debian.org            CNAME   rpz-passthru.
...

Note that each entries above are listed as CNAME records pointing to rpz-passthru. This is the RPZ syntax telling BIND to allow queries for these domains.

Now, in my setups, such BIND systems would typically be the main configured resolver through DHCP on any endpoints/servers etc. This while the only entity being able to address a full spectrum of external DNS queries would be the main Proxy Server (DNS through DoT and using further filtering, SSL Interception, ICAP AV etc etc etc…)

On the main BIND DNS’s Servers, I would indeed keep a short list of trusted domains resolve-able, that is to cover corner cases where proxy is not possible, or when some proxy client implementations wouldn’t work without DNS resolutions, which sadly happens now and then.

Hope this helps some of you,

So longue,
Obuno

UPDATE 05.09.2024#

Within my db.rpz file and in order to handle/force Proxy server based external DNS resolutions, I’ve now shifted to NXDOMAIN replies on my implicit wildcard entry while redirecting some NTP Operating Systems default entries to a local NTP server using local Master Zones. Where (CNAME .), the dot means NXDOMAIN response.

Here is my current db.rpz file standings:

@	          IN	SOA	dns.domain.suffix. admin.dns.domain.suffix. (
                        9
                        3H
                        1H
                        1W
                        1H )

@             IN    NS    localhost.

*                       CNAME   .

And a Master Zone NTP hijack so to speak, DNS Zone which you obviously need to include within your RPZ Whitelist;

$ttl 3600
ntp.org.        IN      SOA     dns.domain.suffix. admin.dns.domain.suffix. (
                        70
                        3600
                        600
                        1209600
                        3600 )

ntp.org.               IN      NS      dns.domain.suffix.
dns.domain.suffix.     IN      A       10.0.0.1

; ####################################################
; ###### ZONE START ##################################
; ####################################################

; ----------------------------------------------------
; ------ NTP.ORG -------------------------------------
; ----------------------------------------------------

*.pool                 IN      A       10.0.0.1