serial-query-rate, notify-rate and startup-notify-rate: how they impact zone transfers in different versions of BIND

This article has been retained in our Knowledge Base since it is of historic interest, but has been replaced by information that relates to currently-supported versions of BIND. See Rate-limiters for authoritative zone propagation.

serial-query-rate (default 20) is a rate-limiter that has been used for a long time to control both the rate of notifies and of zone refresh (SOA queries).

Although the limit is expressed as a per-second rate, it is the actions that are being limited, not the network packets needed to complete the action.  So for example, in the case of a zone refresh, there may multiple queries sent as named retries if no response is received, or tries different authoritative servers.

In the past, BIND 9 managed notifies and SOA refresh queries in a single queue (which sometimes caused problems for secondaries that are also primaries for other servers).  Several changes were made to mitigate the problems of fine-tuning BIND servers to optimize zone update propagation.

Step 1: Separate queues for notifies and SOA refresh queries

To ensure that notifies and refreshes were not competing with each other, in BIND versions 9.6-ESV-R11, 9.8.7, 9.9.5 and 9.10.0 we introduced independent queues - both still with serial-query-rate controlling them:

3650.    [tuning]    Use separate rate limiting queues for refresh and 
                     notify requests. [RT #30589]

Step 2: Separate queues for startup notifies and notifies due to zone changes

Another behavior that was becoming an issue for several production environments is that when restarting an authoritative server that hosts a large number of zones, named will, after loading the zone files, send out notifications for all of them.  This is because although the human DNS administrator may know that nothing has changed in the zone data, named itself doesn't know this.  With this backlog of start-up notifies, it could take some time for zone updates that occurred soon after restarting, to propagate to the secondaries.

To mitigate this effect, we started prioritizing notifies due to changes over those due restarting (or reloading) named:

3955.    [bug]        Notify messages due to changes are no longer queued
                      behind startup notify messages. [RT #24454]

This is implemented as two separate queues - still being rate-limited by serial-query-rate .

The astute readers of the 9.9.8 and 9.10.3 CHANGES log may also notice this bug fix that was added subsequent to the 9.9.7 and 9.10.2 release:

4143.    [bug]        serial-query-rate was not effective for notify.
                      [RT #39858]

In fact, serial-query-rate was not influencing the new separate notify and startup-notify queues as intended, so they were defaulting to 20.  But more importantly, we accidentally introduced a more serious defect that can sometimes cause named to hang when handling high rates of notifies following a restart or reload:

4181.    [bug]        Queued notify messages could be dequeued from the
                      wrong rate limiter queue. [RT #40350] 

Step 3: Separate configuration options so that all three queues can be controlled independently

The final change that has been implemented to aid administrators is the introduction of three separate configuration options - one for each queue (refresh queues, notifies and start-up notifies).

3956.    [func]        Notify messages are now rate limited by notify-rate and
                       startup-notify-rate instead of serial-query-rate.
                       [RT #24454]

serial-query-rate continues to control the rate at which SOA refresh queries are issued by secondary servers. notify-rate takes over as a configuration option for normal notifies (those sent out when a zone has been updated).  startup-notify-rate allows the administrator to configure independently the rate at which notifies are sent out after restarting or reloading.

For all three of these, the default remains at 20, which may be too low for many production environments.  Administrators however are encouraged to increase the values of serial-query-rate and notify-rate gradually to find the levels that meet their production
environment's requirements.  For more advice on tuning configurations for high volume propagation of zone updates, we recommend: Tuning your BIND configuration effectively for zone transfers (particularly with many frequently-updated zones)

Other administrators may wish to disable start-up notifies entirely.  This is currently not possible, but a startup-notify-rate of 1 (a setting of 0 will be silently increased to 1) will slow the rate of these notifications to an insignificant trickle.  They will also, in any case, be removed from the start-up notify queue, if their zone is updated as part of regular zone maintenance.

Standard notifies take precedence over all start-up notifies.