v0.1.6

Upgrade if you use wildcards — v0.1.5 cannot issue them

A wildcard covers one label down but not the name itself, so a real order asks
for both example.com and *.example.com. Both validate at the same
_acme-challenge label, and the CA issues a separate token for each — two TXT
values sit on one name during issuance.

v0.1.5 confirmed its writes with an RFC 2136 "RRset exists (value dependent)"
prerequisite, which compares the whole RRset for equality rather than testing
membership. The second value always came back NXRRSET, and the run aborted
after ten retries with "was accepted but the update server does not serve it".
doctor passed regardless, because its probe writes a single value at a unique
name.

Upgrading: check dns.sign_queries

This setting had no effect on the master path before v0.1.6 and now governs it.
A config carrying sign_queries: false — commonly left behind by debugging —
silently sends the write confirmation into whichever view your source address
selects. Remove it unless your server genuinely rejects signed queries.

What changed

• Verification queries are now TSIG-signed for real. hickory's client signs
  only UPDATE/NOTIFY/AXFR and rewrites the message id after signing, so
  dnsvcert performs the DNS-over-TCP exchange itself and verifies the
  response signature. Key-based view routing on multi-view servers is
  preserved — that was the reason the prerequisite existed.
• Confirming a write is a membership test. Two values at one name both pass.
• dns.sign_queries now governs the master path as well as the resolver path
  (default: the master check signs, a configured resolver does not). It was
  ignored whenever a TSIG key was present.
• A failed confirm reports the TXT values the server actually serves and names
  unsigned queries as a likely cause, instead of pointing at authority.
• hickory-net and futures-util are no longer dependencies.

Verified

Against BIND 9.18 with two views (match-clients { key ...; } plus a decoy)
and update-policy grant ... zonesub TXT: two values at one name both confirm;
nsupdate prereq yxrrset returns NXRRSET for one of two values and NOERROR for
both; a run with sign_queries: false lands in the wrong view and says so.

Reported by a DNSVault engineer hitting it during a live install — thank you.

v0.1.5

Full Changelog: v0.1.4...v0.1.5

Full Changelog: v0.1.4...v0.1.5

Full Changelog: v0.1.4...v0.1.5

Full Changelog: v0.1.4...v0.1.5

Full Changelog: v0.1.4...v0.1.5

Full Changelog: v0.1.4...v0.1.5

v0.1.4

Multi-view DNS support (split-horizon / internal networks).

• Verification queries (TXT confirm, doctor checks) are now TSIG-signed by default, so multi-view servers route them to the same view as the signed updates — running from inside the network just works
• New dns.resolver sends verification queries to a resolver instead (checks exactly what Let's Encrypt sees; signing then defaults off), with dns.sign_queries overriding either default
• dnsvcert setup asks which verification path to use, probes for split-horizon setups, warns when an internal resolver would answer from the wrong view, and reminds you to keep challenge zone TTLs / SOA minimum low for resolver-based verification

v0.1.3

Guided interactive setup — for humans without an AI agent.

• New dnsvcert setup: asks for every value in plain language, writes the config with owner-only permissions, live-checks your DNS in fix-and-retry loops (a missing CNAME prints the exact record and waits while you add it), then issues the certificate and prints the renewal cron line
• Reuses an existing config when present — setup doubles as a troubleshooting tool
• TSIG secret input is hidden on a terminal; piped input still works for scripting
• --help points first-timers at setup

v0.1.2

Hostname support for dns.server.

• dns.server: ns1.example.com now works — hostnames are resolved before use (previously only IPs were accepted)
• Patient production polling: Let's Encrypt's multi-perspective validation can exceed 30s; readiness/certificate polls now wait up to 300s with gentle backoff
• Proven in production against a live DNSVault hybrid v1 deployment: full doctor pass and a real certificate issued through a TXT-only update-policy on the customer's own BIND

v0.1.1

Usability from agent cold-start testing.

• New dnsvcert init writes a starter config (--domain/--email/--challenge-zone/... flags) and prints the exact CNAME records to add
• doctor now runs its CNAME checks before any TSIG secret exists (write probe shows SKIP instead of erroring); the CHANGE_ME placeholder counts as unset so init → doctor works out of the box
• doctor CNAME checks dedup by base name (a wildcard shares its base's record)
• README: install-from-Releases section

v0.1.0

Initial release — ACME DNS-01 client for DNSVault.

• Issues Let's Encrypt (or any ACME CA) certificates through a delegated challenge zone: your production DNS carries one static CNAME per name and is never written to by automation
• issue / renew (cron-friendly, renews under 30 days) / doctor (verifies CNAME delegation + TSIG write access with exact-record hints)
• hook mode plugs into certbot as --manual-auth-hook / --manual-cleanup-hook
• Single static binary per platform, one YAML config, TSIG secret also via DNSVCERT_TSIG_SECRET
• Works with DNSVault hybrid v1 and Neo alike — the whole server-side contract is BIND