Ryan Malloy
1cca9a5aa7
ServeDNS now answers authoritatively for the configured zone(s): - Apex SOA → synthetic SOA (serial = store generation counter) - Apex NS → synthetic NS pointing at p.Nameserver - In-store lookups for any qtype - NODATA vs NXDOMAIN correctly distinguished (SOA in authority section) - UPDATE opcode → REFUSED (Phase 1.4 implements properly) - Queries outside our zones pass through to Next Added: - store.go: recordStore with sync.RWMutex + atomic generation counter. Operations: Add (de-dupes), RemoveRRset, RemoveRR, RemoveName, Lookup (returns a copy so callers can't corrupt internal state), NameExists. All keyed on canonical lowercase + trailing-dot names. - plugin.go: ServeDNS dispatch, findZone (longest-suffix match), syntheticSOA, syntheticNS. New Nameserver field. - setup.go: nameserver directive. Default Nameserver = first zone apex. Store initialised at parse time. - store_test.go: 12 unit tests covering add/dedupe/remove/lookup/ generation/case-insensitivity/copy-safety. - plugin_test.go: 10 dispatch tests covering pass-through, apex synthetics, in-store lookups, NXDOMAIN/NODATA semantics, UPDATE refusal, findZone longest-suffix-wins and case behavior. - setup_test.go: 3 new cases for the nameserver directive + store init. Total: 38 tests passing. Module: git.supported.systems/rsp2k/coredns-rfc2136
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).