half broken

README.md

@@ -396,6 +396,16 @@ the file wins, because `Parse` starts from that derived origin and the
 directive replaces it. Records that fall outside their own zone are dropped
 (`localzone.add` returns false).
 
+The practical consequence: a *relative* name is qualified with the file's base
+name, not with the zone you had in mind. In `local.example.zone` (origin
+`local.`) the record `ns1 A 192.168.1.2` becomes `ns1.local.`, and in a policy
+zone `*.doubleclick.net` becomes `*.doubleclick.net.local.` — a rule that blocks
+nothing you asked about. Both shipped examples therefore spell every name out in
+full, which is the only spelling that does not depend on what the file is
+called: `TestExampleLocalZoneIsOriginIndependent` (`internal/zonefile`) and
+`TestExampleRPZZoneBlocksWhatItSays` (`internal/blocklist`) fail if they are
+"tidied up" back to relative names.
+
 **Policy zone vs ordinary local zone.** Both come from
 `blocklist.local_zones` and both are master files; the difference is what the
 records mean and where they are matched:
@@ -403,7 +413,7 @@ records mean and where they are matched:
 | | RPZ-style policy zone | Ordinary local zone |
 |---|---|---|
 | Compiled by | `blocklist.parseRPZ` / `parseRPZFiles` | `localzone.Load` |
-| Matching | by rule name; `*.name` covers subdomains; the rdata carries the action | by the question: exact `name\|TYPE`, then `*.<name>`, then any type at the name |
+| Matching | by rule name; `*.name` covers subdomains but **not** the name itself (see [Known inconsistencies](#known-inconsistencies)); the rdata carries the action | by the question: exact `name\|TYPE`, then `*.<name>`, then any type at the name |
 | Action from rdata | `CNAME .` → NXDOMAIN, `CNAME rpz-drop.` → drop, `CNAME rpz-passthru.` / `rpz-tcp-only.` → passthrough, other CNAME → CNAME answer, `A`/`AAAA` → that address, `TXT` containing `allow` → allow | none; records are answers, and the zone's SOA is returned for NXDOMAIN/NODATA |
 | In the pipeline | after the ACL, before the cache | after the ACL, before the blocklist |
 | Delegation | n/a | an `NS` record below the apex marks a delegation and the data below it is not answered |
@@ -784,4 +794,27 @@ Found while writing this file; each is a to-do, not something fixed here.
     rejects the combination with `trust_loopback: false`; the unsafe case is
     reported solely as a warning from `POST /api/settings/validate`.
 24. **`config.Load` does not use `yaml.Decoder.KnownFields`**, so unknown keys
-    are ignored silently (also recorded as an open decision in `STATUS.md`).
+    are ignored silently. A settled decision (pinning, not changing, the
+    behaviour); `TestLoadIgnoresUnknownKeys` in `internal/config` holds it.
+25. **`internal/blocklist/parse.go:485-495` — an RPZ record does not cover the
+    name it names.** `rpzRule` gives a bare owner name the subdomain form
+    (`*.name`), and a subdomain-form rule matches that name's children but not
+    the name itself, so `analytics.example.org.` in a policy zone blocks
+    `cdn.analytics.example.org.` and leaves `analytics.example.org.` resolving
+    normally. RPZ semantics say the record applies to the domain and everything
+    under it, so the apex form (`**.name`) is what belongs here — a
+    one-character change in `rpzRule` that alters which queries get blocked, so
+    it wants a decision rather than a quiet fix. Pinned by
+    `TestExampleRPZZoneApexIsNotCovered`. The same gap means an
+    `rpz-passthru.` record for a domain does not allowlist the domain itself.
+26. **`internal/api/api.go:288-317` — `api.cors_origins: ["*"]` echoes the
+    request's `Origin` *and* sets `Access-Control-Allow-Credentials: true`.**
+    That is deliberate (a literal `*` is ignored by browsers when credentials
+    are involved, so echoing is the only way a wildcard can work with a session
+    token), but it does mean a wildcard CORS origin lets any website drive the
+    admin API with whatever the browser already has cached for that host —
+    relevant to `auth.mode: basic` and to a loopback-trusted console. The
+    preflight also answers 204 for *any* origin and any path, and credentials
+    are advertised for exact origins too. Pinned by
+    `TestCORSWildcardEchoesTheOrigin` and `TestCORSPreflight`; whether a
+    wildcard should be refused outright is a decision.