UCF STIG Viewer Logo

On the BIND 9.x server the private keys corresponding to both the ZSK and the KSK must not be kept on the BIND 9.x DNSSEC-aware primary authoritative name server when the name server does not support dynamic updates.


Overview

Finding ID Version Rule ID IA Controls Severity
V-207572 BIND-9X-001134 SV-207572r612253_rule Medium
Description
The private keys in the KSK and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored off-line (with respect to the Internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. This strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets. The private key corresponding to the key-signing key (KSK-private) can still be kept off-line.
STIG Date
BIND 9.x Security Technical Implementation Guide 2021-06-23

Details

Check Text ( C-7827r283770_chk )
If the server is in a classified network, this is Not Applicable.

Determine if the BIND 9.x server is configured to allow dynamic updates.

Review the "named.conf" file for any instance of the "allow-update" statement. The following example disables dynamic updates:

allow-update {none;};

If the BIND 9.x implementation is not configured to allow dynamic updates, verify with the SA that the private ZSKs and private KSKs are stored offline, if not, this is a finding.
Fix Text (F-7827r283771_fix)
Remove any ZSK or KSK private key from any BIND 9.x server that does not support dynamic updates.

Note: Any ZSK or KSK that is not needed to support dynamic updates should be stored offline in a secure location.