What's New

On iPhone and iPad, tapping a delete button (or any other action that asks for confirmation) could leave the button spinning forever without ever showing the confirmation prompt. This happened after navigating back to a page, and only a reload would fix it. The culprit was a Safari quirk that silently blocks the browser's built-in prompts after a back swipe. Confirmations now appear as a regular dialog on the page itself, which is immune to the quirk, and the button spinner no longer starts until you have confirmed. As a bonus, cancelling a confirmation no longer leaves a stuck spinner on any platform.

Entries in your personal activity feed (RSS) now use the same friendly event names as the dashboard, such as "DNS Synced", instead of raw internal event codes. Failed DNS syncs also no longer show technical error details in the feed or on the activity page.

The email security wizard now has a "this domain's own mail server" option and keeps everything your SPF record already authorized. Before, picking a provider (e.g. Google or Hetzner) would overwrite the whole record and quietly drop the entry for a mail server you host yourself, which could start sending your outgoing mail to spam. The wizard now preserves those entries and pre-selects your own server when it sees one.

If you added a record and removed it again before deploying (or a record was already provided by a template), a domain could get stuck showing "Changes Pending" while the deploy preview said there was nothing to deploy — with no way to clear it. The preview now offers a "Clear Pending Flag" action in that case, so the domain returns to a clean state.

The fleet monitor now automatically pauses probing when a dynamic host goes stale — so you won't get false down-alerts if the IP has moved. Monitoring resumes automatically on the next valid DynDNS update.

The legacy /opdat, /opdat.php, /update, /update/simple, and /pro/dynamic endpoints now return the standard DynDNS2 response vocabulary: "good {ip}" on a successful change, "nochg {ip}" when the submitted address matches what's on file, and the standard error codes "abuse", "badauth", "nohost", "notfqdn", "911". Previously they returned homegrown "OK: IP updated to ..." and "ERROR: ..." strings that some standards-compliant routers (e.g. D-Link DSR-250N) couldn't parse, causing them to retry successful updates indefinitely and trip the per-hostname rate limiter. If you have scripts or clients that grep for the old strings, update them to match the DynDNS2 codes. /api/v1/nic/update has always returned these codes and is unchanged.

A regression in v1.14.0 caused edits to existing DNS records to redirect like normal but silently discard the change — renames, value updates, TTL changes, everything. Fixed. If you tried to edit a record in the last day and the change didn't stick, try again.

The propagation check page was marking every resolver as "Stale" even when the answers were correct. Blank expected-value fields are now ignored, and CNAME / MX / NS / SOA comparisons are case-insensitive and tolerate trailing-dot differences between dig and the built-in resolver.

Zones that were checking in normally were sometimes auto-disabled by the stale-zone cleanup because the expiration date was never pushed forward. Every DynDNS update now extends the expiration by 180 days, keeping active zones active.

All delete actions now show a confirmation dialog before proceeding. Forms across the site have been modernized with Turbo Rails for a smoother experience.