DNS Sinkholing with BIND9: Kill Malware at the Network Edge

Table of Contents

Triage at 2 AM

It is 2 AM on a Tuesday. Your monitoring dashboard just spiked. A dozen workstations are attempting to reach a known Command and Control (C2) domain, signaling a potential ransomware outbreak. You could physically pull network cables or try to block thousands of rotating IPs on the firewall. However, there is a more efficient way to neutralize the threat: DNS Sinkholing.

This guide demonstrates how to deploy a DNS Sinkhole using BIND9’s Response Policy Zones (RPZ). This configuration allows you to intercept and override DNS queries for malicious domains across your entire infrastructure. You won’t need to touch a single client machine.

Comparing DNS Blocking Approaches

When you need to prevent devices from reaching specific corners of the internet, you generally have three options. Choosing the right one depends on your scale and the complexity of the threat.

The /etc/hosts Method: This involves adding entries to a local file. It works for a single lab machine but fails when you need to protect 500 servers or a fleet of unmanaged IoT devices.
Firewall IP Blocking: Blocking traffic at Layer 3 or 4 is traditional. However, modern threats use CDNs and fast-flux DNS. If you block one malicious IP, you might accidentally take down 1,200 legitimate sites sharing that same Cloudflare edge address.
DNS RPZ (Response Policy Zones): Think of this as a firewall for DNS. It checks every query against a reputation list. If a domain is flagged, BIND returns a modified response, such as 0.0.0.0 or an NXDOMAIN error.

The Reality of BIND9 RPZ

I have deployed this setup in high-traffic environments. While it is incredibly stable, it is important to understand what it can and cannot do.

The Benefits

Centralized Enforcement: A single update on your BIND server protects every laptop, server, and smart printer on the network.
Platform Independent: It works regardless of the OS. If the device uses your DNS, it follows your rules.
High Performance: BIND processes RPZ lookups with sub-millisecond latency. Your users won’t notice a delay.
Industry Standard: RPZ is a mature extension, making it compatible with many threat intelligence feeds.

The Limitations

DNS over HTTPS (DoH): Modern browsers like Chrome or Firefox can bypass local DNS by using encrypted providers like Google or Cloudflare. To close this loophole, you must block known DoH provider IPs at your perimeter firewall.
Upkeep: A sinkhole is only as good as its data. You need a process to refresh your blacklists daily.

Recommended Environment

For a production-grade resolver, use a stable Linux distribution. Ubuntu 22.04 LTS or Debian 12 are the standard choices. Ensure you are running BIND 9.16 or newer to take advantage of optimized RPZ handling.

Lab Specs:

OS: Ubuntu 22.04 LTS
Internal IP: 192.168.1.10
Software: BIND 9.18.x

Implementation Guide

Step 1: Install BIND9

Update your repositories and install the BIND9 suite. We include bind9utils for configuration testing.

sudo apt update
sudo apt install bind9 bind9utils bind9-doc -y

Step 2: Configure Global Options

Configure BIND to act as a recursive resolver for your local subnet. We will also enable the response-policy feature. Edit /etc/bind/named.conf.options:

acl "trusted" {
        127.0.0.0/8;
        192.168.1.0/24;  # Your local network
};

options {
        directory "/var/cache/bind";

        recursion yes;
        allow-query { trusted; };

        forwarders {
                9.9.9.9; # Quad9 for extra security
                1.1.1.1;
        };

        dnssec-validation auto;
        listen-on-v6 { any; };

        # This line enables the RPZ logic
        response-policy { zone "rpz.blacklist"; };
};

Step 3: Define the RPZ Zone

Define the zone file location in /etc/bind/named.conf.local. This zone is strictly internal and should not be accessible from the outside world.

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

Step 4: Create the Policy File

This file contains your list of blocked domains. We will map malicious entries to specific actions. Create /etc/bind/db.rpz.blacklist:

$TTL 60
@            IN  SOA  localhost. root.localhost. (
                          2023102701 ; serial (YYYYMMDDNN)
                          1h         ; refresh
                          15m        ; retry
                          30d        ; expire
                          1h )       ; default_ttl

             IN  NS   localhost.

# --- Policy Rules ---

# Return NXDOMAIN for this domain and all subdomains
bad-malware-site.com    IN CNAME .
*.bad-malware-site.com  IN CNAME .

# Redirect a tracker to a null IP
evil-tracker.net        IN A     0.0.0.0
*.evil-tracker.net      IN A     0.0.0.0

# Block a specific ad server
adservice.google.com    IN CNAME .

In RPZ syntax, CNAME . tells BIND to return an NXDOMAIN error. This is often better than 0.0.0.0 because applications stop trying immediately rather than waiting for a connection timeout.

Step 5: Verify and Load

Syntax errors can crash your DNS service. Always validate your config before restarting. I have seen a missing semicolon take down an entire office’s internet access.

# Check for general syntax errors
sudo named-checkconf

# Validate the RPZ zone specifically
sudo named-checkzone rpz.blacklist /etc/bind/db.rpz.blacklist

# Ensure BIND can read the file
sudo chown bind:bind /etc/bind/db.rpz.blacklist

# Apply the changes
sudo systemctl restart bind9

Testing the Policy

Use dig to verify that the server is intercepting queries correctly. Run these commands from a client machine or the server itself.

# Check the NXDOMAIN policy
dig @localhost bad-malware-site.com
# Result should show: status: NXDOMAIN

# Check the 0.0.0.0 redirect
dig @localhost evil-tracker.net
# Result should show: evil-tracker.net. 60 IN A 0.0.0.0

If you receive the actual internet IP address, verify that your client’s IP is included in the trusted ACL in named.conf.options.

Automation and Maintenance

Manually updating text files is not sustainable. In production, you should automate the ingestion of threat feeds. Many admins use Python scripts to fetch data from Spamhaus DBL or URLHaus.

I typically use a script that aggregates these lists, formats them into BIND syntax, and increments the SOA serial number. A simple rndc reload rpz.blacklist command then pushes the new blocks live without a full service restart.

One warning: be careful with aggressive ad-blocking. I once blocked a domain that was required for a critical accounting software’s license validation. Always maintain a whitelist zone to quickly restore access when a false positive occurs.

Summary

DNS Sinkholing with BIND9 RPZ is a cost-effective way to harden your network. It stops threats before a TCP connection is even established. While it won’t stop a determined attacker using hardcoded IPs, it effectively wipes out the bulk of automated malware and intrusive tracking across your entire infrastructure.