Inline-signing / dnssec-policy: Signed SOA serial diverges from source serial causing monitoring warnings

[Ajay Guleria]

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ý <ondrej at isc.org> 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)
> ondrej at isc.org <mailto:ondrej at isc.org>
> 
> 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 <bind-users at lists.isc.org <mailto:bind-users at lists.isc.org>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20260721/bdea2229/attachment-0001.htm>