Enable Compliance Audit Logging in BIND (2026)

BIND’s compliance audit logging, often overlooked, isn’t just about recording who changed what on the DNS server. It’s about proving when and why those changes happened, creating an immutable trail that satisfies auditors and helps debug tricky configuration drift. The most surprising thing about BIND’s audit logging is that it’s not a single, monolithic feature, but rather a combination of BIND’s internal logging mechanisms and careful configuration of the controls statement, designed to capture administrative actions.

Let’s see it in action. Imagine we have a BIND 9.16 server and we want to log all rndc commands that modify the configuration or zone data.

First, we need to ensure BIND is configured to accept rndc commands and to log them. This involves the controls statement in named.conf:

controls {
    inet 127.0.0.1 port 953 allow { localhost; } keys { "rndc-key"; };
};

logging {
    channel "audit" {
        file "/var/log/bind/audit.log" versions 3 size 5m;
        severity info;
        print-time yes;
        print-severity yes;
        print-category yes;
    };
    category "control" { "audit"; };
};

// Assuming you have generated a key for rndc
// rndc-confgen -a -k rndc-key
// And placed it in /etc/bind/rndc.key
key "rndc-key" {
    algorithm hmac-md5;
    secret "your_secret_key_here";
};

Here’s what’s happening:

• controls: This block specifies how rndc can connect to the BIND server. We’re allowing connections from localhost on port 953 using a specific key ("rndc-key"). This is the gateway for administrative commands.
• logging: This is where the magic happens.
  • channel "audit": We define a new logging channel named "audit".
    • file "/var/log/bind/audit.log": This is where the logs will be written. We’re using rotation (versions 3 size 5m) to keep the log file manageable.
    • severity info: We want to capture messages of info severity and above.
    • print-time, print-severity, print-category: These directives ensure that each log entry is timestamped, includes its severity level, and the category it belongs to, making it more informative.
  • category "control" { "audit"; };: This is the crucial part. It directs all messages from the control category (which rndc commands fall under) to our newly defined "audit" channel.

Now, let’s generate an rndc key if you haven’t already. On your BIND server, run:

sudo rndc-confgen -a -b 128 -k "rndc-key"

This generates a key and its configuration. You’ll need to copy the key "rndc-key" { ... }; block from the output into your named.conf (or a separate file included by named.conf), and the generated key file (e.g., /etc/bind/rndc.key) should be readable by the BIND process.

After reloading BIND’s configuration (sudo rndc reload or sudo systemctl reload named), you can test it.

Let’s try loading a zone:

sudo rndc loadzone example.com A

Now, check your audit log file (/var/log/bind/audit.log). You should see an entry similar to this:

2023-10-27T10:30:00-07:00 YOUR_HOSTNAME named[12345]: info: control: client @0x7fxxxxxxx 127.0.0.1#xxxxx: received 'loadzone' command for 'example.com/A'

This log entry tells you:

• When: 2023-10-27T10:30:00-07:00 (timestamp)
• Who/What: named[12345] (the BIND process) received a command from 127.0.0.1#xxxxx (the rndc client, identified by its ephemeral port).
• What: received 'loadzone' command for 'example.com/A' (the specific command and its target).

The "why" is inferred from the command itself and the context of your operations. For true "why" logging, you’d typically rely on external scripts or procedures that document the rationale before executing rndc commands.

The mental model here is that BIND has internal "categories" for different types of events. The control category specifically captures interactions via the controls interface, which is what rndc uses. By mapping this category to a dedicated logging channel with appropriate formatting and rotation, we create our audit trail.

A key lever you control is the severity level for the audit channel. Setting it to info captures most administrative actions. If you need more granular detail or want to filter out less critical control messages, you could adjust this. For instance, debug would capture far more, but might be too verbose for a production audit log.

A detail that often trips people up is the interaction between rndc keys and the controls statement. If your controls statement is misconfigured (wrong IP, wrong port, missing allow clause, or incorrect key), rndc commands might fail silently or with generic errors, and no audit log entry will be generated for that attempt. Ensure the key specified in controls exactly matches the key used by the rndc client.

The next challenge you’ll likely face is integrating these audit logs with a centralized logging system like Splunk, ELK stack, or Graylog for long-term retention, searching, and alerting.