Detections
Analytics

BIND-9X-001058 - The secondary name servers in a BIND 9.x implementation must be configured to initiate zone update notifications to other authoritative zone name servers - zone allow-notify

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

It is important to maintain the integrity of a zone file. The serial number of the SOA record is used to indicate to secondary name server that a change to the zone has occurred and a zone transfer should be performed. The serial number used in the SOA record provides the DNS administrator a method to verify the integrity of the zone file based on the serial number of the last update and ensure that all slave servers are using the correct zone file.
When a primary master name server notices that the serial number of a zone has changed, it sends a special announcement to all of the slave name servers for that zone. The primary master name server determines which servers are the slaves for the zone by looking at the list of NS records in the zone and taking out the record that points to the name server listed in the MNAME field of the zone's SOA record as well as the domain name of the local host.
When a secondary name server receives a NOTIFY announcement for a zone from one of its configured master name servers, it responds with a NOTIFY response. The response tells the master that the slave received the NOTIFY announcement so that the master can stop sending it NOTIFY announcements for the zone. Then the slave proceeds just as if the refresh timer for that zone had expired: it queries the master name server for the SOA record for the zone that the master claims has changed. If the serial number is higher, the slave transfers the zone.
The slave should next issue its own NOTIFY announcements to the other authoritative name servers for the zone. The idea is that the primary master may not be able to notify all of the slave name servers for the zone itself, since it's possible some slaves can't communicate directly with the primary master (they use another slave as their master). Older BIND 8 slaves don't send NOTIFY messages unless explicitly configured to do so.

Solution

Edit the 'named.conf' file.

Configure the 'notify' sub statement in the 'options' statement block to 'no':

options {
notify no;
};

Configure the 'notify explicit' and 'also-notify' sub statements in the zone statement block to limit zone transfer notifications to authorized secondary name servers:

zone example.com {
notify explicit;
also-notify { <ip_address>; | <address_match_list>; };

Restart the BIND 9.x process.

See Also

https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_BIND_9-x_V2R2_STIG.zip

Item Details

Category: SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|SC-22, CAT|III, CCI|CCI-000366, Rule-ID|SV-207556r612253_rule, STIG-ID|BIND-9X-001058, STIG-Legacy|SV-87035, STIG-Legacy|V-72411, Vuln-ID|V-207556

Plugin: Unix

Control ID: c9ae6f7c51eeb0caf61992f1a1bcb7e5da0b12991e1bed4f786498b97f9e9edf