v4.9.0

RemotePower v4.9.0 — "ResolutionMatters"

v4.9.0 adds an Admin → DNS dashboard that manages DNS records directly through your provider's API — view, add, edit and delete records without leaving RemotePower or opening each registrar's console — plus a live resolve/dig and propagation panel that shows what a name actually resolves to. It reuses the scoped API tokens you already configured for ACME DNS-01 certificate issuance, so if you issue certs by DNS there is nothing new to set up.

After upgrading, hard-reload the dashboard once so the new front-end loads (service-worker cache remotepower-shell-v4.9.0-r2).

DNS dashboard

Open Admin → DNS, pick a provider and a zone, and the zone's records load straight from the provider's API.

• Read/write records. List, create, edit and delete A / AAAA / CNAME / TXT / MX / NS / SRV / CAA records. Set TTL, MX/SRV priority, and (Cloudflare) the proxied flag.
• Five providers. Cloudflare, DigitalOcean, Hetzner DNS, deSEC and Porkbun. Each is a plain token-authenticated REST API. deSEC's RRset model (one entry per name+type, holding a list of values) and Porkbun's subdomain + in-body credential form are normalised so every provider presents the same record shape in the UI.

Resolve / dig & propagation

Below the records table, the Resolve / dig panel queries a name live and shows two views side by side:

• Authoritative — the answer straight from the zone's own nameservers (what the provider is actually serving).
• Public resolvers — what Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9) and OpenDNS return.

Comparing the two surfaces drift between provider state and what the world sees — including stale caches and records that didn't take. Supports A / AAAA / CNAME / MX / TXT / NS / SOA / CAA / SRV / PTR.

Propagation check. After editing a record, click the globe icon on its row (or Check propagation) to poll the public resolvers and get a propagated X/N chip — green when every resolver already serves the new value, amber while it's rolling out. Each resolver's current answer is shown so you can see exactly who is still stale.

These are read-only DNS lookups. For safety they only ever query the fixed public resolver allowlist and the zone's authoritative nameservers (private, loopback, link-local and metadata addresses are filtered out); no user-supplied resolver address is ever contacted.

Resolver health monitor

Below the resolve panel, Resolver health monitor turns a name into an ongoing check. Add a name + record type and RemotePower re-resolves it across the public resolvers on a rate-limited cadence (every ~15 minutes), tracking:

• Health — healthy (every resolver answers), degraded (some do), or not resolving (none do).
• Latency — mean and max response time across resolvers.
• NXDOMAIN / failure counts — per check, with a per-resolver status dot.

When a name stops resolving for two consecutive checks it raises a resolver_unhealthy alert (flap-dampened so a single blip is ignored); when it resolves again it fires resolver_recovered, which auto-resolves the alert. Both flow through the normal alert inbox, webhook channels and activity feed.

Resolution timeline (MTTR)

The Alerts page gains a collapsible Resolution timeline (MTTR) section that turns the alert history into operational metrics:

• MTTR (mean time to resolution) and MTTA (mean time to acknowledge) across recently-resolved alerts — mean and median, over a 7 / 30 / 90-day window.
• Per-host breakdown — which hosts generate the most alerts and how fast they clear.
• Timeline — every resolution with how it was closed: auto (a recover event cleared it), manual (an operator resolved it — shown with who), or muted — plus the ack/resolve note. This pairs with the ack-webhook so you can see who closed what, and how quickly.

Credentials — reuse your ACME tokens

DNS credentials are the same scoped API tokens RemotePower already uses for ACME DNS-01, stored under ACME → DNS credentials (config['acme_dns_credentials']):

Provider	Token field(s)
Cloudflare	CF_Token (Zone:Read + DNS:Edit)
DigitalOcean	DO_API_KEY
Hetzner DNS	HETZNER_Token
deSEC	DEDYN_TOKEN
Porkbun	PORKBUN_API_KEY + PORKBUN_SECRET_API_KEY

Set a token once and it drives both certificate issuance and this dashboard — there is no second secret store. A Cloudflare token scoped to DNS-edit only may lack Zone:Read; widen it to Zone:Read if zone listing comes back empty.

Safety

• Admin-only. Every /api/dns/* endpoint requires an admin session.
• Audited. Create, edit and delete are written to the audit log with the provider, zone, type and name.
• Confirmed deletes. Deleting a record requires an explicit confirmation — DNS changes are live and can take services (mail, web, even cert renewal) offline.
• SSRF-guarded. Provider calls reuse the hardened HTTP client: no loopback / link-local / cloud-metadata targets, peer-IP re-validation at connect time, and no redirects.

Import credentials from a device's acme.sh

If your provider tokens are already on a host in acme.sh's account.conf (acme.sh saves them as SAVED_CF_Token / SAVED_CF_Key / SAVED_HETZNER_Token / …), you don't need to re-type them — the agent on that host can harvest them:

The whole thing is one flow on the DNS page:

1. Unlock vault.
2. Pick the device under Import from agent and click it.
3. The server flags that device for a one-shot harvest. On its next heartbeat, the agent (running as root) reads account.conf, extracts the SAVED_* DNS-provider credentials, and returns them over the authenticated heartbeat (never through the command-output log). The page polls with live status ("waiting for the agent's next check-in…") and then encrypts the token straight into the vault, clearing the transient plaintext.
4. Pick the provider + zone — the records load (vault unlocked, token decrypted per-request).

The harvest is admin-triggered and one-shot — secrets are not streamed on every heartbeat. The server can't read account.conf itself (0600 root); only the host's root agent can, which is why this runs through the agent. The device picker lists all agent devices, so it works even before the slow acme.sh cert scan has reported.

Optional: store tokens encrypted in the vault

By default, provider tokens live in config.json as clear text (0600). If you'd rather not keep them in clear, store them in the existing CMDB vault instead:

• Set up the CMDB vault if you haven't (Admin → CMDB), then on the DNS page click Unlock vault. To populate it, either Import from config (encrypts the credentials you already entered under ACME → DNS credentials into the vault, no re-typing, with the option to then delete the plaintext copy) or Enter token manually.
• Crypto is PBKDF2-SHA256 (600k iterations) → AES-256-GCM. The passphrase is never persisted server-side; unlocking derives a key that your browser holds for the session and sends per-request (X-RP-Vault-Key). The server decrypts the token in memory for that one request and discards it — no plaintext is written to disk. Click Lock to clear the key from the browser.
• The vault path is decrypt-on-demand, so it works for the interactive dashboard only — it cannot feed unattended ACME auto-renew (there's no passphrase at cron time). Plaintext acme_dns_credentials remains the fallback for automation; the dashboard prefers the vault token when unlocked.