Deploy gate dc-prod-deploy-dc171 (grade D, urn:ump:iesjvepuqb5poim7wu22ff4jtd5vhpw2lotfhogljemsw2h4y6vq)
blocked the cutover: listRecords built 'dig @srv -p port AXFR zone', but
dig's documented positional contract is [name] [type]. BIND 9.18 accepts
either order (live-checked), so the bug was invisible on this host's dig;
older 9.11-9.16 on other distros follow the documented order. Fixed to
'zone AXFR', test asserts the production argv, and the corrected code path
was LIVE-VERIFIED against a real DNS server: actual AXFR of zone 'sami'
via the adapter itself — 48 records parsed (SOA/A/NS), zero mocked pieces.
Parity suite: 24/24.
RFC2136/BIND9 adapter gains listRecords via AXFR zone transfer (dig with
the same TSIG identity as nsupdate; temp 0600 keyfile, always cleaned up;
transfer-denial errors carry the exact allow-transfer fix). TSIG fields
validated (name charset, HMAC algorithm whitelist, base64 secret) before
keyfile interpolation.
Capability honesty at every surface: GET /dns/records 501s name the active
provider + its supported capabilities + zone-transfer pointer; MCP
dashcaddy_list_dns attaches actionable guidance for AI clients; setup
wizard shows per-provider capability hints at choice time (parity-pinned
by tests against the adapters).
Also fixed a latent rfc2136 bug: this._log instance property shadowed the
prototype logging method — every nsupdate call threw since the DC-170-era
refactor. CHANGELOG stale 'protocol-impossible' DC-171 entry superseded.
Judge: grade B, zero blockers (urn:ump:wokpmecjfauc7jvnxyyyu4fq3zkkvwge455a5mxlmi3pdzkfdw3a).
Polish applied post-grade: stale changelog entry corrected, TSIG field
validation + 4 extra failure-path tests (exact dig argv, ENOENT install
hint, non-denial failure passthrough, hostile-field rejection),
dns-records 501 test strengthened to pin provider name + capabilities.
Suite: backend 174 suites / 3754 tests, frontend 68/68.
Hermes