Knowledge Base ISC Main Website Ask a Question/Contact ISC
How does BIND choose the master for a zone refresh (zone timer or notify)?
Author: Cathy Almond Reference Number: AA-01467 Views: 4585 Created: 2017-03-08 15:18 Last Updated: 2017-07-14 13:17 0 Rating/ Voters

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

zone “zone.test.com” IN {
      type slave;
      file “zone.test.com”;
      masters {192.0.2.10; 192.0.2.11; 192.0.2.12; };
};

'masters' in this context means 'any server that is authoritative'

The term 'masters' here doesn't mean that the servers listed have to have the zone configured as 'master' - 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.  Slave servers can provide zone updates to other slaves.

Zone refreshes on timer

Without any notifies being received at all, named will periodically instigate a zone refresh for a slave - 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 slave.

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 master being queried returns the same (or smaller) SOA than the slave is currently serving.

On the first SOA received that is bigger than the one than the slave 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 slave 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 masters' 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 slaves will always converge their SOA serial numbers to the most up-to-date version.

Q&As

  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 slave 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 masters 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 master 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 masters.  The current process (in which BIND always tries the listed masters in the same sequence) ensures that the most up to date version of the zone always reaches all slaves, 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 masters 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 slave 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 masters 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 masters list that named encounters has a more recent, but not the most recent version of the zone, that master will itself be updating again soon and therefore will send out a new notify when it does so,



© 2001-2017 Internet Systems Consortium

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Feedback
  • There is no feedback for this article
Quick Jump Menu