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

[Ajay Guleria]

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

Is this independent signed serial expected behavior for BIND 9.18.39 with dnssec-policy and inline-signing?

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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20260721/60165aa5/attachment.htm>