cPanel BIND Named Response Rate Limiting (RRL) to Prevent DNS Amplification

Authoritative DNS servers operating on cPanel & WHM hosting infrastructure are perennial targets for distributed denial-of-service (DDoS) reflection attacks. Because UDP DNS queries do not require a three-way handshake, malicious actors easily spoof the IP address of victim infrastructure—such as corporate networks, e-commerce stores, or local telecom gateways across Pakistan—and barrage authoritative nameservers with small ANY, TXT, or DNSKEY queries.

The nameserver dutifully transmits massive, cryptographically signed DNS responses (often exceeding 4,096 bytes under EDNS0) directly to the spoofed victim IP. This creates an amplification factor ranging from 20x to over 70x. Left unmanaged, your authoritative server’s upstream bandwidth on your Dedicated Server in Pakistan is saturated, your clean server IP faces upstream null-routing, and innocent third parties are knocked offline.

Implementing Response Rate Limiting (RRL) within ISC BIND9 on cPanel enables authoritative nameservers to selectively throttle redundant queries, silently drop repetitive reflection attacks, and preserve legitimate client resolution through probabilistic truncation (“slip”).

Mechanics of DNS Amplification & How RRL Intercepts It

In a standard reflection scenario:

1. The botnet sends 10,000 queries per second (qps) for example.pk with qtype=ANY or TXT, setting the UDP source IP to 202.47.32.10 (the victim).
2. The nameserver looks up example.pk, constructs a response containing SOA, MX, TXT, A, and AAAA records, and transmits tens of megabits per second toward 202.47.32.10.
3. The victim suffers volumetric network exhaustion, while the cPanel host’s outbound transit is congested.

BIND Response Rate Limiting tracks inbound client query frequencies using an in-memory hash table based on:

• Client IP prefix: Typically /24 for IPv4 or /56 for IPv6.
• Query name (qname): The targeted domain label.
• Query type / class: ANY, TXT, A, etc.
• Response status: Successful resolution, NXDOMAIN, or error.

When an incoming query stream exceeds the defined responses-per-second threshold, BIND does not return a full UDP response. Instead, it either drops the response entirely or sends a truncated (TC=1) response containing zero payload bytes. The TC=1 flag forces legitimate DNS resolvers to retry over stateful TCP, which spoofed attack traffic cannot do because it cannot receive the TCP SYN-ACK packet.

Step-by-Step: Enabling RRL in cPanel & WHM BIND

By default, cPanel manages /etc/named.conf via the cPanel DNS templates. Direct edits to /etc/named.conf will be overwritten when zones are added or cPanel updates run. You must apply custom BIND configuration directives either via the WHM interface or through the persistent include file /etc/named.conf.local or the templates in /var/cpanel/templates/apache2_4/ / BIND configuration includes.

Step 1: Verify BIND Version & RRL Support

BIND 9.9.4 and higher (native on AlmaLinux 8, AlmaLinux 9, and Rocky Linux) includes RRL natively. Run:

named -v
# Example Output: BIND 9.16.23-RH (Extended Support Version)

Ensure BIND was built with RRL support:

named -V | grep -i "rrl"

Step 2: Configure RRL in /etc/named.conf Include

Open the persistent BIND configuration include file:

nano /etc/named.conf.local

Or insert the rate-limit block inside the global options { ... }; directive. In cPanel, navigate to WHM >> Service Configuration >> Nameserver Selection >> BIND Configuration or edit /etc/named.conf directly, verifying templates:

options {
    // Standard cPanel listening options
    directory "/var/named";
    allow-transfer {"none";};
    allow-recursion {"none";};
    recursion no;

    // Response Rate Limiting (RRL) Engine Configuration
    rate-limit {
        responses-per-second 10;
        referrals-per-second 10;
        nodata-per-second 10;
        nxdomains-per-second 5;
        error-per-second 5;
        all-per-second 30;

        // Grouping subnet prefixes
        ipv4-prefix-length 24;
        ipv6-prefix-length 56;

        // Truncate (slip) every 2nd dropped response to let real resolvers fall back to TCP
        slip 2;

        // Exclude internal cluster nodes, monitoring servers, and secondary slave nameservers
        exempt-clients { 
            127.0.0.1;
            ::1;
            192.168.10.0/24;
            // Add your secondary cPanel DNSOnly node IPs below:
            103.151.40.15;
            103.151.40.16;
        };

        // Window size for rolling rate calculation (seconds)
        window 5;
        
        // Memory tuning: hash table sizing for active clients
        max-table-size 20000;
        min-table-size 1000;
    };
};

Understanding Critical RRL Directives

• responses-per-second 10;: Allows a maximum of 10 identical positive answers per second per /24 IPv4 subnet. Any query beyond this quota within the rolling time window triggers rate limiting.
• nxdomains-per-second 5;: Defends against DNS water torture attacks (random subdomain dictionary attacks like a83nd92.yourdomain.pk). Prevents malicious query flooders from overwhelming the CPU with database negative-cache lookups.
• slip 2;: A slip factor of 2 means that out of every two responses that would be dropped, one is replaced with an empty response bearing the Truncated bit (TC=1). When a legitimate caching resolver (such as Google Public DNS 8.8.8.8 or Cloudflare 1.1.1.1) receives TC=1, its RFC-compliant resolver stack immediately re-queries over TCP port 53. If slip 0; is configured, all responses are dropped silently, which can cause legitimate users behind congested NAT gateways to experience intermittent DNS resolution failures.
• exempt-clients { ... };: Prevents internal monitoring tools, WHM cPanel DNS cluster synchronization scripts (dnsadmin), and secondary slave nameservers from having their zone transfers or status checks throttled.

Validating and Reloading BIND

Before applying the new directives, always perform a configuration syntax check using named-checkconf:

named-checkconf /etc/named.conf

If the command outputs nothing, the configuration syntax is completely valid. If an error is returned (such as unknown option 'rate-limit'), inspect closing braces and semicolons.

Now reload BIND gracefully without interrupting active DNS resolution:

rndc reconfig
# Alternatively reload via cPanel service runner
/usr/local/cpanel/scripts/restartsrv_named

Verify in /var/log/messages or /var/named/data/named.run that RRL initialized properly:

grep -i "rate-limit" /var/log/messages
# Output: Jan 04 15:24:10 srv named[18492]: rate-limiting is enabled

Testing RRL with Query Flooding Simulations

From an external testing machine or remote Cloud VPS, simulate a rapid query burst against your nameserver:

# Send 25 rapid TXT queries for a hosted domain
for i in {1..25}; do dig @ns1.yourdomain.pk example.pk TXT +short; done

Inspect BIND log activity on the cPanel server to witness RRL drops and slip truncation in real time:

tail -f /var/log/messages | grep "rate-limit"

Diagnostic Log Output:

named[18492]: client @0x7f9a14081000 192.0.2.45#51423 (example.pk): rate-limit dropped response to 192.0.2.0/24 for example.pk TXT
named[18492]: client @0x7f9a14081000 192.0.2.45#51424 (example.pk): rate-limit slipped response to 192.0.2.0/24 for example.pk TXT

Notice how BIND alternately drops and slips the packet, effectively neutralizing reflection bandwidth by over 97% while leaving legitimate DNS resolution paths intact.

Comparing Authoritative DNS DDoS Mitigations

For deeper infrastructure security across your cPanel environment, review our architectural guides on cPanel CSF/LFD Custom Regex Rules and cPanel DNS Cluster Sync Failures.