coredns/caddy/Dockerfile

# Custom Caddy build that bundles the Vultr DNS provider plugin.
# Stock caddy:2 doesn't include DNS-provider modules — they're plugins.
# xcaddy compiles them in at build time.
FROM caddy:2.10.0-builder AS builder
# The Caddy builder image bakes in Go 1.23, but caddy-dns/vultr now
# requires Go >= 1.24. GOTOOLCHAIN=auto lets `go get` fetch a newer
# toolchain on demand so we don't have to bump base images every time
# a plugin's minimum Go version moves.
ENV GOTOOLCHAIN=auto
RUN xcaddy build \
    --with github.com/caddy-dns/vultr \
    --with github.com/caddy-dns/rfc2136

FROM caddy:2.10.0
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
coredns: production Let's Encrypt cert via Caddy sidecar (DNS-01 + Vultr) Replaces the self-signed dev cert flow with a real LE prod cert for dns.l.supported.systems, issued and auto-renewed by a Caddy sidecar using DNS-01 challenge against the Vultr API. Components: - caddy/Dockerfile builds Caddy 2.10.0 with caddy-dns/vultr plugin via xcaddy. GOTOOLCHAIN=auto so xcaddy can fetch newer Go on demand when plugin versions advance their minimum Go. - caddy/Caddyfile uses DNS-01 with explicit public resolvers (1.1.1.1, 9.9.9.9) for the propagation check. Without that, Docker's embedded DNS leaks the container into the host's split-horizon LAN DNS, which returns LAN IPs for ns1.vultr.com and the propagation check fails. - docker-compose: caddy service shares ./caddy-data with coredns via a read-only subpath mount that excludes /acme (account private key). - Healthcheck doubles as a symlinker: maintains stable cert.pem / key.pem names at /data/caddy/ and chmods cert files + their dirs to be readable by CoreDNS's nonroot user. Flips to "healthy" only once the symlinks dereference (i.e. cert exists), gating CoreDNS start via depends_on: service_healthy. - Corefile unchanged — same /etc/coredns/certs/cert.pem path; only the bind-mount source switches from ./certs to ./caddy-data/caddy. - New Makefile target: tls-up orchestrates the bring-up sequence. Cert is valid until Aug 12 2026. Verified end-to-end: dig @127.0.0.1 -p 8853 +tls +tls-hostname=dns.l.supported.systems ... dig @127.0.0.1 -p 8443 +https +tls-hostname=dns.l.supported.systems ... 2026-05-14 01:34:57 -06:00			`# Custom Caddy build that bundles the Vultr DNS provider plugin.`
			`# Stock caddy:2 doesn't include DNS-provider modules — they're plugins.`
			`# xcaddy compiles them in at build time.`
			`FROM caddy:2.10.0-builder AS builder`
			`# The Caddy builder image bakes in Go 1.23, but caddy-dns/vultr now`
			# requires Go >= 1.24. GOTOOLCHAIN=auto lets `go get` fetch a newer
			`# toolchain on demand so we don't have to bump base images every time`
			`# a plugin's minimum Go version moves.`
			`ENV GOTOOLCHAIN=auto`
			`RUN xcaddy build \`
caddy: add caddy-dns/rfc2136 + test-rfc2136 site -- self-hosted ACME flow Wires Caddy as the ACME client side of our new self-hosted DNS-01 flow. Proves the design end-to-end: caddy-dns/rfc2136 -> our CoreDNS rfc2136 plugin -> zone file write -> git auto-commit -> HE AXFR -> LE validates -> cert issued. Changes: - caddy/Dockerfile: --with github.com/caddy-dns/rfc2136 added alongside the existing caddy-dns/vultr. - caddy/Caddyfile: new test-rfc2136.supported.systems site that uses the new provider. server coredns:53 (docker internal), key from env, propagation_delay 60s + timeout 600s to accommodate HE pull. - docker-compose.yml: ACME_TSIG_SECRET passed to the caddy container (the same secret CoreDNS verifies on the other side of the loop). First cert issued in production: 2026-05-21 ~13:23 UTC. ~5.5 min end-to-end from Caddy starting to cert in hand. Documented in session notes; the cert sits unused in caddy-data/ until/unless something publishes ports 80/443 for that hostname. 2026-05-21 13:27:05 -06:00			`--with github.com/caddy-dns/vultr \`
			`--with github.com/caddy-dns/rfc2136`
coredns: production Let's Encrypt cert via Caddy sidecar (DNS-01 + Vultr) Replaces the self-signed dev cert flow with a real LE prod cert for dns.l.supported.systems, issued and auto-renewed by a Caddy sidecar using DNS-01 challenge against the Vultr API. Components: - caddy/Dockerfile builds Caddy 2.10.0 with caddy-dns/vultr plugin via xcaddy. GOTOOLCHAIN=auto so xcaddy can fetch newer Go on demand when plugin versions advance their minimum Go. - caddy/Caddyfile uses DNS-01 with explicit public resolvers (1.1.1.1, 9.9.9.9) for the propagation check. Without that, Docker's embedded DNS leaks the container into the host's split-horizon LAN DNS, which returns LAN IPs for ns1.vultr.com and the propagation check fails. - docker-compose: caddy service shares ./caddy-data with coredns via a read-only subpath mount that excludes /acme (account private key). - Healthcheck doubles as a symlinker: maintains stable cert.pem / key.pem names at /data/caddy/ and chmods cert files + their dirs to be readable by CoreDNS's nonroot user. Flips to "healthy" only once the symlinks dereference (i.e. cert exists), gating CoreDNS start via depends_on: service_healthy. - Corefile unchanged — same /etc/coredns/certs/cert.pem path; only the bind-mount source switches from ./certs to ./caddy-data/caddy. - New Makefile target: tls-up orchestrates the bring-up sequence. Cert is valid until Aug 12 2026. Verified end-to-end: dig @127.0.0.1 -p 8853 +tls +tls-hostname=dns.l.supported.systems ... dig @127.0.0.1 -p 8443 +https +tls-hostname=dns.l.supported.systems ... 2026-05-14 01:34:57 -06:00
			`FROM caddy:2.10.0`
			`COPY --from=builder /usr/bin/caddy /usr/bin/caddy`