serial-query-rate (default 20) is a rate-limiter, that has been used
to 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 an
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.
Until recently, BIND managed notifies and SOA refresh queries in a single
queue (which sometimes caused problems for slaves that are also masters
for other servers). Several changes have been 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:
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 slaves.
To mitigate this effect, from BIND versions 9.9.7 and 9.10.2, we started prioritizing notifies due to changes over those due restarting (or reloading) named:
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:
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:
wrong rate limiter queue. [RT #40350]
This second fix is also included in BIND versions 9.9.8, and 9.10.3.
This advice is intended for those running authoritative servers that generate high rates of notifies from large numbers of different zones in order to ensure that they have changes 4181 and 4143 as well as change 3955.
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). This is planned for 9.11.0 but has already been released in the Stable Preview (subscription) edition of BIND from 9.9.7-S1 onwards:
startup-notify-rate instead of serial-query-rate.
serial-query-rate continues to control the rate at which SOA refresh queries are issued by slave 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.
Whilst BIND 9.9.7-S1 provides an early preview of the new configuration options, on top of the separation of the three queues that is introduced in Open Source BIND 9.9.7, it is based on BIND 9.9.7 and is therefore missing change 4181, leaving servers that have high rates of outgoing notifies vulnerable to the possibility of experiencing problems due to the race condition mentioned above.