A caching DNS proxy with a persistent record book and a beacon-driven survival mode, plus an embedded web dashboard and Prometheus metrics.

• Incoming queries (UDP/TCP/DoT/DoH) are answered from the in-memory cache (otter, per-entry TTL) when possible.
• On a miss, the backend servers whose routing suffix matches the query name (see below; by default all of them) are queried concurrently and the fastest non-empty response wins. If every server answers empty, an empty response is served.
• Every backend answer is persisted to the record book (lotusdb) together with its TTL (informational) and the query date.
• A beacon record is probed on every backend server at an interval. If the beacon is unreachable on all servers for BEACON_FAIL_AFTER, the proxy enters survival mode: backends are no longer queried and answers are served from the record book, even past their TTL. Once the beacon is continuously reachable for BEACON_RECOVER_AFTER, normal mode resumes.

Each backend URI may carry a suffix query parameter naming the DNS zone it serves. On a cache miss, a query is routed only to the backends whose suffix matches the query name — and among matching suffixes, only the most specific one (most labels) wins. Backends without a suffix serve . (everything) and act as the catch-all.

LIGHTHOUSE_BACKENDS="udp://1.1.1.1:53,udp://10.96.0.10:53?suffix=cluster.local."

With this configuration:

• foo.svc.cluster.local. → only 10.96.0.10 (suffix cluster.local. beats .)
• example.com. → only 1.1.1.1 (the catch-all)

Notes:

• The suffix is case-insensitive; leading/trailing dots are optional (cluster.local, .cluster.local., and CLUSTER.LOCAL are equivalent). A name equal to the suffix itself also matches.
• Several backends may share the same suffix; they are fanned out together and the fastest non-empty answer wins, as usual.
• If every backend has a suffix and none matches a query, the query fails (SERVFAIL) — keep at least one catch-all backend unless that is intended.
• For DoH backends the suffix parameter is stripped before the URL is used as the endpoint.
• Routing applies to resolution only; the health beacon and dashboard probes still check all backends regardless of suffix.

Requires Go 1.26.5 and Node (both via asdf install).

make build   # builds the Nuxt dashboard, embeds it, compiles the binary
LIGHTHOUSE_BACKENDS=udp://1.1.1.1:53,udp://8.8.8.8:53 \
LIGHTHOUSE_BEACON_NAME=example.com \
./lighthouse

Dashboard at http://localhost:8080 (status, QPS charts, backend health, record book explorer with search/delete/re-query). Prometheus metrics at http://localhost:9090/metrics (lighthouse_frontend_*, lighthouse_backend_*, lighthouse_cache_entries, lighthouse_recordbook_records, lighthouse_survival_mode).

docker build -t lighthouse .
docker run -d --name lighthouse \
  -e LIGHTHOUSE_BACKENDS=udp://1.1.1.1:53,udp://8.8.8.8:53 \
  -e LIGHTHOUSE_BEACON_NAME=example.com \
  -p 53:53/udp -p 53:53/tcp -p 8080:8080 -p 9090:9090 \
  -v lighthouse-data:/data \
  lighthouse

The image is distroless and runs as nonroot; the record book lives in the /data volume. CI (.github/workflows/) runs go vet + go test -race and the dashboard build on every push/PR, and pushes images to ghcr.io/<owner>/lighthouse on main (latest, main, sha-*) and on v* tags (semver tags).

Services live under internal/<service>/ with service.go, model/, and storage/ (repositories). Cross-service calls use consumer-side interfaces built on primitive types, satisfied by the services directly; internal/adapters/ is reserved for cases where service models must be translated (currently none). Delivery edges (internal/dnsserver, internal/httpserver) consume services directly via consumer interfaces. Wiring happens in cmd/lighthouse/main.go.