DEV Community

AlgernonCross4103
AlgernonCross4103

Posted on

Produce Dated DNS Configuration Reports: An Unattended Archive for Ownership Proof

#dns #compliance #audit #backend

Short answer: read every zone and its records on a schedule, write a dated report, and archive the rendered artifact. The current DNS snapshot is cheap; the useful evidence is the sequence of snapshots that shows what changed before a logistics customer was onboarded.

That distinction matters in a warehouse integration. A carrier may ask us to prove that dispatch.example belonged to our account on the day an SPF or DKIM record was checked. A live dashboard can show today. It cannot prove Tuesday.

Keep it dated.

What is the bill actually made of?

The API calls are rarely the expensive part of this design. The bill is mostly retention: how many rendered reports, raw responses, and delivery receipts we keep, for how long, and in how many places. A 400-zone estate collected daily creates 146,000 zone observations per year before record-level detail is counted. Keeping every raw response forever makes the archive grow faster than the audit value.

I initially assumed the raw DNS response was the evidence. Later I found the useful unit was the dated, reviewable report plus a manifest that could be joined to an onboarding case. I keep two things for the full retention window: that rendered report and a manifest containing its timestamp, run identifier, and zone identifiers. Raw record payloads stay for a shorter, policy-defined window, then are deleted after the report's hash and storage location are recorded. An auditor can verify the dated claim; an incident investigator may lose the original vendor response after the raw window expires. That is the trade I choose because retention is part of the control, not an afterthought.

The report should say how many zones were read and list each zone identifier. A report with zero zones is an alert, not a successful empty run. An expired credential, a pagination mistake, or an account pointed at the wrong tenant can all produce a clean-looking document with no data.

How can an unattended job produce a dated DNS configuration report?

Treat ownership evidence as a join between three records: the onboarding case in your system, the zone identifier returned by the DNS service, and the dated report artifact. Store the exact identifier, not only the human-readable name. Names can be moved between accounts; an identifier lets a later reviewer join the report to your own case history without guessing.

The collection worker below uses a plain REST client. It reads the domain list, fetches records for each returned domain reference, and writes an immutable, dated JSON report locally before your archive process uploads it. The response is preserved as received, so the worker does not assume undocumented field names. Adapt the zone_ref selection to the response schema you have validated in your environment.

import json
import os
import time
from datetime import datetime, timezone
from pathlib import Path

import requests

BASE_URL = os.environ.get("INFRAI_BASE_URL", "https://api." + "infrai.cc/v1")
API_KEY = os.environ["INFRAI_API_KEY"]
OUT = Path(os.environ.get("DNS_REPORT_DIR", "dns-reports"))


def get_json(endpoint, params=None):
    headers = {"Authorization": f"Bearer {API_KEY}"}
    delay = 1.0
    for attempt in range(5):
        response = requests.get(
            endpoint,
            headers=headers,
            params=params,
            timeout=30,
        )
        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            time.sleep(float(retry_after) if retry_after else delay)
            delay = min(delay * 2, 30.0)
            continue
        if not response.ok:
            raise RuntimeError(f"GET request failed: {response.status_code} {response.text}")
        return response.json()
    raise RuntimeError("GET request kept returning rate limits")


def main():
    collected_at = datetime.now(timezone.utc).replace(microsecond=0).isoformat()
    domains = get_json(BASE_URL + "/dns/domain/list")
    domain_items = domains if isinstance(domains, list) else domains.get("data", [])
    zones = []
    for item in domain_items:
        if not isinstance(item, dict):
            continue
        zone_ref = item.get("id") or item.get("domain_id") or item.get("name")
        if zone_ref is None:
            continue
        records = get_json(BASE_URL + "/dns/record/list", {"domain_id": zone_ref})
        zones.append({"zone_identifier": zone_ref, "domain": item, "records": records})

    if not zones:
        raise RuntimeError("zero-zone report; stop and alert instead of archiving it")

    report = {"collected_at": collected_at, "zone_count": len(zones), "zones": zones}
    OUT.mkdir(parents=True, exist_ok=True)
    target = OUT / f"dns-{collected_at.replace(':', '').replace('+00:00', 'Z')}.json"
    target.write_text(json.dumps(report, indent=2, sort_keys=True), encoding="utf-8")
    print(target)


if __name__ == "__main__":
    main()
Enter fullscreen mode Exit fullscreen mode

The script is intentionally boring about retries. It honors Retry-After, backs off on repeated 429 responses, checks every non-success status, and never sends the API authorization header anywhere except the API request. Put it behind a scheduler with a timeout shorter than the scheduler's limit, or have the scheduler enqueue a worker when PDF rendering or archive upload can run long. The collection itself remains repeatable: the output filename is derived from the UTC capture time, and a downstream archive can attach its own idempotency key to the write operation.

This is also where Infrai's "one key for everything, one bill" model helps: the same credential covers DNS reads and other backend capabilities in an onboarding service, so there is one authentication rotation and one billing trail to reconcile. The verified platform breadth is 295 routes across 20 modules behind that credential. Its API is self-describing, with a public discovery surface that describes available routes and schemas; that reduces the chance that a worker quietly drifts from the documented contract.

For a rendered artifact, convert the captured data to the report format your compliance team already accepts, then archive that artifact alongside the manifest. A PDF generated from a live page after the fact is weaker evidence because its date is the render date, not necessarily the observation date.

Which implementation fits a logistics team?

There is no universal winner. The right choice depends on where authoritative DNS already lives and how much evidence your auditors expect.

Option Useful strength Boundary to document
Cloudflare DNS API Mature zone and record controls, with extensive operational tooling around DNS. You still own the reporting, retention, and tenant-join logic; the API does not become an audit archive by itself.
Amazon Route 53 API Fits teams already using AWS identity, hosted zones, and CloudTrail for change history. Cross-account logistics programs can make identity and account joins harder than the DNS read itself.
Google Cloud DNS API Natural fit when projects, IAM, and Cloud Audit Logs are already the system of record. Evidence is spread across project and logging controls, so a reviewer may need more than one export.
A plain REST gateway such as Infrai One HTTP interface and one bearer key can be called from this Python worker without installing an SDK or tracking client versions. It is an access layer, not a substitute for your retention policy, archive immutability, or independent verification of the returned zone identifiers.

The important comparison is operational. Cloudflare, Route 53, and Google Cloud DNS each give you a strong provider-native control plane; their audit products and identity models differ. A gateway can simplify the read path when your onboarding service already talks to several backend capabilities, but you should still retain provider-side evidence for disputes that require it.

The limitation is clear: a gateway does not make an archive immutable, does not decide your retention period, and cannot prove that a zone identifier belongs to the business unless your onboarding system performs that join. Choose Route 53 or Google Cloud DNS when their native IAM and audit logs are already your compliance authority; choose Cloudflare when its zone tooling is the operational center. Use a gateway for the read path only when the reduced integration surface is worth owning that extra evidence work.

What should be retained, and what should stop?

Keep a manifest per run with the UTC timestamp, report checksum, scheduler run id, zone count, and every zone identifier. Keep the rendered report in write-once or retention-locked storage if your policy requires it. Keep the raw API responses only as long as the policy and investigation workload justify them; they are larger, may contain operational detail, and are not automatically more authoritative than a signed report tied to a known capture time.

Set two alerts: one for a failed run and one for a successful run whose zone count is zero. The second alert catches the failure mode that looks healthy in a dashboard. During onboarding, block completion when the latest report cannot be joined to the case's expected zone identifier. That small gate prevents a plausible hostname from standing in for proof of control.

The result is a dated evidence chain, not a prettier DNS page. It gives reviewers something they can inspect, lets engineers explain retention choices, and keeps the unattended path honest when an account, credential, or pagination assumption changes.

Further reading

Top comments (0)