Title

The primary servers in a BIND 9.x implementation must notify authorized secondary name servers when zone files are updated. (Cat II impact)

Discussion

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 Secondary servers are using the correct zone file. When a primary name server notices that the serial number of a zone has changed, it sends a special announcement to all of the secondary name servers for that zone. The primary name server determines which servers are the secondaries 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 primary name servers, it responds with a NOTIFY response. The response tells the primary that the secondary received the NOTIFY announcement so that the primary can stop sending it NOTIFY announcements for the zone. Then the secondary proceeds just as if the refresh timer for that zone had expired: it queries the primary name server for the SOA record for the zone that the primary claims has changed. If the serial number is higher, the secondary transfers the zone. The secondary should issue its own NOTIFY announcements to the other authoritative name servers for the zone. The idea is that the primary may not be able to notify all of the secondary name servers for the zone itself, since it is possible some secondaries cannot communicate directly with the primary (they use another secondary as their primary). Older BIND 8 Secondarys don't send NOTIFY messages unless explicitly configured to do so.

Check Content

If this is a secondary name server, this is Not Applicable. On a primary name server, verify that the global notify is disabled. The global entry for the name server is under the "Options" section and "notify" should be disabled at this section. Inspect the "named.conf" file for the following: options { notify no; }; If the "notify" statement is missing, this is a finding. If the "notify" statement is set to "yes", this is a finding. Verify that each zone is configured to notify authorized secondary name servers when a zone file has been updated. Each zone has its own zone section. Inspect the "named.conf" file for the following: zone example.com { notify explicit; also-notify { <ip_address>; | <address_match_list>; }; If an "address match list" is used, verify that each IP address listed is an authorized secondary name server for that zone. If the "notify explicit" statement is missing, this is a finding. If the "also-notify" statement is missing, this is a finding. If the "also-notify" statement is configured to notify name servers that are not authorized for that zone, this is a finding.

Fix Text

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.

Additional Identifiers

Rule ID: SV-272395r1082259_rule

Vulnerability ID: V-272395

Group Title: SRG-APP-000516-DNS-000088

Expert Comments

CCIs tied to check.

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