Manage BIND at Runtime with rndc Commands (2026)

BIND’s rndc utility is your backstage pass to controlling a running BIND daemon (named) without needing to restart it. Think of it as the remote control for your DNS server, letting you poke and prod its internal state, reload configurations, and even manage security keys.

Let’s see rndc in action. Imagine you’ve just updated your zone file and want BIND to pick up the changes. Instead of a disruptive systemctl reload named, you’d typically use rndc reload example.com.

# On the server where named is running:
rndc reload example.com

If that works, you’ll see no output. If it fails, you might see something like:

rndc: connect: connection refused

This tells you rndc couldn’t talk to named. We’ll get to that. But assuming it did work, the zone example.com is now reloaded. named didn’t have to re-read its entire configuration file, just the specific zone data. This is much faster and less disruptive than a full reload.

The Core Problem rndc Solves

At its heart, named is a long-running process, a daemon. Restarting it means a brief period where your DNS server is offline. For critical infrastructure, this is unacceptable. rndc allows for granular control, enabling updates and diagnostics without service interruption. It’s how you manage the live state of your DNS server.

How rndc Works: The Control Channel

rndc communicates with named over a dedicated control channel. This channel is secured using shared secret keys. When you configure BIND, you generate a key and tell both named and rndc to use it.

Here’s a typical setup in named.conf:

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

key "rndc-key" {
    algorithm hmac-sha256;
    secret "your_super_secret_key_here==";
};

And in your rndc.conf (often in /etc/rndc.conf or ~/.rndc.conf):

server 127.0.0.1 {
    port 953;
    keys { "rndc-key"; };
};

key "rndc-key" {
    algorithm hmac-sha256;
    secret "your_super_secret_key_here==";
};

Notice the inet 127.0.0.1 port 953 in named.conf. This tells named to listen for control connections on loopback address, port 953. The allow directive restricts who can connect. The keys section points to the shared secret. rndc.conf mirrors this, telling rndc where to find named and which key to use for authentication.

Common rndc Commands and Their Uses

• rndc reload [zone]: Reloads a specific zone or all zones if none is specified.

  • Diagnosis: rndc reload example.com (if it works, no output; if it fails, you’ll see connection errors or authentication failures).
  • Fix: Ensure named.conf and rndc.conf have matching key names and identical secret values. Verify named is listening on the specified IP/port by checking netstat -tulnp | grep 953.
  • Why it works: named accepts the connection on port 953, validates the key used by rndc, and then processes the reload command by re-reading the specified zone file.

• rndc reconfig: Reloads the main BIND configuration file (named.conf) and any included files. This is broader than rndc reload.

  • Diagnosis: rndc reconfig
  • Fix: Same as rndc reload.
  • Why it works: Similar to rndc reload, but it triggers a re-parse of the entire named.conf file and re-initialization of all configured zones and views.

• rndc status: Shows the current operational status of the named process, including uptime, number of zones loaded, and memory usage.

  • Diagnosis: rndc status
  • Fix: Same as rndc reload.
  • Why it works: named responds with internal statistics about its current running state.

• rndc dumpdb [-zones] [-all]: Dumps the server’s internal cache (the "database") to a file. -zones dumps only the loaded zones; -all dumps everything.

  • Diagnosis: rndc dumpdb -zones
  • Fix: Same as rndc reload.
  • Why it works: named writes its current in-memory DNS records (both authoritative data and cached records) to a file, usually in /var/named/data/. This is invaluable for debugging resolution issues.

• rndc stop: Shuts down the named process gracefully.

  • Diagnosis: rndc stop
  • Fix: Same as rndc reload.
  • Why it works: named initiates a clean shutdown sequence, saving its state if configured to do so.

• rndc freeze [zone] / rndc thaw [zone]: These commands temporarily prevent a zone from being updated (e.g., by rndc reload or dynamic DNS updates) or allow it again, respectively.

  • Diagnosis: rndc freeze example.com followed by attempting a rndc reload example.com (which should fail or do nothing). Then rndc thaw example.com.
  • Fix: Ensure keys are correct and named is running.
  • Why it works: freeze marks the zone internally so that further updates are ignored until thaw is issued.

The Counterintuitive Aspect of Key Management

Many users assume rndc keys are just simple passwords. They aren’t. The algorithm hmac-sha256 and the secret string together form a cryptographic HMAC (Hash-based Message Authentication Code). When rndc sends a command, it doesn’t just send the command text; it sends the command plus a signature derived from the command and the shared secret using the specified algorithm. named performs the same calculation and verifies the signature. This ensures that not only is the message from the correct source (if the key is kept secret), but also that the message hasn’t been tampered with in transit. A mismatch in algorithm or an incorrect secret will result in an authentication failure, typically seen as rndc: failed to connect to master master.example.com: permission denied or similar, even if the network connection succeeds.

The Next Step: Dynamic DNS

Once you’re comfortable managing your BIND server at runtime with rndc, the natural next step is to explore how to update zone data automatically using DNS Security Extensions (DNSSEC) and the Transaction Signature (TSIG) mechanism, often facilitated by tools like nsupdate, which also relies on rndc’s keying concepts.