docs: lift user-facing guides to recipes/, drop dangling docs/ refs

docs/ is gitignored; references to docs/implementation/*.md from public
source, configs, and packaging were dead links outside the maintainer
machine. Adds four recipes (README, dnsdist-front, doh-on-lan,
odoh-upstream) under top-level recipes/ and repoints existing pointers.

- numa.toml, packaging/client/{README.md,numa.toml}: point to
  recipes/odoh-upstream.md.
- src/{bootstrap_resolver,forward,serve}.rs: reference issue #122
  directly (module scope is broader than the ODoH-specific recipe).
- src/health.rs: drop the §-ref; iOS HealthInfo remains named as the
  canonical consumer.

recipes/README.md

@@ -0,0 +1,11 @@
+# Recipes
+
+Scenario-driven configs for common Numa deployments. Each recipe is self-contained: copy the snippet, adjust the marked fields, reload.
+
+## Transport / encryption
+
+- [DoH on the LAN](doh-on-lan.md) — expose Numa's built-in DNS-over-HTTPS to local clients.
+- [dnsdist in front of Numa](dnsdist-front.md) — terminate public TLS externally, keep Numa on loopback.
+- [ODoH upstream with bootstrap pinning](odoh-upstream.md) — oblivious DNS client mode without leaking the relay/target hostnames.
+
+Missing a scenario? Open an issue or PR — these are plain Markdown with no build step.

recipes/dnsdist-front.md

@@ -0,0 +1,64 @@
+# dnsdist in front of Numa
+
+For public DoH with a real (ACME-signed) cert, terminate TLS outside Numa and forward plain DNS (or loopback-only DoH) to the resolver. Cert renewal, rate-limiting, and load-balancing live in the front-end; Numa stays focused on resolution.
+
+## When to use this
+
+- Public hostname (`dns.example.com`) with a Let's Encrypt or internal PKI cert.
+- You want a dedicated front-end for DoH/DoT/DoQ while Numa stays loopback-bound.
+- You plan to run multiple Numa instances behind one endpoint.
+
+## Architecture
+
+```
+ public 443/DoH  ┐
+ public 853/DoT  ├─► dnsdist  ─►  127.0.0.1:53 (Numa UDP/TCP)
+ public 443/DoQ  ┘
+```
+
+## dnsdist config
+
+```lua
+-- /etc/dnsdist/dnsdist.conf
+
+newServer({address="127.0.0.1:53", name="numa", checkType="A", checkName="numa.rs."})
+
+addDOHLocal(
+  "0.0.0.0:443",
+  "/etc/letsencrypt/live/dns.example.com/fullchain.pem",
+  "/etc/letsencrypt/live/dns.example.com/privkey.pem",
+  "/dns-query",
+  {doTCP=true, reusePort=true}
+)
+
+addTLSLocal(
+  "0.0.0.0:853",
+  "/etc/letsencrypt/live/dns.example.com/fullchain.pem",
+  "/etc/letsencrypt/live/dns.example.com/privkey.pem"
+)
+
+addAction(AllRule(), PoolAction("", false))
+```
+
+## Numa config
+
+```toml
+[proxy]
+enabled   = true         # keep if you still use *.numa service routing
+bind_addr = "127.0.0.1"  # stays default
+```
+
+No changes to `[server]` — Numa keeps serving plain DNS on UDP/TCP 53, which dnsdist forwards.
+
+## Caveat: client IPs
+
+Without PROXY protocol support in Numa, the query log shows the front-end's IP on every query, not the real client. dnsdist can emit PROXY v2 (`useProxyProtocol=true` on `newServer`), but Numa doesn't yet parse it — tracked in the wish-list under #143. Until then, accept the blind spot or correlate against dnsdist's own logs.
+
+## Verify
+
+```bash
+kdig +https @dns.example.com example.com
+kdig +tls  @dns.example.com example.com
+```
+
+Both should return clean answers. Numa's `/queries` API should show the request landing, sourced from the front-end IP.

recipes/doh-on-lan.md

@@ -0,0 +1,61 @@
+# DoH on the LAN
+
+Numa ships an RFC 8484 DoH endpoint (`POST /dns-query`) on the `[proxy]` HTTPS listener. By default it binds `127.0.0.1:443` with a self-signed cert — invisible to anything off the box. Three changes make it reachable from the LAN.
+
+## When to use this
+
+- Your phone/laptop is on the same network as Numa and you want encrypted DNS without a cloud resolver.
+- You're OK installing Numa's self-signed CA on every client (one-time, via `/ca.pem` + the mobileconfig flow).
+
+For a publicly-trusted cert, see [dnsdist in front of Numa](dnsdist-front.md) instead.
+
+## Minimal config
+
+```toml
+[proxy]
+enabled   = true       # default
+bind_addr = "0.0.0.0"  # was 127.0.0.1 — expose to LAN
+tls_port  = 443        # default; DoH is served here
+tld       = "numa"     # default — self-resolving, see below
+```
+
+`tld` is the DoH gate: Numa accepts the DoH request only when the `Host` header is loopback or equals (or is a subdomain of) `tld`. Clients therefore dial `https://numa/dns-query`.
+
+With the default `tld = "numa"`, there's no DNS bootstrap to configure: Numa already resolves `numa` and `*.numa` to its own LAN IP for remote clients (that's how the `*.numa` service-proxy feature works). Any client that uses Numa as its resolver will resolve `numa` correctly on first try.
+
+If you'd rather use a hostname that resolves via normal DNS (e.g. you want DoH-only clients that never talk plain DNS to Numa), set `tld = "dns.example.com"` and add a matching A record in whichever DNS your clients consult before reaching Numa.
+
+## Trust the CA on each client
+
+Numa generates a self-signed CA at startup. Fetch it once, import it wherever you'll run the DoH client:
+
+```bash
+curl -o numa-ca.pem http://<numa-ip>:5380/ca.pem
+```
+
+- **macOS** — `sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain numa-ca.pem`
+- **iOS** — install the mobileconfig from the API (same CA, signed profile). Flip *Settings → General → About → Certificate Trust Settings* on after install.
+- **Linux** — drop into `/usr/local/share/ca-certificates/` and run `sudo update-ca-certificates`.
+- **Android** — requires the user-installed CA path; browsers may still refuse it for DoH. Consider the [dnsdist front](dnsdist-front.md) route instead.
+
+## Verify
+
+```bash
+kdig +https @numa example.com
+```
+
+Without `+https` kdig uses plain DNS. With `+https` the same answers should flow over port 443.
+
+Raw check:
+
+```bash
+curl -H 'accept: application/dns-message' \
+     --data-binary @query.bin \
+     https://numa/dns-query
+```
+
+## Gotchas
+
+- Port 443 is privileged on Linux/macOS. Run Numa via the provided service units, or grant `CAP_NET_BIND_SERVICE` (`sudo setcap 'cap_net_bind_service=+ep' /path/to/numa`).
+- Non-matching `Host` header → HTTP 404 from the proxy's fallback handler. Double-check `tld`.
+- ChromeOS enrollment rejects user-installed CAs for some flows — known pain point, see issue #136.

recipes/odoh-upstream.md

@@ -0,0 +1,59 @@
+# ODoH upstream with bootstrap pinning
+
+Numa can run as an Oblivious DoH (RFC 9230) client: the relay sees your IP but not the question, the target sees the question but not your IP. Neither party alone can re-identify a query. This recipe covers the minimal config and the bootstrap leak that `relay_ip` / `target_ip` close.
+
+## When to use this
+
+- You want split-trust encrypted DNS without a single provider seeing both who you are and what you asked.
+- Numa is your system resolver (so there's no "other" DNS to ask).
+
+## Minimal config
+
+```toml
+[upstream]
+mode   = "odoh"
+relay  = "https://odoh-relay.numa.rs/relay"
+target = "https://odoh.cloudflare-dns.com/dns-query"
+strict = true   # refuse to fall back to a non-oblivious path on relay failure
+```
+
+`strict = true` means a relay-level HTTPS failure returns SERVFAIL instead of silently downgrading. Set it to `false` and configure `[upstream].fallback` if you'd rather keep resolving (at the cost of the oblivious property).
+
+## The bootstrap leak
+
+When Numa is the system resolver and needs to reach the relay/target, *something* has to translate `odoh-relay.numa.rs` → IP. If Numa asks itself, you deadlock. If Numa asks a bootstrap resolver (1.1.1.1, 9.9.9.9), that resolver learns which ODoH endpoint you use in cleartext — it can't see your questions, but it sees the destination. That's the leak ODoH was supposed to close.
+
+`relay_ip` and `target_ip` tell Numa the IPs directly, so it never asks anyone:
+
+```toml
+[upstream]
+mode      = "odoh"
+relay     = "https://odoh-relay.numa.rs/relay"
+target    = "https://odoh.cloudflare-dns.com/dns-query"
+relay_ip  = "178.104.229.30"     # pin the relay — no hostname lookup
+target_ip = "104.16.249.249"     # pin the target — no hostname lookup
+```
+
+Numa still validates TLS against the hostnames in `relay` / `target`, so a hijacked IP can't masquerade — pinning skips only the DNS step.
+
+## Finding current IPs
+
+```bash
+dig +short odoh-relay.numa.rs
+dig +short odoh.cloudflare-dns.com
+```
+
+Re-pin when an operator rotates. The community-maintained list at <https://github.com/DNSCrypt/dnscrypt-resolvers/blob/master/v3/odoh-relays.md> is a useful cross-reference.
+
+## Verify
+
+```bash
+kdig @127.0.0.1 example.com
+```
+
+Numa's `/queries` API and startup banner should label the upstream as `odoh://`. Look for `ODoH relay returned ...` errors in the logs if routing fails.
+
+## Known gotchas
+
+- **Same-operator refused.** Numa's eTLD+1 check blocks configs where the relay and target belong to the same operator (pointless — same party sees both sides). Override only when testing.
+- **Single relay.** Current config accepts one relay and one target. Multi-entry rotation/failover is tracked in #140.