How to Configure BIND 9 Authoritative DNS, DNSSEC Signing, and Response Policy Zones on Ubuntu Server

The Domain Name System (DNS) forms the core address resolution layer of enterprise IT infrastructure. Without cryptographic authentication, standard DNS queries are vulnerable to cache poisoning, Man-in-the-Middle spoofing, and forged response injection (such as Kaminsky-style poisoning attacks). Furthermore, enterprise security teams require the capability to intercept and neutralise malicious domain lookups originating from infected internal endpoints. Linux resolves both challenges through BIND 9 (Berkeley Internet Name Domain).

Operating as the industry-standard DNS server software on Ubuntu Server, modern BIND 9 features native, fully automated DNSSEC (DNS Security Extensions) key rollover and zone signing. When paired with Response Policy Zones (RPZ)—often termed “DNS Firewalling”—network administrators can deliver cryptographically verifiable zone answers to global recursive resolvers while dynamically filtering internal endpoint queries against real-time threat intelligence feeds.

Architectural Overview: Authoritative DNS, DNSSEC, and RPZ

BIND 9 coordinates multiple cryptographic and policy modules within the named daemon process:

Component	Technical Architecture	Security Role
Authoritative Server	Primary / Master Zone Storage	Holds the definitive master records (SOA, NS, A, MX, TXT) for registered corporate domains.
DNSSEC Inline Signing	Asymmetric Cryptography (ECDSA / Ed25519)	Signs resource record sets (RRsets) with RRSIG records, establishing a cryptographic chain of trust to the root zone.
Key-Signing Key (KSK)	Long-term private signing key	Signs the Zone-Signing Key set; published to parent registrar as a Delegation Signer (DS) record.
Zone-Signing Key (ZSK)	Shorter-term operational key	Signs everyday zone records; rotated automatically by BIND 9 policies.
Response Policy Zone (RPZ)	Custom recursive policy overlay	Intercepts client queries; rewrites malicious domain lookups to NXDOMAIN or internal sinkhole IPs.

Installing BIND 9 and Verifying System Service State

Ubuntu Server packages the modern, hardened BIND 9.18+ release directly in its official repositories.

# Install BIND 9, administrative utilities, and DNS diagnostic tools
sudo apt update
sudo apt install -y bind9 bind9utils bind9-doc dnsutils

# Verify the named daemon is active and running
sudo systemctl status named

Configuring an Authoritative Zone with Automated DNSSEC Signing

Modern BIND 9 replaces cumbersome manual dnssec-signzone scripts with native, automated dnssec-policy rules that handle key generation, signing, and key rollovers automatically.

Step 1: Declare the Zone in named.conf.local

Edit /etc/bind/named.conf.local to add the domain definition:

sudo nano /etc/bind/named.conf.local

Add the following configuration block:

zone "enterprise.co.uk" {
    type master;
    file "/var/cache/bind/db.enterprise.co.uk";
    
    // Enable automated inline DNSSEC signing using standard policy
    dnssec-policy default;
    inline-signing yes;

    // Restrict zone transfers to authorized secondary nameservers
    allow-transfer { 198.51.100.5; };
    allow-query { any; };
};

Step 2: Create the Authoritative Zone Database File

Create the zone database file inside /var/cache/bind/ (which grants the bind system user write permissions for dynamic journal and key files):

sudo nano /var/cache/bind/db.enterprise.co.uk

Populate the zone file with standard DNS records:

$TTL 86400
@   IN  SOA ns1.enterprise.co.uk. hostmaster.enterprise.co.uk. (
            2026102401  ; Serial (YYYYMMDDNN)
            3600        ; Refresh
            1800        ; Retry
            604800      ; Expire
            86400 )     ; Negative Cache TTL

; Authoritative Nameservers
@       IN  NS      ns1.enterprise.co.uk.
@       IN  NS      ns2.enterprise.co.uk.

; Server IP Addresses
ns1     IN  A       198.51.100.10
ns2     IN  A       198.51.100.11

; Application Host Records
@       IN  A       203.0.113.50
www     IN  CNAME   @
mail    IN  A       203.0.113.60
@       IN  MX  10  mail.enterprise.co.uk.

; SPF Security Record
@       IN  TXT     "v=spf1 mx -all"

Deploying Response Policy Zones (RPZ) for Threat Neutralisation

To block internal clients from resolving phishing domains, malicious command-and-control (C2) servers, or unwanted tracking nodes, implement an RPZ firewall layer.

Step 1: Configure RPZ in named.conf.options

Edit /etc/bind/named.conf.options:

sudo nano /etc/bind/named.conf.options

Inside the options { ... }; block, append the response-policy directive:

response-policy {
    zone "rpz.internal.blocklist";
};

Step 2: Declare and Populate the RPZ Blocklist Zone

Add the RPZ zone definition to /etc/bind/named.conf.local:

zone "rpz.internal.blocklist" {
    type master;
    file "/etc/bind/db.rpz.internal.blocklist";
    allow-query { localhost; 10.0.0.0/8; };
};

Create the blocklist file /etc/bind/db.rpz.internal.blocklist:

sudo nano /etc/bind/db.rpz.internal.blocklist

$TTL 300
@   IN  SOA localhost. root.localhost. (
            2026102401 3600 1800 604800 300 )
@   IN  NS  localhost.

; Action 1: Force NXDOMAIN (Name Does Not Exist) for phishing domain
malware-payload.com     CNAME   .
*.malware-payload.com   CNAME   .

; Action 2: Redirect known C2 domain to internal sinkhole IP
c2-beacon.ru            A       10.0.99.99

Validating Configuration Syntax and Committing Changes

Always validate BIND 9 configuration files before restarting the daemon to prevent network outages.

# Lint overall named configuration files
sudo named-checkconf

# Lint authoritative zone file syntax
sudo named-checkzone enterprise.co.uk /var/cache/bind/db.enterprise.co.uk

# Reload BIND 9 to trigger automated DNSSEC signing and RPZ loading
sudo rndc reload

Extracting DS Records for Parent Registrar Delegation

Once BIND 9 loads the zone, it automatically generates KSK and ZSK key pairs, establishes RRSIG signatures, and writes key metadata to /var/cache/bind/.

# Query the newly generated DNSKEY records locally
dig @localhost enterprise.co.uk DNSKEY +multiline

# Query the DS (Delegation Signer) record required by your domain registrar
sudo rndc dnssec -status enterprise.co.uk

Copy the generated DS record (Key Tag, Algorithm 13 [ECDSA-P256-SHA256], and Digest) and submit it into your domain registrar’s DNSSEC control panel to link your nameserver into the global ICANN cryptographic root.

Troubleshooting BIND 9, DNSSEC, and RPZ Errors

Consult this diagnostic reference table to resolve common nameserver failures:

Symptom / Error	Underlying Root Cause	Remediation Procedure
rndc: 'reload' failed: permission denied / write error	BIND attempted to write signed .signed and .jnl files into /etc/bind/ where the bind user lacks write access.	Move dynamically signed zone files into /var/cache/bind/, which is owned by bind:bind and permitted by AppArmor profiles.
named-checkconf: unknown option 'dnssec-policy'	Running an outdated legacy release of BIND (prior to version 9.16).	Upgrade BIND to a modern version (sudo apt install bind9 on Ubuntu 22.04/24.04).
External resolvers return SERVFAIL when querying the domain.	DNSSEC validation failure: the DS record at the registrar does not match the active KSK key on the nameserver.	Query parent root servers via delv @8.8.8.8 enterprise.co.uk +rtrace. Reconcile key tags and update the registrar with current DS hashes.
RPZ policies do not intercept client lookups.	BIND is acting strictly as an authoritative nameserver rather than a recursive resolver for clients.	Ensure recursion yes; and appropriate allow-recursion { 10.0.0.0/8; }; ACLs are declared in named.conf.options.

Configuring BIND 9 on Ubuntu Server with automated DNSSEC signing and Response Policy Zones establishes an ironclad, tamper-proof DNS infrastructure that protects corporate domains and proactively defends network perimeters.