Since DNS zones do not use locking, they are vulnerable to a race which manifest e.g. when users are hard-deleted in bulk. Zone serial is incremented immediately on each change, but there's no guarantee of transaction execution order. So, for example, there may be two chains like:
- Chain
A sets serial 36
- Chain
B sets serial 37
Now, especially when deleting users, there are many transactions to delete VPS, snapshots, datasets, etc., and those take an arbitrary amount of time. This may result in chain B being done first, meaning the serial is set to 37. Then chain A finishes as well and sets the serial to 36, i.e. a lower value. This zone update is then ignored by secondaries and so we end up with a serial mismatch between the primary and secondaries.
Since DNS zones do not use locking, they are vulnerable to a race which manifest e.g. when users are hard-deleted in bulk. Zone serial is incremented immediately on each change, but there's no guarantee of transaction execution order. So, for example, there may be two chains like:
Asets serial 36Bsets serial 37Now, especially when deleting users, there are many transactions to delete VPS, snapshots, datasets, etc., and those take an arbitrary amount of time. This may result in chain
Bbeing done first, meaning the serial is set to 37. Then chainAfinishes as well and sets the serial to 36, i.e. a lower value. This zone update is then ignored by secondaries and so we end up with a serial mismatch between the primary and secondaries.