How does BIND choose the primary for a zone refresh (zone timer or notify)?
  • 04 May 2021
  • 5 Minutes to read
  • Contributors
  • Dark
  • PDF

How does BIND choose the primary for a zone refresh (zone timer or notify)?

  • Dark
  • PDF

Article Summary

BIND secondary servers update their zone content from one of the list of primaries that they have configured in named.conf:

zone “” IN {
     type secondary;
     file “”;
     primaries {;;; };
"primaries" in this context means "any server that is authoritative"
The term "primaries" here doesn't mean that the servers listed have to have the zone configured as "primary" - it just means that these servers so listed are authoritative for the zone and can provide a zone update if one is requested of them. Secondary servers can provide zone updates to other secondaries.

Zone refreshes on timer

Without any notifies being received at all, named will periodically instigate a zone refresh for a secondary - which means that it will send SOA queries to the servers in the list to see if it can find one that returns an SOA with a larger serial number than the one currently being served by the secondary.

The servers are queried in turn - named moves on to the next server in the list if either:

  • It is unable to get a response from the server it is currently querying (this might be no response or an error response).
  • The primary being queried returns the same (or smaller) SOA than the secondary is currently serving.

On the first SOA received that is bigger than the one than the secondary is currently serving, then named will initial a zone transfer with that server. Once the zone transfer has been received and the zone has been updated, then this zone refresh is complete - named does not continue to try the other servers to see if one of them has a yet bigger SOA.

The frequency with which this type of refresh takes place is controlled by the settings in the zone's SOA record.

Zone refreshes on receipt of notify

If a valid notify is received where the notify carries a serial number larger than the one in the SOA currently served by the slave then the secondary zone will again schedule a zone refresh, following exactly the same process it would use if the zone refresh was initiated on timer - i.e. it behaves exactly as if the zone refresh timer has expired.

A notify is deemed valid if the sender is one of the servers in the NS RRset for the zone, has been explicitly allowed using an "allow-notify" clause, or is from an address listed in the primary servers clause.

receipt of a "notify" does not cause named to first query the sender of the notify
This seems unintuitive to many when they learn this for the first time, but it vastly simplifies the code/algorithm for handling refreshes on notify and also ensures, by using the same sequence of SOA checks each time, that the secondaries will always converge their SOA serial numbers to the most up-to-date version.


  1. What happens if a notify is received while named already has a refresh in progress (or queued)?

    The serial number of the notify is checked and it is discarded if it is not larger than the currently-served zone's SOA serial number.  If it is larger, and if there is not a queued refresh already, then named queues another refresh for the zone.  This is to ensure that named always tries to update again in the situation where the in-progress zone refresh might not be obtaining the most up-to-date version.

  2. Why does named sometimes queue a refresh for a zone?

    For each secondary zone, named can handle an active refresh in-progress, and another one queued up to be processed when resources and/or configuration permit.  There are various tuning options for zone refreshes, and these may cause a refresh to be delayed rather than being processed immediately.  See Tuning your BIND configuration effectively for zone transfers (particularly with many frequently-updated zones)

  3. What happens if named cannot get a response from a server in the primaries list?

    If there are more servers in the list to try, then named moves on to try the next server, otherwise it finishes this refresh cycle.  The problem primary server will temporarily cached as 'unreachable' and won't be retried for future transfers until at least 10 minutes has passed since it was last discovered to be unreachable or until a notify is received from it.

  4. Why does named schedule a refresh rather than simply requesting a zone transfer from the server that notified it?

    It is often not possible to refresh immediately on receipt of a notify, and in the interim there may have been other updates to other primaries.  The current process (in which BIND always tries the listed primaries in the same sequence) ensures that the most up to date version of the zone always reaches all secondaries, even though it may take more than one refresh in some situations.

  5. For queued refreshes, does named track which server sent the notify?

    This is logged and it's also recorded, but the sender's address is not used when the zone refresh is actioned - named works through the primaries list from the beginning each time.

  6. For queued refreshes, does named track the serial number on the notify?

    This is logged, but it is not stored.  The serial number on received notifies are used only to compare with the currently-served secondary zone's SOA - if not larger than the current zone, then they are discarded.  If bigger, then a refresh is scheduled or queued (if there is already an ongoing refresh).

  7. Why doesn't named query all of the servers on the primaries list and then transfer from the one with the biggest SOA serial number?

    It is more efficient overall to rely on the fact that there will be subsequent notifies received if the first server encountered with a newer version of the zone than the one currently being served is the one that named initiates a zone transfer from rather than continuing to test all the servers in the list.  Providing that all servers are correctly configured (to notify, accept refresh queries and allow transfers), convergence of all servers to having the same and current version of the zone is guaranteed.

  8. Why does named discard valid notifies when there is already one refresh queued-up?

    It's not necessary to queue more than one refresh.  Even if the first server in the primaries list that named encounters has a more recent, but not the most recent version of the zone, that primary will itself be updating again soon and therefore will send out a new notify when it does so.