UCF STIG Viewer Logo

The DNS software administrator will configure each master/slave server supporting a zone to cryptographically authenticate zone transfers.


Overview

Finding ID Version Rule ID IA Controls Severity
V-4482 DNS0455 SV-4482r2_rule DCNR-1 High
Description
A slave updates its zone information by requesting a zone transfer from its master. In this transaction, the risk for the slave is that the response to its request is not in fact from its authorized master but from an adversary posing as the master. In this scenario, such an adversary would be able to modify and insert records into the slaves zone at will. To protect against this occurrence, the slave must be able to authenticate the master to provide assurance that any zone updates are valid.
STIG Date
BIND DNS STIG 2015-10-01

Details

Check Text ( C-3531r1_chk )
BIND

Instruction: This check is only applicable to slave servers. If there is not an allow-transfer phrase within the zone statement, then this is a CAT I finding. If there is an allow-transfer statement, there must be a TSIG key corresponding to each of the zone partners. The reviewer can validate this by examining the key and server statements within named.conf. Check the keys phrase within each of the server statements. Verify the key statement is configured to cryptographically authenticate the master name server; an example is provided below, if this is not configured, then this is a finding.

On the master name server, this is an example of a configured key statement:

key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil. {
algorithm hmac-md5;
include "/etc/dns/keys/tsig-example.key";
};

zone “disa.mil” {
type master;file “db.disa.mil”;
allow-transfer { key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil.; };
};
On the slave name server, this is an example of a configured key statement:

key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil. {
algorithm hmac-,d5;
include "/etc/dns/keys/tsig-example.key";
};

server 10.2.2.2 {
keys {ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil};
};

zone “disa.mil” {
type slave;
masters { 10.1.1.1; };
file “db.disa.mil”;
};

A violation of this requirement can have one of two severity levels depending upon the extent of the violation. If slaves do not authenticate master servers in any manner, then the discrepancy would be a Category I finding. If some form of authentication exists (i.e., based on IP address), but it is not based on cryptography, then the discrepancy would be a Category II finding.

Windows 2000/2003 DNS:

Instruction: This check only applies if the name server is not active directory integrated. If the Windows DNS zone type is not active directory integrated, then the open the DNS management console snap-in, right click on the zone and select properties. If name servers tab has entries, then this will still be a CAT II finding. If the name servers tab does not have entries, then this is a CAT I.

In cases in which the name server is not running BIND or Windows DNS, the reviewer must still examine the configuration and its documentation to validate this requirement.
Mitigation:
A violation of this requirement can have one of two severity levels depending upon the extent of the violation. If slaves do not authenticate masters in any manner, then the discrepancy would be a Category I finding. If some form of authentication exists (i.e., based on IP address), but it is not based on cryptography, then the discrepancy would be a Category II finding.
Fix Text (F-4367r1_fix)
The DNS software administrator should configure each slave supporting a zone to cryptographically authenticate its master before accepting zone updates.