BIND DNS Server Hardening: Recursion, Zone Transfers, TSIG and DNSSEC Settings

Securing BIND comes down to a handful of settings: recursion open to the internet, zone transfers open to anyone, dynamic updates authorised by IP address and a stale release line. BIND 9 from ISC is still the reference DNS server on Linux and Unix, running authoritative zones, internal resolvers and hidden primaries. This guide goes past the generic DNS advice into the actual named.conf controls: access control lists, recursion limits, zone transfer and update security with TSIG, Response Rate Limiting, DNSSEC signing with dnssec-policy, the rndc control channel, privilege separation, logging and patching. It is written for DNS administrators and infrastructure security teams. Option names and behaviour come from the BIND 9 Administrator Reference Manual and the ISC Knowledge Base; confirm details against the ARM for your release.

This is an independent guide from NHI Mgmt Group, based on ISC's public documentation as of November 2026. It is not sponsored or reviewed by ISC. Product features change, so confirm settings against ISC's current documentation.

Key takeaways

• Separate authoritative and recursive roles. ISC recommends different server sets for each, and says internet facing authoritative servers ideally should not recurse at all.
• ACLs are first match, not best match. In { 10/8; !10.0.0.1; } the address 10.0.0.1 still matches. Put negations first and test every list.
• Authorise transfers and updates by TSIG key, never by IP. The ARM calls IP based allow-update insecure because UDP source addresses are easily forged.
• Turn on Response Rate Limiting on authoritative servers. RRL is off by default; start with log-only yes, then enforce.
• Stay on a supported branch and patch fast. Apply ISC's security updates promptly; see the ISC BIND 9 Software Vulnerability Matrix for current advisories.

How identity and access work in BIND

BIND has no user accounts. Every access decision is made by address match lists, which can match a source IP or prefix, a TSIG or SIG(0) key, a named acl, or an EDNS Client Subnet prefix. A matching entry allows, a negated match (!) denies, and if nothing matches access is denied. Matching stops at the first hit, so ordering matters. For the generic DNS threat model, see the DNS Security Guide; this page stays on BIND itself.

Recursion defaults and why they still bite

Since BIND 9.4.1-P1, if neither allow-recursion nor allow-query-cache is set, both default to localnets; localhost;, and setting one sets the other to the same value (ISC Knowledge Base AA-00269). That default is safe on a host with only private interfaces but not on a server whose interface sits in a public subnet: localnets then covers everyone on that subnet. Write explicit ACLs instead of relying on defaults:

• Named ACL: acl "clients" { 10.20.0.0/16; 192.0.2.0/24; }; then allow-recursion { clients; }; and allow-query-cache { clients; };.
• Authoritative only: recursion no; in options, so BIND never resolves on behalf of a client and cannot be used as an open resolver for reflection (ATT&CK T1498.002).
• Views: where one server must answer internal and external clients, ISC warns to use views carefully or split internal and external zones onto different servers, and to test with canary records that internal data does not leak.

Admin roles and privileged access

Privilege in BIND means three things: who can change named.conf and zone files on disk, who can use the rndc control channel, and which operating system account named runs as.

The rndc control channel

If there is no controls statement, named listens on 127.0.0.1 and ::1, uses the key file /etc/rndc.key (created by rndc-confgen -a), and the inet channel uses port 953. The read-only flag is off by default, so the channel allows full control (reload, freeze zones, flush caches, stop). To disable it entirely use controls { };.

• Keep it local: bind inet only to loopback, and block TCP 953 at the host firewall. Remote management should go over SSH to the host, not over an exposed control port.
• Read only monitoring: if a monitoring system needs rndc status, give it a separate key on a channel with read-only yes.
• Protect the key file: rndc.key grants full control of the server. Owner root or the named group, mode 0640 or tighter.

Run named unprivileged

• Drop root with -u: ISC's authoritative best practice is to run as an unprivileged user with the -u argument. Note the ARM caveat that an unprivileged named cannot bind new privileged ports on reload, so listen-on changes need a restart.
• Chroot with -t if you want it: the ARM documents -t <dir> as a sandbox and recommends combining it with -u. ISC's best practice page says chroot is neither recommended nor discouraged; on modern distributions, systemd sandboxing and SELinux or AppArmor profiles do similar work. If you chroot, adjust directory and pid-file and provide /dev/random, /dev/zero, /dev/log and /etc/localtime as your OS needs.
• Write access only where needed: named must write to dynamic and inline signed zone files, journals and key directories, but should not be able to write named.conf or static zone files.
• Dedicated hosts: ISC recommends running BIND on servers dedicated to DNS, which shrinks who has shell access in the first place.

Integrations, API tokens and service accounts

BIND's machine credentials are its keys: TSIG keys shared with secondaries and DHCP or automation systems, the rndc key, and DNSSEC private keys. They are non-human identities and need owners, rotation and storage rules like any other. See the Secrets Management Guide.

TSIG and update rules from the ARM

• Keep secrets out of world readable files: the ARM says named.conf should not be world readable when it holds keys, or keys should sit in a separate restricted file pulled in with include.
• List keys, not addresses, in allow-update: the ARM states that address based update control is insecure because the source address of an update UDP packet is easily forged. It also warns that if a forwarding secondary is listed, an attacker can relay updates through it.
• Prefer update-policy: it grants per key rights on names and record types rather than all or nothing, for example letting an ACME client change only _acme-challenge TXT records.
• Delegate dynamic data: the ARM suggests putting dynamically updated names in a delegated subdomain so the top level zone allows no updates at all.
• Read the errors: TSIG failures return BADKEY (unknown key), BADSIG (bad signature) or BADTIME (clock outside the window), all as NOTAUTH. BADTIME usually means NTP is broken; repeated BADKEY or BADSIG from one source is probing.
• Encrypt where you can: the ARM notes that TSIG gives integrity in transit and authenticated TLS adds confidentiality; BIND 9.20 accepts a transport argument on allow-transfer for zone transfers over TLS.

Logging and detection

BIND logging is configured in the logging statement with channels (file, syslog, stderr) and categories. Send security relevant categories to syslog and on to your SIEM. For DNS telemetry beyond the server itself, see the DNS Logging and Detection Guide.

• Query logging is expensive: ISC estimates roughly ten times the overhead and advises enabling it only after careful thought. Prefer sampling, dnstap or network capture on resolvers where you need full query visibility.
• Keep enough history: ISC advises sizing log files and retention so the logs from the onset of a problem are not rotated away; plan for several hours to more than 24 hours of context.
• Watch the process: monitor process presence, CPU, memory, network buffers and disk. BIND's common failure mode is deliberate termination on inconsistent state, so use a supervisor to restart it and archive logs.
• Statistics channel: ISC recommends enabling the XML statistics channel for troubleshooting; bind it to loopback or a management network only.

Metrics that show the hardening is working

• Recursive answers served to addresses outside the client ACL: target zero (test externally each quarter).
• Zone transfers to unknown addresses: target zero.
• Dynamic updates without a TSIG key accepted: target zero.
• Days between an ISC security release and production deployment: track against your patch SLA.
• Percentage of TSIG keys with a named owner and a rotation date: target 100 percent.
• Hours of DNSSEC signature validity remaining on public zones: alert well before expiry.

Hardening baseline

Version and patching

ISC's support policy gives each stable (even numbered) branch about four years: roughly a year of feature and bug fixes, then Extended Support with critical and security fixes only. Odd numbered branches such as 9.21 are development releases and are not for production. As checked on 8 November 2026, ISC lists 9.16 as end of life and 9.20 as the current stable branch, while its own pages disagree on the exact 9.18 end date, so confirm on the ISC download page before planning. Subscribe to bind-announce and track the BIND 9 Software Vulnerability Matrix, which shows the fixed version for every CVE. See the Patch Management Guide.

Configuration baseline

Response Rate Limiting

ISC recommends RRL for authoritative servers; on resolvers it is more likely to cause false positives. It is off by default. Responses are tracked in a rolling window that defaults to 15 seconds (range 1 to 3600), and the default buckets group clients by /24 for IPv4 and /56 for IPv6. Tune responses-per-second, ipv4-prefix-length and exempt-clients first; separate limits exist for nxdomains-per-second, errors-per-second, referrals-per-second and all-per-second. ISC also advises provisioning for bursts of around 20 times normal traffic and generally preferring RRL to inbound packet filtering. See the DDoS Protection Guide.

DNSSEC signing with dnssec-policy

dnssec-policy default; in a zone creates one key that signs the whole zone and uses NSEC. A custom policy sets algorithms, key lifetimes and NSEC3 parameters, for example a KSK lifetime of P1Y and ZSK of 60d with ecdsap384sha384, and nsec3param iterations 0 optout no salt-length 0;. The policy needs dynamic DNS or inline-signing, and BIND then handles re-signing and key rollovers. Configure parental-agents with checkds explicit; so BIND checks the DS record at the parent during KSK rollovers, and remember that BIND does not validate the agent's answers, so it must be trusted. For deployment planning see the DNSSEC Deployment Guide.

Rollout order

1. Inventory: list every BIND instance, its role, version, zones, secondaries and update clients.
2. Close recursion: set explicit ACLs or recursion no;, validate with named-checkconf, reload, then test from an external host.
3. Key transfers: deploy TSIG keys to each secondary, add the server statements, confirm transfers succeed, then remove IP grants from allow-transfer. Keep the old configuration file to roll back.
4. Key updates: move each update client to its own key and an update-policy rule; watch update-security for refusals.
5. RRL in log only mode: run for a week, review the rate-limit log, then enforce.
6. Privileges and control channel: confirm -u, file ownership, loopback only controls.
7. Sign: enable dnssec-policy on a low risk zone, publish DS, then extend.

Common misconfigurations

• Open resolver on an authoritative server: recursion left on with localnets covering a public subnet, or allow-recursion { any; }; copied from an old tutorial. The server becomes a reflection amplifier.
• Zone transfers to anyone: no allow-transfer restriction, so a single AXFR hands out the full zone, including internal looking host names useful for reconnaissance.
• Updates authorised by IP: allow-update { 10.0.0.5; }; trusts a forgeable source address, exactly what the ARM warns against.
• ACL order mistakes: a broad prefix before a negation, so the excluded address is still allowed because matching stops at the first hit.
• Keys in world readable files: TSIG secrets inside a named.conf with mode 0644, or committed to a configuration repository. Treat this as a credential leak and rotate.
• Running a development or end of life branch: an odd numbered release in production, or a 9.16 server that has had no fixes since April 2024.
• Signature expiry: DNSSEC enabled, but signing breaks because named cannot write its key or zone directory, and validating resolvers start returning SERVFAIL for the whole zone.

Framework mapping

NIST's own DNS deployment guidance is summarised in the NIST SP 800-81 Rev. 3 Secure DNS Deployment Guide.

Practitioner checklist

• Run authoritative and recursive service on separate BIND servers, and set recursion no; on every authoritative server.
• Replace default recursion behaviour with explicit named ACLs for allow-recursion and allow-query-cache, and test from outside.
• Set allow-transfer { none; }; globally and grant transfers per zone by TSIG key only.
• Authorise dynamic updates with per client TSIG keys and update-policy; remove every IP based allow-update.
• Store keys in restricted include files, give each key an owner and rotation date, and rotate any key found in a readable file or repository.
• Enable RRL on authoritative servers in log-only mode, review, then enforce; consider minimal-any.
• Keep rndc on loopback with a protected key, run named with -u, and hide version.
• Ship security, xfer-out, update-security and rate-limit logs to the SIEM with alerts.
• Stay on a supported even numbered branch, subscribe to bind-announce and patch against the ISC vulnerability matrix.
• Sign public zones with dnssec-policy and monitor signature validity.

Standards and references

• ISC: BIND 9 Administrator Reference Manual, Security Configurations
• ISC: BIND 9 Administrator Reference Manual, Configuration Reference
• ISC: BIND 9 Administrator Reference Manual, DNSSEC
• ISC Knowledge Base: BIND Best Practices, Authoritative
• ISC Knowledge Base: Using Response Rate Limiting (RRL)
• ISC Knowledge Base: allow-recursion and allow-query-cache defaults
• ISC Knowledge Base: BIND 9 release status and support policy
• ISC Knowledge Base: BIND 9 Software Vulnerability Matrix

Related NHI Mgmt Group resources: DNS Security Guide · Authoritative DNS and Registrar Account Security Guide · DNS Security Checklist · DNS Hijack Playbook