Ryan Malloy
8e421f925e
C1 — Document the process-global MsgAcceptFunc mutation: CoreDNS 1.14.3 doesn't expose per-Config MsgAcceptFunc (server.go:159 hardcodes the dns.Server struct), so the override has to be global. The init()-level comment now explains the operational consequences in detail, and setup() emits a loud INFO log calling out the global scope for operator audit. Upstream support for per-Config MsgAcceptFunc would let us delete the whole stanza. C2 — handleUpdate now requires the caller to assert TSIG verification via an explicit `verified bool` parameter. The security contract is encoded in the function signature, not in convention. ServeDNS passes verified=true after checkTSIG succeeds; verified=false produces an immediate Refused with no state mutation. Future internal callers (NOTIFY relay, admin RPC, refactor) physically cannot reach the mutation code without proving the request was authenticated. M9 — Don't sign TSIG-failure rejection responses. Per Hamilton's finding, signing a rejection with the named key attests "yes, this server holds that key" — useful intel for an attacker probing key existence. Unsigned Refused is the right shape: nsupdate sees "no TSIG on reply" and treats as auth failure, which is what actually happened. New test TestUpdate_UnverifiedCaller_Refused proves the C2 contract: handleUpdate(w, msg, false) refuses, zone file unchanged. |
||
|---|---|---|
| .gitignore | ||
| config.go | ||
| go.mod | ||
| go.sum | ||
| plugin.go | ||
| README.md | ||
| setup.go | ||
| setup_test.go | ||
| tsig.go | ||
| update.go | ||
| update_test.go | ||
| zonefile.go | ||
| zonefile_test.go | ||
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).