86a83302b648d7e226e6420291b3815ef3df5a73
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  matsandClaude Sonnet 5.5
|
c6c5ca4ff7 |
Make the resolver pure DNS: JSON access log on stdout instead of a log store
The resolver kept its own query-log store (a bbolt ring, a live ring with SSE fanout, rolling per-domain counters and dashboard time-series) for the console. In a multi-node deployment each pod held a different slice of that, so every view disagreed with itself, and the cost sat on the query path. Charts belong in Grafana and log search in the log collector, so the store is gone. internal/accesslog writes one JSON line per notable query to stdout. The default is what was blocked and what failed (blocked, redirected, SERVFAIL, dropped, refused); log_cached and sample_rate add ordinary answers for a debugging session. Lines go through a bounded buffer to a single writer goroutine and are dropped, and counted in fancydns_access_log_dropped_total, when the stream cannot keep up, so a stalled log pipe can never stall a query. The config key is access_log (the old qlog block is ignored, like any unknown key). The metrics gain what the dashboard used to compute: fancydns_group_queries_total by ACL group and outcome and fancydns_responses_total by RCODE. Removed with the store: /api/dashboard, /api/logs, /api/logs/stream, /api/logs/clear, /api/cache/top, the series rings, and the cache's per-name hit table, which took a mutex and built a string on every cache hit. Tests that read the old log now read the access-log lines; the contract test drops the removed endpoints. The web console still calls them and is changed in the next commit. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> |
||
|
developer
|
504512f247 |
Add a Zones console: create and manage local zones, records and delegations
The console could not see local zones at all. `blocklist.local_zones` compiled a store that nothing read back: there was no API for a zone, its records, its delegations or the file a record came from, and no way to change one without editing YAML and reloading. The Domains page is the blocklist's inline rules, not local data, so nothing in the console covered the half of the server that answers authoritatively from disk. There is now a Zones page and the endpoints behind it: `GET /api/zones`, `POST`/`PUT`/`DELETE /api/zones/records`, `POST`/`DELETE /api/zones/delegations` and `DELETE /api/zones?zone=`. **The console owns one directory and nothing else.** `blocklist.managed_zones` holds one `<apex>.zone` per zone, with that zone's SOA, apex NS set and the records added there, and it is compiled by the same `localzone.Load` as the operator's files — so a record added from the console is served on the next query, with no reload and no restart. Files in `blocklist.local_zones` are listed and shown read-only and are never rewritten; the key defaults to empty, so a deployment that never sets it gets a zone browser and no zone writes. Which file a record came from is now part of the store (`zone.files`, keyed by the index the store already uses), so the snapshot can say "console" or "your file" per record; the query path does not read it. **The writer proves its own output.** A record is validated by the project's own master-file parser, so `www` means `www.<zone>` and a bare CNAME target is completed exactly as it would be in a zone file; the file is rendered, and the rendering is re-parsed and compared with the records it meant to write before the file is renamed into place. A writer bug that dropped a record would otherwise present as a zone that silently stopped answering. A zone that cannot answer is refused rather than created: no SOA means no NXDOMAIN or NODATA authority, and no apex NS means nothing is delegated and no server is named. The SOA's primary follows the apex NS set — a zone whose SOA names a server outside its own NS set hands out a referral no resolver can follow — and the serial moves on every write. **A delegation takes the names under it, so a record below a cut is refused.** The store answers those names as delegated without reading the zone file, which would make the record data that looks alive and never answers. `DELETE /api/zones?zone=` exists for the same reason from the other side: a zone the console created is a real zone, so it says NXDOMAIN for what it does not hold, and deleting a record is not what gives a name back to upstream. It is refused for a zone that also has records outside the managed directory, because removing that file would remove none of the zone. **Two bugs the work turned up.** `engine.applyConfig` published local-record metrics only when `blocklist.local_zones` was non-empty, so a zone the console created was served but never counted; the gate is now the store's own record count. And the record-value renderer fell back to `RR.String()` for every type it did not know, which is the whole line rather than the RDATA — it wrote a name and a TTL into the value column for DHCID, LOC, SSHFP and SVCB, and would have fed that back as a record value on the next edit. Every write recompiles the store and flushes the cache. Which names changed is not knowable from the API, and a cached upstream answer for a name the zone now answers is simply wrong, so the flush is blunt on purpose. The wire shapes are type aliases in `internal/api` rather than copies, so there is one set of json tags, and `TestZoneEndpointKeySets` pins the key set at every level with a record and a delegation actually present — an empty list only proves the envelope. `TestZoneWritesNeedAManagedDirectory` pins the read-only default, and `TestZoneConsoleRoundTrip` walks the whole thing: a record added through the API is answered authoritatively on the next query, a cut stops the parent answering below it, and deleting the zone hands the name back. Verified against a running instance built from this tree: records and wildcards answer with `aa`, relative names are qualified, a record below a cut is refused with a message that says why, and the file on disk is a zone file an operator can read. The console page is typechecked and built; the browser was not available in this round, so it has not been looked at. |
||
|
developer
|
48d37db15b |
Add the first internal/api test suite
build / build-push (push) Failing after 19s
internal/api is the admin REST + SSE surface and had no test file at all, so nothing pinned the auth modes, the X-Forwarded-For trust boundary, the rate limiter or the fact that a read route must not mutate anything. This adds a local harness (a Server over fake hooks on an httptest listener, with a real config file on disk) and three test files. What it pins: * Routing. A table over every route in Server.routes: each one answers 200 and reaches the hook it is supposed to, so a new route without a case here is a route nothing tests. Plus method-not-allowed / 404 / outside the base path, a base path other than /api, and a read-route sweep that asserts no mutating hook was reached, the config generation did not move and the file on disk is byte-identical afterwards. A panicking component becomes a 500 and the server keeps serving, because the admin API is the only way to fix a broken instance. * Auth. All three modes. apikey: the right key always works, and a prefix, a suffix, a case-folded key, a wrong basic password, an unknown bearer token, an unsupported scheme and a malformed Authorization header never do; curl -u any:KEY is accepted because that is what clients send. basic: bad username and bad password refused, a successful login issues a bearer token, the token works for the whole API, basic auth also works per request, an API key is not a credential in this mode, logout revokes the token, and a token past its session_ttl stops working. none: nothing is required and the caller runs as a writable loopback principal. trust _loopback: a local client with no credentials is let through, and a forwarded non-loopback client is not. Every mutating route refuses a read-only key with 403 without reaching its hook or touching the file (and the same request with a read-write key succeeds, so the 403 is about the key and not the payload), and allow_config_write: false refuses the settings editor with a valid key while the other mutations still work. The hashing is pinned on the state, not on timing: the authenticator's maps are keyed on the SHA-256 of the credential and hold no plaintext key or password, so a copied server struct cannot leak one. * Product code is untouched; the suite is `package api` with its own setup. |