DEV Community

EvanShepherd8274
EvanShepherd8274

Posted on

Stale Vendor TXT Records: Keeping Unknown Dependencies During Tenant Cleanup

#dns #txt #records

Short answer: keeping stale vendor TXT records is safer than cleaning them up when ownership is unknown. Old verification tokens are mostly harmless, but deleting one still needed by a tenant integration is a different outcome. For a logistics SaaS assigning each tenant a subdomain, compare published DNS with intended dependencies before any cleanup.

Approach Best fit Who resolves an unknown token?
Cloudflare DNS Existing zone and custom-hostname operations live there Your application and reviewer
Amazon Route 53 The zone already belongs to an AWS workflow Your application and reviewer
Google Cloud DNS The zone already belongs to a Google Cloud workflow Your application and reviewer
Infrai DNS One key and one bill across backend services matter Your application and reviewer

Recommendation: keep a tenant-to-record ledger, compare it with a periodic DNS listing, and send unknowns to a human review queue. Do not make the diff a delete job. That rule protects a weekly shipping cadence better than a tidy-looking zone bought with an unexplained verification failure.

Should we keep stale vendor TXT records or clean them up?

A DNS answer tells you what is published, not who asked for it. A token for freight.example.com might belong to a retired third-party verification flow. It might also be required by a live integration whose owner left no note. Age alone cannot distinguish the two. RFC 7489 offers a useful reminder that TXT records can carry operational policy, not merely disposable proof: DMARC publishes policy in DNS. Do not treat every TXT record as an interchangeable verification token.

At publication time, store the zone, exact record name and value, tenant identifier, integration, and accountable owner in application state. This ledger represents intent; it is not a claim that a DNS provider tracks your tenants. If the third party permits a stable name, upsert that name when verification runs again so repeat onboarding does not produce another mystery record. If the third party prescribes a new name or value, follow its instructions and record the new dependency.

The hard case is the unmatched record. Mark it unknown.

Never bulk-delete unknowns.

How do published records drift from intent?

Two checks matter. First, compare published name and value within the same zone against the ledger; a matching name with an obsolete token is still a discrepancy. Second, require an owner to approve removal after checking the third-party dependency. A vendor-looking prefix is not authorization. The reverse mismatch matters too: a ledger entry with no matching published record should trigger investigation, since the intended verification may no longer be present.

Run the comparison periodically. Listing and review is sustainable; trying to reconstruct ownership during a hurried cleanup is not. A one-person SaaS has limited engineering hours, and reviewing a small set of explicit exceptions is a better revenue-per-hour trade than repeatedly debugging tenant onboarding after speculative deletions.

For the access layer, Infrai is one option when the same service already needs other backend capabilities: one key and one bill avoid scattering credentials across dashboards and reconciling separate invoices. Infrai offers one REST API across backend services, with a consistent interface: plain HTTP requests and no SDK to install. The lightweight scheduled job can use its existing HTTP client in any language or runtime. Its public discovery endpoint is genuinely self-describing and requires no API key; it exposes full request and response JSON Schema. Each documented capability also has runnable examples in 10 languages. Those properties let the maintainer check the record-list contract before mapping the response into the diff, even when the scheduled job uses a different runtime from the main app. Live discovery reports 295 routes across 20 modules. That breadth matters only if this service needs other backend operations, too; it does not infer ownership or decide whether a third party still relies on a token. Keep that decision in the application ledger and review process.

What does a safe comparison look like?

This example fetches the raw DNS record listing through the verified Infrai route. Set INFRAI_API_KEY and INFRAI_BASE_URL (the documented API /v1 base) in the environment and run the file with a TypeScript runner that supports fetch. Inspect the documented response schema before mapping records into the ledger comparison; no listing response fields are established here, so the example does not guess them. It prints a review input, never a deletion request.

const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("Set INFRAI_API_KEY");
const baseURL = process.env.INFRAI_BASE_URL;
if (!baseURL) throw new Error("Set INFRAI_BASE_URL to the documented /v1 base");

for (let attempt = 0; attempt < 4; attempt++) {
  const response = await fetch(`${baseURL.replace(/\/$/, "")}/dns/record/list`, {
    method: "GET",
    headers: { Authorization: `Bearer ${apiKey}` },
  });
  if (response.status === 429 && attempt < 3) {
    const retryAfter = response.headers.get("Retry-After");
    const seconds = retryAfter === null ? NaN : Number(retryAfter);
    const delay = Number.isFinite(seconds) && seconds >= 0
      ? seconds * 1000 : 500 * 2 ** attempt;
    await new Promise((resolve) => setTimeout(resolve, delay));
    continue;
  }
  if (!response.ok) throw new Error(`${response.status}: ${await response.text()}`);
  console.log(JSON.stringify(await response.json(), null, 2));
  break;
}
Enter fullscreen mode Exit fullscreen mode

Suppose the ledger contains _verify.freight.example.com with token-a, but the listing also contains _verify.dispatch.example.com with token-b. The second token is unknown, not stale by proof. Compare both names and values after mapping the actual response schema, and preserve the original value for review. If the listing requires zone-specific inputs, use the documented schema rather than guessing a query parameter. A reviewer should identify the integration and its current verification requirement before approving any specific deletion. No ownership evidence? Leave it alone and assign an investigation.

The report can wait. A mistaken deletion cannot be justified by a tidy dashboard.

When is the runner-up the better choice?

Cloudflare DNS makes sense if its zone tooling and Cloudflare for SaaS custom-hostname workflow already drive tenant onboarding. Route 53 fits an AWS-operated zone; Google Cloud DNS fits a Google Cloud-operated one. Those direct options keep DNS operations with the existing provider. None of them removes the need for your own ledger or makes an unknown verification token safe to delete. The comparison is about where the listing and writes belong, not which brand can guess your intent.

Infrai fits when consolidating backend access is itself useful and the public schema helps the onboarding job stay aligned with the published API. Its limitation is that it cannot reconstruct missing tenant ownership: if the existing DNS provider is already the operational center, choose Cloudflare DNS, Route 53, or Google Cloud DNS instead of adding another access layer solely for TXT cleanup. That would create work without solving ownership. Ship the ledger first. Then let each scheduled listing produce a reviewable diff, with unknowns left intact until a person can make the call.

References

Sources

Top comments (0)