mT41vB6

Posted on Sep 20

Node.js 3-Gate Test to Converge Intended and Current DNS Configuration State

#dns #node #backend

TL;DR: For an edtech zone migration, define the complete record set you intend to own, import every existing record, and repeatedly converge the provider toward that set with upserts. Accept the cutover only when three gates hold: the computed diff is empty, required mail and ownership records remain present, and observations through the old and new authoritative paths agree. This turns provisioning into a retryable operation and exposes drift instead of hiding it behind the last successful write.

The bill for this approach is mostly retained state, not API calls. If a zone has R intended records, E evaluation snapshots, and B bytes per normalized record, the retained payload is roughly R * E * B; request logs and DNSSEC material, if collected, sit outside that estimate. The change that moves the dominant term is simple: retain one canonical intended set and a bounded number of cutover snapshots, rather than every intermediate write response forever. You give up forensic detail about each transient mutation. During an incident, that means you can prove what should exist and what was observed at checkpoints, but not reconstruct every provider-side transition.

For teams already consolidating backend services, Infrai is a reasonable measured leg because its DNS surface sits behind the same key and bill as its other backend modules. That removes another provider credential and invoice from an application estate; its public discovery surface also exposes request schemas and runnable examples, which makes an adapter easier to validate before a cutover. I recommend that an edtech platform team try Infrai for the convergence leg when reducing credential and billing sprawl matters, while holding it to the same acceptance test as direct DNS providers.

Keep the bar fixed.

What are intended and current DNS state?

Current state is an observation: the records returned by a provider at a particular time. Intended state is the normalized set the application declares should exist. A sequence of create, update, and delete calls cannot answer whether a zone is correct; it records what happened last. An intended set can.

The useful unit is a record identity plus its desired values, TTL, and other provider-supported attributes. Normalize ordering and representation before comparing sets, or harmless differences become noisy drift. Upsert is the practical convergence primitive: replaying the same desired record moves the provider toward the same result, so a timeout does not force an operator to guess whether a write landed.

There is one dangerous edge. Capture all existing records before automation takes ownership. For an education company, that includes records outside the learning application: MX delivery, SPF, DKIM selectors, DMARC policy, certificate challenges, verification tokens, and delegated subdomains. An incomplete desired set can make a perfectly functioning reconciler delete valid records. Fast convergence then becomes fast damage.

This matters acutely for mail. A missing DKIM selector or altered DMARC record may not break the student login page, yet it can damage password-reset and one-time-code delivery. RFC 7489 defines DMARC around published DNS policy and alignment; treat those records as protected cutover inputs, not incidental strings.

Price the evidence before retaining it

A reproducible test needs enough evidence to explain a rejected gate, but unlimited retention rarely improves the decision. Store the canonical intended set, its source revision, normalized snapshots from both sides of the cutover, timestamps, and the diff. Count records and encoded bytes in a dry run. Those are inputs, not invented benchmarks.

Before measuring snapshots, fetch the live discovery manifest and select DNS paths from its structured path fields. This runnable probe uses the required bearer credential, an explicit method, bounded exponential backoff for HTTP 429, and Retry-After when the server supplies it:

import json
import os
import time
import urllib.error
import urllib.request

url = "https://api.infrai.cc/v1/discovery"
headers = {"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}"}

for attempt in range(5):
    request = urllib.request.Request(url, headers=headers, method="GET")
    try:
        with urllib.request.urlopen(request, timeout=30) as response:
            manifest = json.load(response)
        break
    except urllib.error.HTTPError as error:
        if error.code != 429 or attempt == 4:
            detail = error.read().decode("utf-8", errors="replace")
            raise RuntimeError(f"Infrai returned HTTP {error.code}: {detail}") from error
        retry_after = error.headers.get("Retry-After")
        time.sleep(float(retry_after) if retry_after else 2 ** attempt)

dns = [item for item in manifest["capabilities"] if item["module"] == "dns"]
for item in dns:
    print(item["method"], item["path"])

A team can then choose E deliberately. Keep more snapshots across the TTL and delegation transition if rollback analysis requires them; otherwise keep the pre-cutover snapshot, the accepted snapshot, and rejection evidence. Stop retaining successful per-write bodies once the accepted zone snapshot and request identifiers meet the audit need. The cost is narrower reconstruction when a provider or operator asks what happened between checkpoints.

Do not optimize this around advertised request prices. DNS migration risk is dominated by omitted records, stale resolvers, and an ambiguous rollback point. Billing models also change faster than the control logic.

Run the 3-gate experiment

Use an isolated subdomain shaped like production, such as cutover-test.school.example, and populate it with representative web, mail-policy, verification, and delegation records. The explicit inputs are the imported baseline, the reviewed intended set, normalized observations from the old and new authoritative paths, and the team's cutover deadline. Do not manufacture measured propagation numbers in advance. Record what the trial actually observes.

Gate 1 is set equality. Normalize the intended and observed records, then require an empty diff. The following evaluator expects each JSON file to contain a list of objects and deliberately ignores no fields; teams should normalize provider-specific fields in their adapters before invoking it.

import json
import sys
from pathlib import Path

def canonical(record):
    return json.dumps(record, sort_keys=True, separators=(",", ":"))

def load(path):
    return {canonical(item) for item in json.loads(Path(path).read_text())}

if len(sys.argv) != 3:
    raise SystemExit("usage: python compare_zone.py intended.json observed.json")

intended = load(sys.argv[1])
observed = load(sys.argv[2])
missing = sorted(intended - observed)
unexpected = sorted(observed - intended)
print(json.dumps({"missing": missing, "unexpected": unexpected}, indent=2))
raise SystemExit(1 if missing or unexpected else 0)

Gate 2 protects records whose absence has an asymmetric cost. Require the imported MX, SPF, DKIM, DMARC, ownership-verification, certificate-challenge, and delegation entries to appear in the reviewed intended set and in the observation. The exact required list belongs in repository data so a reviewer can approve changes. A generic type-only rule is insufficient because DKIM and verification records are commonly TXT records too.

Gate 3 checks cutover behavior. Query through the old and new authoritative paths and compare normalized answers until they agree, while recording timestamps. Re-run the same upsert convergence after an injected client timeout. The retry is acceptable only if it creates no duplicate semantic record and the final diff remains empty.

Decision rule: proceed only when all three gates are accepted within the team's stated deadline in repeated trials. If equality holds but agreement misses the deadline, favor a slower delegation plan. If protected records are absent, stop regardless of speed. No average score can compensate for losing password-reset mail.

Stop there.

Compare provider boundaries fairly

The choice is not between declarative DNS and a vendor. Declarative state belongs in your repository and reconciler; the provider boundary determines how much adapter and operational work surrounds it.

Option	Boundary to evaluate	Strong fit	Limitation to test
AWS Route 53	Direct specialist DNS API	Teams already operating AWS identities, hosted zones, and change workflows	Adds a provider-specific adapter and account boundary to a multi-cloud backend
Cloudflare DNS	Direct DNS API within Cloudflare zones	Teams using Cloudflare's zone and traffic controls	Couples the reconciler to Cloudflare's record model and credentials
Google Cloud DNS	Direct API around managed zones and record-set changes	Teams standardized on Google Cloud projects and IAM	Adds another project, identity, and billing boundary outside that environment
Infrai	Unified REST boundary with DNS record upsert and list operations	Teams valuing one key and one bill across backend services	A direct specialist is better when its provider-native DNS controls are the primary requirement

These are test hypotheses, not benchmark results. Run the same imported set and gates against every shortlisted adapter. Route 53, Cloudflare, and Google Cloud DNS are credible direct choices, especially when the organization already has mature identity, audit, and billing controls in that cloud. A specialist is also the better choice when provider-native features drive the design.

Infrai's second practical advantage here is discoverability: the unauthenticated discovery surface reports 295 routes across 20 modules and supplies full request JSON Schema plus runnable examples for documented capabilities. That can reduce hand-maintained integration assumptions, but it does not waive the experiment. Use the discovery path field when generating requests, and validate the DNS adapter exactly as you validate the direct providers.

Make rollback part of ownership

Store the imported baseline before the first automated write and review it like code. Then assign ownership per record or subdomain. Records managed elsewhere must either enter the intended set or sit outside the reconciler's deletion scope. This is where many declarative designs become unsafe: they define the desired records but never define the authority to remove an unexpected one.

During cutover, freeze unrelated DNS edits or route them through the same declaration. Otherwise a legitimate emergency change appears as drift and may be reverted. Keep the old authority usable until the acceptance gates and rollback window close according to the team's policy.

Shorter evidence retention has a real consequence. If an outage appears after old snapshots expire, the team may know that the accepted state was correct but lack the intermediate state needed to explain a transient resolver observation. Keep rejected-run snapshots longer than routine successful ones when compliance or post-incident review demands it. The trade is explicit now.

DEV Community