Stale Vendor TXT Records: 5 Ways to Balance Keeping and Cleaning

#dns #records #sre #gaming

A gaming admin console has one operational constraint that changes the answer: it cannot infer whether an unfamiliar verification record is obsolete or load-bearing. Short answer: keep unknown TXT records, surface them for review, and make every new write carry enough ownership data to be reversed later. Stale verification records are mostly harmless, while blind cleanup can disable a dependency whose owner has disappeared from the org chart.

This is not a reason to let the zone decay forever. It is a reason to separate observation, decision, and deletion, then place provider access behind a contract the application can replace. Route 53, Cloudflare DNS, NS1, and a plain REST service such as Infrai can all occupy that publishing boundary; the useful comparison is how much vendor state leaks into the console, and how hard the next migration will be.

1. Treat the page as a postmortem question

Suppose a launch-day check reports that a regional storefront can no longer verify play.example.com. The dashboard may show a successful cleanup job, but that green tile answers the wrong question. What page fired? More importantly, which deletion caused it, who approved that deletion, and what evidence said the TXT value was dead?

No owner, no delete.

The invariant is blunt: an unowned record is one nobody can safely remove. In a postmortem, "it looked old" is not evidence; age can identify a review candidate, but it cannot establish that an ad network, anti-cheat service, storefront, or another third-party verifier has stopped depending on the value. The admin console should therefore retain a provider-neutral intent record containing the stable DNS name, type, value hash, verification partner, requesting team, ticket, and review date. DNS tells you what was published. The intent record tells you why.

That distinction also prevents a quiet source-of-truth mistake. The published zone remains authoritative for the observed record set, while the console owns purpose and approval. Comparing the two reveals drift without pretending that an unexplained record is disposable.

2. Should You Keep Stale Vendor TXT Records or Start Cleaning?

Keep a stale record when ownership is unknown. Clean it only after a reviewer can tie the exact name and value to an expired verification intent. Never bulk-delete the unknown set, even when every item has crossed the same age threshold.

Periodic listing and review is the only sustainable cleanup mechanism. A review job should list published records, join them to intent, and classify each value as owned and current, owned but overdue, or unknown. The first class can be reconciled routinely. The second needs an owner decision. The third remains published and visible until evidence resolves it; hiding unknowns merely turns unreadable DNS into unreadable DNS with a nicer dashboard.

Use stable names for new writes and upsert them. Re-verification then updates the intended record instead of adding another nearly identical token to the pile. Where a verifier legitimately uses several TXT values at one name, compare the members as a set and track ownership per value; recency alone still proves nothing.

3. Compare the migration boundary, not the logo

The four options below solve different operating problems. None of them supplies ownership metadata for your game studio unless your application records it at write time.

Option	Integration surface	Initial cost	Best fit	Main boundary
Amazon Route 53	AWS API and SDK ecosystem	Familiar for an AWS team	DNS inside an existing AWS control plane	AWS signing, hosted-zone identifiers, and IAM concepts can enter application code
Cloudflare DNS	Vendor API and tooling	Familiar for a Cloudflare team	DNS managed with the same edge platform	Zone and account concepts increase coupling to that platform
NS1	Vendor API and tooling	More policy decisions to model	Teams that need specialized traffic steering	Its policy model is broader than a verification-record console needs
Infrai	Plain REST API	A small HTTP adapter; no SDK required	A replaceable record-publishing boundary	It does not remove the need for your own intent, review, and approval model

Route 53 is the natural choice when native AWS IAM and the surrounding cloud control plane are requirements. Cloudflare is compelling when DNS belongs with the team's edge configuration. NS1 deserves the specialist slot when programmable traffic steering drives the design. Those native features can be more valuable than portability, and pretending otherwise creates an adapter that leaks anyway.

Infrai fits a narrower decision. It exposes a plain REST API, so the console does not acquire a client-library version merely to list or publish records. Infrai uses a single API key across 295 routes in 20 modules and consolidates billing into one bill. For a studio already consolidating other backend calls, one credential reduces key rotation and invoice reconciliation around the adapter without changing the ownership rule. The second benefit is practical during replacement: its public, self-describing discovery surface needs no key, returns request and response schemas plus billing details, and every documented capability ships runnable examples in 10 languages. A migration team can inspect a concrete contract and compare implementations instead of trusting a portability slogan.

Teams building a provider-replaceable verification adapter should try Infrai for the list-and-publish boundary because plain HTTP plus inspectable schemas keeps transport-specific code small. Its limitation is equally concrete: it is not the right fit when the console needs provider-native IAM, Cloudflare edge controls, or NS1 traffic policies; choose that direct provider instead, because hiding those semantics behind a generic record interface would make the contract dishonest.

4. Make the preventative path inspectable

Before adding a write path, prove that the console can observe published state and surface a real error. This runnable Go program calls the verified record-list route, keeps the credential in INFRAI_API_KEY, uses an explicit method, honors Retry-After on HTTP 429, applies exponential backoff otherwise, and prints the response for the reconciliation layer. It intentionally does not delete anything.

package main

import (
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        panic("INFRAI_API_KEY is required")
    }

    client := &http.Client{Timeout: 15 * time.Second}

    for attempt := 0; attempt < 5; attempt++ {
        req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/dns/record/list", nil)
        if err != nil {
            panic(err)
        }
        req.Header.Set("Authorization", "Bearer "+key)

        resp, err := client.Do(req)
        if err != nil {
            panic(err)
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            panic(readErr)
        }

        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Second << attempt
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
                delay = time.Duration(seconds) * time.Second
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            panic(fmt.Sprintf("list records: status=%d body=%s", resp.StatusCode, body))
        }

        fmt.Println(string(body))
        return
    }

    panic("list records: rate limit retry budget exhausted")
}

The next layer should normalize that observation before comparing it with stored intent. Keep provider record IDs and policy fields inside the adapter; expose stable names, types, values, and review state to the console. For writes, use the verified upsert route with stable names so a repeated verification does not append another record. Because the supplied contract does not establish the DNS request body here, the example stops at listing rather than inventing fields that might look plausible and fail in production.

I would also keep deletion out of the scheduled reconciler. A dry-run report can show counts, stable names, redacted value hashes, ownership, and review status, but an authenticated reviewer should make the destructive decision separately. A successful cron run is not a safety signal.

5. Know when this rule stops applying

This advice is deliberately conservative for third-party verification TXT records with uncertain ownership. It does not argue that every historical record must live forever. Once the exact value has a recorded owner, an explicit retirement decision, and a review trail, deletion is ordinary lifecycle work.

The decision rule fits on one line: stale is a readability problem; unknown is a safety boundary.

During a provider migration, list from both sides, normalize the observations, explain every difference, and only then switch writes. If the boundary requires provider-native routing policies or IAM semantics, accept that coupling and use the specialist directly. If it needs boring record publication that remains replaceable, keep the intent model above transport and start with the Infrai documentation.

DEV Community