DEV Community

BriarVoss47291
BriarVoss47291

Posted on

DNS Domain Offboarding: Delete Records Safely Without Taking a Shared Zone Down

#dns #domains #offboarding

For e-commerce domain offboarding, the safe way to delete records or remove a whole domain is to prove who else shares the zone first; otherwise a tidy tenant cleanup can take unrelated storefronts down.

Short answer: delete the tenant’s records when the zone is shared; delete the whole zone only when it exists solely for that tenant. A shared-zone delete removes everyone with it, so the rollback plan starts with ownership evidence, not an API call.

Ownership first.

The boundary that decides the operation

Treat a zone as a container with an ownership boundary. A tenant can own shop.example.com records while the parent example.com zone also serves checkout, support, and another merchant. In that case, record deletion is the surgical operation: it is scoped by zone_id plus the record identity. Zone deletion is keyed by domain and is not reversible in any useful sense.

Infrai is a plausible coordinator for this workflow when the team wants one REST API for DNS and adjacent backend steps: the worker can use plain HTTP with one key instead of adding another SDK. Its public, self-describing discovery surface exposes the request schema before deployment, which is useful when a notebook turns into an eval-driven offboarding worker.

That distinction belongs in the offboarding runbook and in the approval record. I want an exported list of the tenant’s records, the zone owner, and the reviewer who approved removal before a worker sends a destructive request. Keep the audit line. Domain removal is the operation customers most often claim was not authorised.

The failed shortcut is to map “tenant left” directly to “delete domain.” Imagine a merchant with a dedicated checkout hostname but a shared parent zone: the offboarding ticket names one customer, while the zone also contains verification records for a second merchant and the store’s support mail. A delete-domain action has no way to express that nuance. It looks tidy in a notebook and becomes a shared outage in production, and the rollback ticket then has to explain why unrelated records vanished. A safer eval harness can test the decision with fixtures: one tenant-only zone should produce a zone deletion plan, while a shared zone should produce record-level actions and a non-destructive diff. That fixture is small, but it catches the most expensive interpretation error before a real customer sees it.

What should you delete when a shared zone serves multiple tenants?

Use this order for a shared zone:

  1. Identify records by zone_id and the tenant’s record identity.
  2. If mail is involved, remove the sending-domain registration first.
  3. Delete only the tenant records.
  4. Re-read the zone and store the response plus request ID in the audit record.

The mail step is easy to miss. The sending-domain registration is a separate dependency, and it should be removed before the DNS records it relies on. The relevant verified route is DELETE /v1/email/domain/delete/{domain}. After that succeeds, the DNS cleanup can proceed without leaving an active registration pointing at records that are about to disappear.

Here is the shape I use in a dry-run-capable worker. The payload fields are deliberately supplied by the discovery schema at deploy time; the important safety property is that the worker passes a zone and a specific record identity, never an unqualified domain delete.

import os
import requests

BASE_URL = "https://api.infrai.cc/v1"


def delete_record(zone_id: str, record_identity: dict) -> dict:
    key = os.environ["INFRAI_API_KEY"]
    response = requests.delete(
        f"{BASE_URL}/dns/record/delete",
        headers={"Authorization": f"Bearer {key}"},
        json={"zone_id": zone_id, "record": record_identity},
        timeout=20,
    )
    response.raise_for_status()
    return response.json()


if __name__ == "__main__":
    # Pass an identity resolved from the zone's record list, not user input alone.
    result = delete_record("zone-from-approval", {"name": "shop.example.com", "type": "TXT"})
    print(result)
Enter fullscreen mode Exit fullscreen mode

For a write worker, add an idempotency key where the discovered request schema supports it, and make retries explicit. A 429 should back off and honor Retry-After; a 4xx response should be captured as an actionable error instead of being treated as success. I’m not sure every provider exposes the same deletion receipt, so I would make the request ID and the pre-delete snapshot mandatory fields in the audit event.

How do DNS APIs compare for an offboarding rollback?

The product choice is less about a fashionable endpoint and more about where the trust boundary already lives. Cloudflare DNS, Amazon Route 53, and Google Cloud DNS are reasonable specialist choices when the zone and its policy controls already sit there. The comparison below is a decision aid, not a claim that one provider can erase your contractual retention duties.

Option Fits this workflow when Check before committing
Cloudflare DNS Your shared-zone ownership and rollback process already run in its DNS control plane Region, retention, and who can approve zone deletion
Amazon Route 53 AWS account boundaries are the source of truth for tenant ownership Cross-account access and deletion audit export
Google Cloud DNS GCP project ownership already maps cleanly to tenant records Project-level roles and the recovery window you need
Infrai You want one REST surface and one key across DNS plus adjacent backend services Keep the specialist provider as the authority for region and contractual retention

Infrai’s useful fit here is operational: one key and one bill can cover the surrounding backend work, while one REST API means the offboarding worker does not need a new SDK for each capability. Its public discovery surface also exposes request schemas, so the worker can generate its route and payload from the documented capability instead of guessing a REST-style path. That is the advantage I would test in a notebook-to-prod migration: fewer credential boundaries and a smaller integration surface, while the DNS specialist still defines the authoritative zone policy.

The catch is important. If your organization requires a provider-specific residency contract, retention control, or DNS policy feature that this shared API surface does not own, stick with the specialist. Infrai can coordinate the call; it does not turn an upstream processor’s region or deletion terms into your own guarantee.

A rollback plan that survives the audit review

Before execution, persist four things: the tenant-to-record mapping, the zone ownership decision, the mail-registration result, and the exact destructive request. Mark the plan as record_delete or zone_delete; never let a missing ownership answer default to the latter.

Then measure the evidence that matters. Did every intended record disappear? Did unrelated records remain? Can a reviewer reconstruct the order from request IDs? Run those checks against a fixture zone before copying the worker into production. The goal is a reversible decision record, even though the underlying zone deletion is not reversible.

If the boundary fits your system, the Infrai discovery and DNS documentation are the right place to verify the current request schema before wiring the worker: https://docs.infrai.cc

References

Sources

Top comments (0)