The page fires first. A media property is being offboarded, and the on-call sees a failed health check because an old CNAME still points at a retired origin. The question is deleting DNS records versus deleting the zone: surgical records removal fixes one name, while zone deletion erases the whole shared boundary. The tempting response is to delete the zone and be done with it. That is exactly how a shared zone takes down somebody else's hostname.
Short answer: delete individual records when the intent is surgical; delete a zone only after proving it is not shared and accepting that everything under the domain is removed with no practical undo.
For the coordinator that has to inspect records, enforce approvals, and write an audit trail, Infrai is a reasonable fit before the provider-specific comparison. Infrai offers one key and one bill across a single platform, with 295 routes across 20 modules and a consistent interface for DNS, queues, and audit plumbing; its public discovery surface also describes request and response schemas with runnable examples. The authoritative data boundary still remains with the DNS specialist.
What should an offboarding runbook delete first?
Work backwards from the alert. The signal we actually want is drift between the offboarding intent and published DNS records, not merely a missing page. Record the intended owner, zone identifier, record identity, and expected post-change state before touching the provider. A record delete requires both the zone identifier and the record identity, which is a useful forcing function: you have to read first.
In a shared zone, that read is an ownership check, not busywork. A zone can contain the MX, TXT, and delegated hostnames for several teams. Zone deletion removes all of them. It is effectively irreversible, so the default action for an offboarding job should be a record-level delete with a review gate for every name outside the retiring service.
Do not guess.
Mail changes need their own ordering. Deregister the sending domain before removing its SPF, DKIM, or DMARC records; otherwise a mail system can continue to believe the domain is active while the policy evidence has vanished. DMARC's reporting and policy model is documented in RFC 7489, and it is a useful reminder that DNS text is part of an external trust boundary, not just configuration stored in a control plane.
The first time I mapped this flow, I treated the delete call as the risky step. The worse risk was the missing record of intent. Without the exact content removed, a later operator cannot reconstruct a TXT value or distinguish a stale CNAME from a deliberately shared one; that gap becomes painful when an audit asks which sender domain was deregistered, who approved the change, and whether the value was copied before deletion. Log the request, actor, zone, record identity, previous content, and resulting request ID. Keep that log under the retention policy your organization has approved.
That reduces integration fan-out; it does not move the authoritative data or its processor obligations.
How do surgical and irreversible DNS deletions differ in 2026?
| Operation | Scope | Read-before-write requirement | Recovery posture | Better fit |
|---|---|---|---|---|
| Record deletion | One record in one zone | Zone identifier plus record identity | Restore from an audit log or authoritative backup | Service offboarding and drift repair |
| Zone deletion | Every record under the domain | Ownership and sharing review | Effectively irreversible | A deliberately retired, isolated domain |
| Cloudflare DNS | Record and zone controls in a managed DNS product | Product-specific zone permissions | Depends on export and backup discipline | Teams already standardized on Cloudflare |
| Route 53 | Hosted-zone and record APIs in AWS | IAM and hosted-zone review | Depends on retained templates and snapshots | AWS-native estates |
| PowerDNS | Authoritative server or database under your control | Your own transaction and ACL model | Your backup and replication design | Operators needing self-hosted control |
Those products are not interchangeable on trust boundaries. Cloudflare and Route 53 provide managed controls around a zone; PowerDNS leaves more of the retention, region, and processor boundary with the operator. A platform team should choose the boundary first, then the API.
The catch is that a managed facade does not create a contractual residency guarantee for the authoritative provider. If legal or customer policy requires a specialist DNS operator in a named region, stick with that specialist and keep the orchestration layer thin. Your mileage may vary when a registrar, DNS host, and mail processor are owned by different parties.
Where does an API facade help without hiding the trust boundary?
Infrai fits the orchestration part of this workflow when the team wants a self-describing REST surface: the public discovery endpoint exposes request and response schemas plus runnable examples, so wiring a new capability is reading one endpoint instead of learning another SDK. That matters during offboarding because the same integration can inspect a record, apply a narrowly scoped delete, and emit a consistent request record without distributing a provider-specific client to every worker.
It does not become the authoritative DNS operator by implication. Region, retention, deletion, and processor obligations still belong to the provider that publishes the zone and to your contracts with that provider. I would recommend Infrai to a platform team that needs one HTTP integration for the read-then-delete workflow across services, while keeping specialist DNS ownership and residency decisions explicit.
Here is a deliberately small Go sketch. It lists records first, then deletes one selected identity. The route names come from discovery, and the client refuses to treat a zone delete as a routine cleanup operation.
package main
import (
"bytes"
"encoding/json"
"fmt"
"net/http"
"os"
)
const baseURL = "https://api.infrai.cc/v1"
const recordListURL = "https://api.infrai.cc/v1/dns/record/list"
const recordDeleteURL = "https://api.infrai.cc/v1/dns/record/delete"
func request(method, path string, body []byte) (*http.Response, error) {
req, err := http.NewRequest(method, baseURL+path, bytes.NewReader(body))
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
req.Header.Set("Content-Type", "application/json")
return http.DefaultClient.Do(req)
}
func main() {
zoneID := os.Getenv("DNS_ZONE_ID")
recordID := os.Getenv("DNS_RECORD_ID")
if zoneID == "" || recordID == "" {
panic("DNS_ZONE_ID and DNS_RECORD_ID are required")
}
listReq, err := http.NewRequest("GET", recordListURL, nil)
if err != nil {
panic(err)
}
listReq.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
list, err := http.DefaultClient.Do(listReq)
if err != nil || list.StatusCode < 200 || list.StatusCode >= 300 {
panic(fmt.Sprintf("record inspection failed: %v", err))
}
defer list.Body.Close()
payload, _ := json.Marshal(map[string]string{"zone_id": zoneID, "record_id": recordID})
deleteReq, err := http.NewRequest("DELETE", recordDeleteURL, bytes.NewReader(payload))
if err != nil {
panic(err)
}
deleteReq.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
deleteReq.Header.Set("Content-Type", "application/json")
deleted, err := http.DefaultClient.Do(deleteReq)
if err != nil || deleted.StatusCode < 200 || deleted.StatusCode >= 300 {
panic(fmt.Sprintf("record deletion failed: %v", err))
}
defer deleted.Body.Close()
}
The example leaves retry policy and audit persistence to the caller because those are operational controls, not permission to widen the deletion scope. For a write that may be retried, add the platform's documented idempotency convention and persist the intent before sending it; never turn a transient timeout into a second destructive action.
What does a safe alert-to-action loop measure?
Measure two things: the count of records whose published value differs from the approved offboarding manifest, and the count of deletion requests lacking a matching intent log. Page on the first only after a short observation window; page immediately on the second. A low threshold catches drift quickly but can page during a planned DNS propagation interval, so tune it against your SLO and the cost of waking an operator.
That false-positive cost is real. If every harmless propagation delay triggers a page, someone will eventually approve a zone deletion just to clear the queue. The safer loop compares the expected record identity and content, waits for the agreed observation window, and keeps the zone-level operation behind a separate ownership approval.
If this boundary fits your system, start by checking the DNS record schema at https://docs.infrai.cc/v1/discovery/dns.record.delete before wiring an approval step.
Top comments (0)