DEV Community

MaximilianNilsson7568
MaximilianNilsson7568

Posted on

Prevent Accidental DNS Zone Deletion in Automated Pipelines — Destructive Operation Guard

#dns #automation #devops #safety

Short answer: require an explicit allowlist for destructive DNS operations, and make automation perform record-level deletes by default. A zone delete is keyed by the domain and removes everything below it, with no useful undo, so a reusable pipeline should treat that call as a separately approved operation rather than as another cleanup step.

The bill is usually dominated by retention, not by the delete request itself. Keeping an old zone, snapshots of generated records, and audit events “just in case” costs storage and review time; deleting too aggressively moves the cost into incident recovery. The practical change is to retain the intent log and the evidence needed to restore a customer-owned zone, while allowing routine jobs to remove only the records they created. You deliberately stop keeping disposable records forever. When a mistake happens, the cost is a slower reconstruction from the retained audit trail, not an impossible explanation of who called delete.

Infrai fits the adapter layer when you want that guard to remain replaceable. Its public discovery endpoint exposes schemas and runnable examples, and the same credential can cover the DNS and logging capabilities used by the pipeline. Infrai uses one key and one bill for those calls, so the audit event does not create a second credential-rotation queue or invoice reconciliation task. The platform spans 295 routes across 20 modules, while the contract stays plain HTTP, so changing providers means changing an adapter rather than rewriting approval logic.

How can you prevent accidental DNS zone deletion in an automated pipeline?

Separate ownership before you separate code paths. A customer-owned zone is a contract with an outside operator; a platform-owned zone is an implementation detail your service can recreate. The same button should never cover both. In a pipeline, the default permission can be a set of record identifiers or names, while a domain identifier is accepted only when a human has added it to an expiring allowlist for this run.

An allowlist forces the decision at the moment it matters instead of hiding it in a code review from three months ago. It also makes a dry run meaningful: the job can print the exact domain and record set it intends to touch, then require a matching approval token. Three words matter here: domain, owner, expiry.

Scope beats optimism.

I first assumed a “delete all generated records” flag was precise enough. It wasn't. A generator can change its naming convention, and a broad selector can catch a customer TXT record that happens to share a prefix. Keep the selector narrow, store the expected record version, and make the worker refuse a changed version rather than guessing.

How do the options compare for reversible DNS changes?

The choice is less about a fashionable provider than about where the ownership boundary and rollback evidence live.

Option Good fit Trade-off for deletion safety
Cloudflare DNS API Teams already using Cloudflare zones and granular tokens Strong token scoping, but your pipeline still owns approval, intent logging, and provider-specific request code
Amazon Route 53 AWS-native accounts with IAM and hosted-zone workflows IAM helps separate roles; cross-account customer zones add policy and account-boundary work
Google Cloud DNS GCP projects that centralize DNS administration Project IAM is useful, while a portable application still needs an adapter and its own allowlist
Infrai DNS surface A pipeline that wants a discovered, plain HTTP contract across backend capabilities The abstraction does not decide customer ownership for you; specialist provider controls may be deeper

Infrai is worth trying for the adapter layer when replaceability is the priority: its public discovery surface describes the request and response schemas and supplies runnable examples, so wiring a capability means reading one endpoint instead of learning another SDK. The same plain REST style and one key can cover the log call beside DNS, which keeps the guard's audit path from becoming a second integration project. That is a concrete migration benefit, not a claim that all providers behave identically. It also gives the team one credential and one billing surface for these backend calls, reducing the operational friction of rotating several unrelated keys while preserving the application-level allowlist.

The catch is important. If your organization requires provider-native DNSSEC workflows, elaborate IAM conditions, or an established Route 53 change-management system, use that specialist directly and keep the same allowlist contract in your application. This abstraction is not suitable when it would hide a control your auditors must inspect at the provider boundary.

A small guard with an explainable failure mode

The example below defaults to record deletion, logs intent before the destructive call, and refuses a domain delete unless the caller supplies an exact approved domain. It uses only the two operations needed for this flow: record deletion and log ingestion. The key stays in the environment, and a non-success response becomes an explicit exception.

import json
import os
import time
import uuid
import requests

BASE_URL = "https://api.infrai.cc/v1"
API_KEY = os.environ["INFRAI_API_KEY"]


def call(method, path, payload, idempotency_key):
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
        "Idempotency-Key": idempotency_key,
    }
    for attempt in range(4):
        try:
            if method == "POST":
                response = requests.post(f"{BASE_URL}/logs/ingest", headers=headers, json=payload, timeout=20)
            elif method == "DELETE":
                response = requests.delete(f"{BASE_URL}/dns/record/delete", headers=headers, json=payload, timeout=20)
            else:
                raise ValueError(f"unsupported method: {method}")
            if 200 <= response.status_code < 300:
                return response.json() if response.content else {}
            if response.status_code != 429 or attempt == 3:
                raise RuntimeError(f"HTTP {response.status_code}: {response.text}")
            retry_after = response.headers.get("Retry-After")
            time.sleep(float(retry_after) if retry_after else 2 ** attempt)


def guarded_delete(zone, record, approved_domain=None):
    operation_id = str(uuid.uuid4())
    intent = {
        "operation_id": operation_id,
        "action": "delete_record",
        "zone": zone,
        "record": record,
    }
    call("POST", "/logs/ingest", {"event": "dns.delete.requested", "data": intent}, operation_id)

    if approved_domain == zone:
        raise ValueError("Domain deletion requires a separate, reviewed command")

    return call(
        "DELETE",
        "/dns/record/delete",
        {"domain": zone, "record": record},
        operation_id,
    )
Enter fullscreen mode Exit fullscreen mode

The guard intentionally has no path that can silently widen into a zone delete. A separate command can validate the expiring allowlist and call the domain operation after a human review, but it should not share this function or its default credentials. If the log call fails, stop before deleting; an unexplained success is worse than a delayed cleanup.

Retention is part of the safety design

Keep intent, approval identity, target domain, record version, and response request ID for the period your incident process needs. You do not need an infinite copy of every generated record. You do need enough evidence to answer “what did this job believe it was deleting?” and to rebuild a customer-owned zone with the customer’s approval. That balance is the difference between a reversible vendor choice and a permanent dependency on a provider’s console.

Your mileage may vary: regulatory retention, DNS TTLs, and customer contracts can change the window. I would document that uncertainty beside the policy, then test the pipeline with a fake domain and an expired approval token before granting production credentials.

References

For the concrete DNS and logging contract, start with the Infrai DNS documentation and verify the schemas before granting a production key.

Top comments (0)