Ryan Malloy
8466f08780
The previous YYYYMMDDNN encoding capped at NN=99 (100 bumps/day) and hard-failed UPDATEs once the day's counter was exhausted — confirmed in production on 2026-05-22 when ACME activity across the supported. systems zone hit the cap and SERVFAILed every subsequent UPDATE. New format: YYMMDD*10000+NNNN. With 4-digit NNNN we get 10000/day, and dropping the century keeps a 2026-dated serial (2,605,229,999 max) under uint32's 4,294,967,295 ceiling. A 4-digit year (e.g., 20260522*10000) would overflow uint32 — RFC 1035's SOA serial type bounds this. Three behavior changes: 1. On NNNN=9999, roll forward to the next encoded day with NNNN=0001 rather than erroring. The encoded date drifts ahead of wall time on heavy churn days and catches up on quiet days; monotonic ordering (the only DNS requirement) holds. 2. Future-encoded serials (from a prior rollover) are honoured — the previous "older date" branch downgraded them back to today*100+1, producing a backwards serial. This bug also tripped a manual workaround on the same day. Now: future encoded dates bump their own NNNN. 3. Legacy YYYYMMDDNN serials migrate automatically on first bump. A value like 2026052299 (~2.026B) is numerically smaller than today's new-format minimum 2605220001 (~2.605B), so the older-or-unparseable branch fires and rewrites in place. New > old, so AXFR receivers treat it as a clean forward bump. Tests cover same-day, rollover, future-encoded no-regress, legacy migration, non-CalVer reset, and no-SOA error.
coredns-rfc2136
A CoreDNS plugin that accepts RFC 2136 dynamic DNS updates (TSIG-authenticated), filling a gap in the official plugin set.
CoreDNS as-shipped has no plugin for accepting dynamic updates — its
plugin model treats authoritative data as read-only (loaded from auto,
file, secondary, etc.). This plugin adds the missing piece.
Primary use case: self-hosted ACME DNS-01
The motivating problem: automate Let's Encrypt cert issuance for many domains without depending on registrar APIs (Vultr/Route53/Cloudflare). The architecture:
_acme-challenge.example.com CNAME <uuid>.auth.supported.systems
│
│ delegated NS to your CoreDNS host
▼
CoreDNS + rfc2136 plugin
│
│ accepts TSIG UPDATEs from Caddy
│ (caddy-dns/rfc2136) or any other
│ ACME client
▼
Let's Encrypt validates
One-time per protected domain: add a CNAME glue line in your static
zones. After that, all cert issuance + renewal happens via UPDATE
messages — zero static zone-file churn.
Status
Phase 1 (skeleton): compiles, registers with CoreDNS, parses the
Corefile directive. Does not yet handle UPDATE messages or serve any
records. ServeDNS is a pass-through. See phases.md for the roadmap.
Configuration
rfc2136 <zone> [<zone>...] {
tsig-key <key-name> <algorithm> <base64-secret>
ttl <seconds>
persist <path>
}
Example:
.:53 auth.example.com {
rfc2136 auth.example.com {
tsig-key acme-key. hmac-sha256 BASE64SECRET==
ttl 60
}
errors
log
}
Building
This plugin is consumed by a custom CoreDNS build via plugin.cfg:
# In CoreDNS source's plugin.cfg, BEFORE the `cache` plugin:
rfc2136:git.supported.systems/rsp2k/coredns-rfc2136
Then go get git.supported.systems/rsp2k/coredns-rfc2136 && make.
License
MIT (TODO: add LICENSE file).