Environment
- Technitium DNS Server v14.3 (also inspected v15.4.0 source —
AuthZoneManager.cs / SecondaryZone.cs behavior unchanged)
- Primary (ns1) + Secondary (ns2), NOTIFY working, zone transfers over TCP
Problem
When the primary's serial advances multiple times within seconds (our case: Let's Encrypt DNS-01 — Traefik adds/removes _acme-challenge TXT records rapidly, each bumping the serial), the secondary's incremental transfer can fail during condensing:
System.InvalidOperationException: Current SOA serial does not match with the IXFR difference sequence deleted SOA.
at TechnitiumLibrary.Net.Dns.AuthZoneManager.CondenseIncrementalZoneTransferRecords(...)
When this happens the refresh hard-fails and the secondary keeps serving the stale zone. There is no automatic fallback to a full AXFR — the zone only recovers via a manual resync (which does perform AXFR) or, sometimes, a later IXFR that happens to line up.
Practical impact: with ACME DNS-01, remote validation vantage points hitting the stale secondary see the wrong _acme-challenge TXT and Let's Encrypt rejects with 403 unauthorized :: During secondary validation: Incorrect TXT record. Certificate issuance fails cluster-wide until someone manually resyncs the zone.
Expected behavior
Per RFC 1995 §4 spirit: if the incremental transfer cannot be applied/condensed, the secondary should retry with a full AXFR instead of failing the refresh. Manual resync already proves AXFR recovers the zone — the same path just isn't taken automatically on IXFR condense failure.
Related
Request
Either (a) fall back to AXFR automatically when CondenseIncrementalZoneTransferRecords throws, or (b) provide a per-zone "use AXFR only" option for secondaries. (a) seems strictly safe since the condense failure already means the IXFR diff sequence is unusable.
We currently work around this with an external watchdog that compares SOA serials primary-vs-secondary and calls /api/zones/resync when a zone is stuck — happy to share details.
Environment
AuthZoneManager.cs/SecondaryZone.csbehavior unchanged)Problem
When the primary's serial advances multiple times within seconds (our case: Let's Encrypt DNS-01 — Traefik adds/removes
_acme-challengeTXT records rapidly, each bumping the serial), the secondary's incremental transfer can fail during condensing:When this happens the refresh hard-fails and the secondary keeps serving the stale zone. There is no automatic fallback to a full AXFR — the zone only recovers via a manual resync (which does perform AXFR) or, sometimes, a later IXFR that happens to line up.
Practical impact: with ACME DNS-01, remote validation vantage points hitting the stale secondary see the wrong
_acme-challengeTXT and Let's Encrypt rejects with403 unauthorized :: During secondary validation: Incorrect TXT record. Certificate issuance fails cluster-wide until someone manually resyncs the zone.Expected behavior
Per RFC 1995 §4 spirit: if the incremental transfer cannot be applied/condensed, the secondary should retry with a full AXFR instead of failing the refresh. Manual resync already proves AXFR recovers the zone — the same path just isn't taken automatically on IXFR condense failure.
Related
Request
Either (a) fall back to AXFR automatically when
CondenseIncrementalZoneTransferRecordsthrows, or (b) provide a per-zone "use AXFR only" option for secondaries. (a) seems strictly safe since the condense failure already means the IXFR diff sequence is unusable.We currently work around this with an external watchdog that compares SOA serials primary-vs-secondary and calls
/api/zones/resyncwhen a zone is stuck — happy to share details.