| This is described in https://datatracker.ietf.org/doc/html/rfc1982, but TL;DR is do two at least two increments smaller than 2^31-1 with 32-bit modulo.
Even simpler in your case:
Switch from 2026nnnn to 4026nnnn, wait for all secondaries to pick the updated zone, then switch to unixtime (1nnnnn).
Imagine the SERIAL as a clock with two handles with 0 at top and 2^31 at the bottom. If you are going shortest distance from A to B clockwise then it is increment, if you are going counterclockwise then it is decrement.
Ondřej --
Ondřej Surý (He/Him)
[email protected]
ADHD brain at work: I sometimes lose track of my inbox. Please feel free to send a gentle nudge if you're waiting on a reply!
My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. Hi Ondřej, Thanks for the suggestion. My zones currently use YYYYMMDDNN serials (e.g. 2026072103), which are numerically higher than the current Unix timestamp. A direct switch to date +%s would therefore decrease the SOA serial. Is there a recommended migration strategy to move from YYYYMMDDNN to Unix timestamp serials? Thanks,
Ajay
Hi Ajay,switch to unixtime serial number and the problem goes away. You will also geta one-second granularity for the updates as free bonus. The YYYYMMDDNNonly allows 100 updates per-day.Ondrej--Ondřej Surý (He/Him)[email protected]ADHD brain at work: I sometimes lose track of my inbox. Please feel free to send a gentle nudge if you're waiting on a reply!My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.On 21. 7. 2026, at 17:12, Ajay Guleria via bind-users <[email protected]> wrote:
Hello BIND Team,
We have deployed automatic DNSSEC signing for a production authoritative zone using BIND 9.18.39.
Environment
• BIND: 9.18.39
• Zone type: Primary
• Configuration:
• inline-signing yes;
• dnssec-policy "default";
rndc zonestatus reports:
serial: 2026072103
signed serial: 2026072300
inline signing: yes
key maintenance: automatic
DNSSEC validation is fully successful:
delv @8.8.8.8 example.com
; fully validated
The DS record has been published at the parent, and validation succeeds using Google Public DNS and Cloudflare.
Observation
The signed zone serial is maintained independently from the source zone serial.
For example:
Unsigned zone:
2026072103
Signed zone:
2026072300
After adding one DNS record:
Unsigned:
2026072103
Signed:
2026072301
This behavior is consistent with the documentation stating that the signed zone maintains its own SOA serial.
Operational issue
Many widely used monitoring tools (MXToolbox, IntoDNS, DNS Spy, and others) interpret the served SOA serial as a YYYYMMDDNN date-based serial.
As a result, they report warnings such as:
SOA Serial Number Format is Invalid
Serial: 2026072300
Serial date was 2026-07-23 which is in the future.
Although DNSSEC validation is correct, these warnings generate operational tickets and user concerns.
Questions
1. Is this independent signed serial expected behavior for BIND 9.18.39 with dnssec-policy and inline-signing?
2. Is there any supported configuration that preserves the source SOA serial in the served signed zone while still allowing automatic signing and automatic key maintenance?
3. If not, would ISC consider adding an optional configuration (for example, a policy or zone option) that allows the served signed zone to retain the source SOA serial where administrators intentionally use YYYYMMDDNN serial numbering?
Thank you for any clarification.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
CAUTION: This email originated from outside of IIT Delhi. Do not click links or open attachments unless you recognize the sender and know the content is safe.
|
