Hi, After upgrading our fleet of slave servers from 2.5.4 to 2.6.4, I noticed that, on a few slaves, a large zone that changes rapidly is now consistently behind the master to a larger degree that we consider normal. By "behind", I mean that the serial number reported by the slave in the SOA record is less than reported the master server. Normally we expect small differences between the serial on the master and the slaves because our zones change rapidly. These differences are often transient. However, after the upgrade, a subset of the slaves (always the same ones) have a much larger difference. Fortunately, the difference does not increase without bound. The hosts in question seem powerful enough: one has 8 2gHz Xeons and 32G RAM, which is less powerful than some of the hosts that are keeping up. It may be more a case of their connectivity. Two of the affected slaves are in the same location. For now, I've downgraded these slaves back to 2.5.4, and they are able to keep up again. Is there a change that would be an obvious culprit for this or is something that we could tune? One final piece of information: We always apply the change contained in the ecs-patch branch (which returns ECS data if the client requests it). I don't know if the effect of this processing is significant. We do need it as part of some ongoing research we're conducting. Chuck

No luck so far. We already had zonefile-sync set to -1 (no sync). I tried running with journal-db-mode: asynchronous for a while, then switched to journal-content: none. In both cases, the slave fell behind again after several minutes of operation. Chuck