Ryan Malloy
e9d37f483c
Sets up the package layout for a CoreDNS plugin that will accept RFC 2136 dynamic updates with TSIG authentication, primarily targeting self-hosted ACME DNS-01 cert automation. What this commit gives us: - go.mod against coredns/caddy v1.1.4, coredns/coredns v1.14.3, miekg/dns v1.1.72 - plugin.go: RFC2136 struct + Handler interface (ServeDNS is pass-through) - setup.go: init() registration + Corefile parser (skeleton — recognizes tsig-key, ttl, persist directives but doesn't yet wire them) - README.md, .gitignore go build ./... clean. No tests yet — those come with Phase 1.2 alongside the actual UPDATE handler and in-memory store. Plan: ~/.claude/plans/dood-does-coredns-offer-enumerated-piglet.md
77 lines
2.2 KiB
Markdown
77 lines
2.2 KiB
Markdown
# coredns-rfc2136
|
|
|
|
A [CoreDNS](https://coredns.io) 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.supportedsystems.net/rpm/coredns-rfc2136
|
|
```
|
|
|
|
Then `go get git.supportedsystems.net/rpm/coredns-rfc2136 && make`.
|
|
|
|
## License
|
|
|
|
MIT (TODO: add LICENSE file).
|