Bulk edit your DNS records

Some DNS chores mean doing the same edit twenty times. Dropping TTLs to 5 minutes before a migration. Pointing a pile of subdomains at a new IP. Cleaning out old verification TXT records nobody remembers adding. Until now that was twenty trips through the edit dialog.

Now you tick the records you want and pick an action.

The actions

• Delete removes every selected record from the provider.
• Set TTL gives all of them the same TTL.
• Set content replaces the value. Handy when a server's IP changes and a dozen A records point at it.
• Set proxied turns Cloudflare's proxy on or off for the selection. It only shows up on Cloudflare zones, since no other provider has a proxy, and applies to A, AAAA, and CNAME records.

Where it works

Bulk edit lives on the zone page, where you work on one zone at a time. The Records page also supports it. That page lists records across all your zones, so you can search for an old IP address, select every match, and update them all at once, even when they're spread over different zones and providers.

Read-only records can't be selected. That covers SOA, apex NS, and Route 53 alias and routing-policy records, so a careless "select all" won't touch them.

One alert per action

A bulk edit sends one change notification per zone, not one per record. Delete 20 records and each destination gets a single alert listing all 20. On the Records page, a selection that spans three zones produces three alerts, one per zone. Very large selections go out in batches of 100 records, with one alert per batch.

The zone history still gets an entry for every record, so you can see exactly what the bulk action did and restore any single record from it.

Only the field you picked changes

A bulk TTL change sets the TTL and nothing else. DNScheck reads each record's current state on the server before writing. If someone changed a value at the provider after you opened the page, the bulk edit leaves that value alone instead of putting back the copy your browser had.

What happens on failure

Records are applied one at a time at the provider. If one fails, the rest still go through, and you get a summary like "18 updated, 2 failed". Provider writes can't be rolled back cleanly, so DNScheck doesn't try to undo the records that succeeded. The alert only lists changes that actually went through, and if nothing went through you get no alert at all.

"Skipped" means the change didn't apply to that record. Setting the proxy flag on an MX record is one example.

If you close the tab halfway through, the records already written still get saved to history, and the alert still goes out.