Inline-signing / dnssec-policy: Signed SOA serial diverges from source serial causing monitoring warnings
Ajay Guleria via bind-users <[email protected]> Tue, 21 Jul 2026 20:42:28 +0530
| Newsgroups | gmane.network.dns.bind9.user,gmane.network.dns.bind.user |
|---|---|
| Message-ID | <[email protected]> |
--===============5419845077408741200== Content-Type: multipart/alternative; boundary="Apple-Mail=_00BCDE99-6C61-4F48-96E5-C30EE17D5217" --Apple-Mail=_00BCDE99-6C61-4F48-96E5-C30EE17D5217 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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.= --Apple-Mail=_00BCDE99-6C61-4F48-96E5-C30EE17D5217 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii <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> --Apple-Mail=_00BCDE99-6C61-4F48-96E5-C30EE17D5217-- --===============5419845077408741200== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list. --===============5419845077408741200==--