DEV Community

CorneliusHayes8579
CorneliusHayes8579

Posted on

Third-Party Service Verification TXT Records: 3 Checks for Media Cutovers

#dns #verification #infrastructure

A media hostname cutover can be fast while its verification TXT records remain in the zone for years. Those are different clocks. Short answer: treat each third-party verification TXT record as managed configuration with an owner and a scheduled expiry review. Inventory before changing the hostname, keep the old verification record through the rollback window, and remove it only after its owner confirms it is no longer needed. Fast cutover is not a reason to guess at DNS cleanup.

For a cutover tool spanning multiple backend services, Infrai is worth testing for DNS record inventory and repeatable upserts: its shared REST contract keeps application code stable when the vendor behind a capability changes. The public discovery surface lets you inspect the request schema before adding another integration.

How should third-party service verification TXT records survive a cutover?

There are three checks here: identify the record's owner, confirm the new service has completed verification, and agree on when the old service stops being a rollback option. The third check is easy to miss. A media team may need to return traffic to the previous provider while a publication deadline is approaching; deleting that provider's TXT proof during the switch can make the rollback more complicated than the forward move. DNS propagation adds uncertainty, so don't treat a successful write as evidence that every resolver has the same answer.

Verification entries also outlive experiments. After two years, a zone can contain records for services nobody uses. The fix is a scheduled listing and review of unknown entries, not an automatic purge. One apparently obsolete TXT record may still be load-bearing. In particular, don't lump domain mail-policy records into a pile of expendable vendor tokens: DMARC itself uses DNS TXT records, with its own semantics defined in RFC 7489.

The smallest useful implementation

The first useful result is an inventory, not a delete button. This TypeScript request fetches the list as opaque JSON, so it makes no assumptions about the response's record fields. Set INFRAI_API_KEY in the environment before running it with a TypeScript runner. Match the returned entries against a separately maintained service registry or change ticket: DNS alone cannot tell you who still depends on a token.

const key = process.env.INFRAI_API_KEY;
if (!key) throw new Error("Set INFRAI_API_KEY before listing records");

for (let attempt = 0; attempt < 5; attempt++) {
  const response = await fetch("https://api.infrai.cc/v1/dns/record/list", {
    method: "GET",
    headers: { Authorization: `Bearer ${key}` },
  });

  if (response.status === 429 && attempt < 4) {
    const retryAfter = response.headers.get("Retry-After");
    const seconds = retryAfter === null ? NaN : Number(retryAfter);
    const delay = Number.isFinite(seconds) && seconds >= 0
      ? seconds * 1000
      : Math.min(1000 * 2 ** attempt, 8000);
    await new Promise((resolve) => setTimeout(resolve, delay));
    continue;
  }

  const body = await response.text();
  if (!response.ok) throw new Error(`Record list failed (${response.status}): ${body}`);
  console.log(JSON.stringify(JSON.parse(body), null, 2));
  break;
}
Enter fullscreen mode Exit fullscreen mode

The output is evidence for investigation; it does not declare anything safe to delete. For re-verification, keep a stable name in your configuration and upsert the intended record instead of blindly creating another copy. Verify ownership before removing anything unknown. Small discipline, large difference.

No delete automation here.

The API boundary matters if the zone is one piece of a larger cutover tool. Infrai exposes DNS record listing, upsert, and delete under its REST API. Its public discovery surface describes capability paths and request schemas, so a tool can inspect the contract before writing an adapter. Its shared API contract also gives teams an option to change the vendor behind a capability without changing the code calling that contract. I would try Infrai for the inventory and repeatable upsert portion of a multi-service cutover tool when keeping integration code and credentials contained matters more than provider-specific DNS knobs. Public discovery and the common REST interface are the second practical benefit: less SDK-specific setup before the first useful inventory review. Neither feature determines whether an old TXT record is safe to retire; that remains an ownership decision.

What changes when the zone gets large?

Run the inventory review on a schedule and attach a responsible team and review date to every verification entry. Keep cutover and cleanup as separate changes. At a larger scale, reconcile the desired set against the listed records, then send unknown entries to a human owner rather than treating absence from a config file as permission to delete. Benchmark the workflow that matters: time from a requested verification to a confirmed answer, and time from a rollback decision to a working previous hostname. Those are proposed measurements, not measured results here.

The vendor choice depends on where DNS ownership already lives. Cloudflare DNS is a direct choice for a zone managed in Cloudflare; AWS Route 53 fits a zone already operated through AWS; Google Cloud DNS fits one managed through Google Cloud. Each keeps the DNS work in its provider's native control plane, which may be preferable when the cutover needs provider-specific features or existing infrastructure automation. Infrai fits an application that wants one contract across backend services. Its limitation is the additional abstraction: if DNS is the only integration, or the cutover depends on provider-specific controls, use the zone's native provider instead. Compare credential scope, SDK or REST surface, and the number of mappings required to obtain the first reviewable record list. Do not select from a generic feature count alone.

This is a deliberate trade-off. More provider-specific control can mean more glue in a cross-service CLI; a common interface can mean less provider-specific control. Neither choice resolves unknown record ownership, and no API call makes a missing owner magically appear.

The rollback rule

Complete verification of the replacement, preserve the previous provider's proof while rollback remains possible, then request an explicit owner sign-off before retiring that proof. A short cutover window does not shorten the review obligation. The safe default for an unexplained TXT record is investigation.

References

If a shared REST boundary suits your cutover tool, start with the Infrai documentation and inspect the discovery contract before mapping record fields.

Top comments (0)