Title

The BIND 9.x server implementation must uniquely identify and authenticate the other DNS server before responding to a server-to-server transaction, zone transfer and/or dynamic update request using cryptographically based bidirectional authentication to protect the integrity of the information in transit. (Cat I impact)

Discussion

Server-to-server (zone transfer) transactions are provided by TSIG, which enforces mutual server authentication using a key that is unique to each server pair (TSIG), thus uniquely identifying the other server. DNS does perform server authentication when TSIG is used, but this authentication is transactional in nature (each transaction has its own authentication performed). Enforcing mutually authenticated communication sessions during zone transfers provides the assurance that only authorized servers are requesting and receiving DNS zone data. Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Failure to properly implement transactional security may have significant effects on the overall security of the DNS infrastructure. The lack of mutual authentication between name servers during a DNS transaction would allow a threat actor to launch a Man-In-The-Middle attack against the DNS infrastructure. This attack could lead to unauthorized DNS zone data being introduced, resulting in network traffic being redirected to a rogue site. Satisfies: SRG-APP-000158-DNS-000015, SRG-APP-000390-DNS-000048, SRG-APP-000394-DNS-000049, SRG-APP-000395-DNS-000050, SRG-APP-000439-DNS-000063, SRG-APP-000440-DNS-000065

Check Content

If zone transfers are disabled with the "allow-transfer { none; };" directive, this is Not Applicable. If the server is in a classified network, this is Not Applicable. Verify that the BIND 9.x server is configured to uniquely identify a name server before responding to a zone transfer. Inspect the "named.conf" file for the presence of TSIG key statements: On the master name server, this is an example of a configured key statement: key tsig_example. { algorithm hmac-SHA1; include "tsig-example.key"; }; zone "disa.mil" { type master; file "db.disa.mil"; allow-transfer { key tsig_example.; }; }; On the slave name server, this is an example of a configured key statement: key tsig_example. { algorithm hmac-SHA1; include "tsig-example.key"; }; server <ip_address> { keys { tsig_example }; }; zone "disa.mil" { type slave; masters { <ip_address>; }; file "db.disa.mil"; }; If a master name server does not have a key defined in the “allow-transfer” block, this is a finding. If a secondary name server does not have a server statement that contains a "keys" sub statement, this is a finding.

Fix Text

Configure the BIND 9.x server to use TSIG keys. Add a key statement to the "named.conf" file for TSIG that is being used: key tsig_example. { algorithm hmac-SHA1; include "tsig-example.key"; }; Add key statements to the allow-transfer statements on a master name server: allow-transfer { key tsig_example.; }; Add key statements to the server statements on a secondary name server: server <ip_address> { keys { tsig_example }; }; Restart the BIND 9.x process.

Additional Identifiers

Rule ID: SV-207561r879599_rule

Vulnerability ID: V-207561

Group Title: SRG-APP-000158-DNS-000015

Expert Comments

CCIs tied to check.

Controls tied to check. These are derived from the CCIs shown above.