Knowledge Base ISC Main Website Ask a Question/Contact ISC
serial-query-rate, notify-rate and startup-notify-rate: how they impact zone transfers in different versions of BIND
Author: Cathy Almond Reference Number: AA-01313 Views: 19328 Created: 2015-10-30 10:45 Last Updated: 2015-10-30 17:22 100 Rating/ 1 Voters

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:

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 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:

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]

This second fix is also included in BIND versions 9.9.8, and 9.10.3.

If you are running BIND 9.9.7, 9.9.7-P*, 9.10.2 or 9.10.2-P*, we recommend upgrading to BIND 9.9.8, 9.10.3 or later

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:

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 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.

If you are using BIND 9.9.7-S*, we recommend upgrading to BIND 9.9.8-S1 or later

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.

© 2001-2018 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.

  • There is no feedback for this article
Quick Jump Menu