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 > On 21 Jul 2026, at 10:06 PM, Ondřej Surý <[email protected]> wrote: > > Hi Ajay, > > switch to unixtime serial number and the problem goes away. You will also get > a one-second granularity for the updates as free bonus. The YYYYMMDDNN > only allows 100 updates per-day. > > Ondrej > -- > Ondřej Surý (He/Him) > [email protected] <mailto:[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] <mailto:[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.
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
