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.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list.
