<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=us-ascii"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><p>Hello BIND Team,</p><p>We have deployed automatic DNSSEC signing for a production authoritative zone using BIND 9.18.39.</p><h3>Environment</h3><ul><li><p>BIND: 9.18.39</p></li><li><p>Zone type: Primary</p></li><li><p>Configuration:</p><ul><li><p>inline-signing yes;</p></li><li><p>dnssec-policy "default";</p></li></ul></li></ul><p><code inline="">rndc zonestatus</code> reports:</p><pre><code>serial: 2026072103
signed serial: 2026072300
inline signing: yes
key maintenance: automatic
</code></pre><p>DNSSEC validation is fully successful:</p><pre><code>delv @8.8.8.8 example.com
; fully validated
</code></pre><p>The DS record has been published at the parent, and validation succeeds using Google Public DNS and Cloudflare.</p><h3>Observation</h3><p>The signed zone serial is maintained independently from the source zone serial.</p><p>For example:</p><pre><code>Unsigned zone:
2026072103
Signed zone:
2026072300
</code></pre><p>After adding one DNS record:</p><pre><code>Unsigned:
2026072103
Signed:
2026072301
</code></pre><p>This behavior is consistent with the documentation stating that the signed zone maintains its own SOA serial.</p><h3>Operational issue</h3><p>Many widely used monitoring tools (MXToolbox, IntoDNS, DNS Spy, and others) interpret the served SOA serial as a YYYYMMDDNN date-based serial.</p><p>As a result, they report warnings such as:</p><pre><code>SOA Serial Number Format is Invalid
Serial: 2026072300
Serial date was 2026-07-23 which is in the future.
</code></pre><p>Although DNSSEC validation is correct, these warnings generate operational tickets and user concerns.</p><h3>Questions</h3><ol><li><p>Is this independent signed serial expected behavior for BIND 9.18.39 with <code inline="">dnssec-policy</code> and <code inline="">inline-signing</code>?</p></li><li><p>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?</p></li><li><p>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?</p></li></ol><p>Thank you for any clarification.</p></body></html>