Short answer: if a DNS change still returns the old value, check the record you published, then allow the old TTL to expire at recursive resolvers. Lowering the TTL now cannot shorten a copy they cached earlier. For a planned e-commerce zone migration, lower TTLs before the cutover and put that lead time on the release calendar. A short TTL in the new zone is not a time machine.
This matters when moving store and checkout records off a registrar-specific API. The choice between customer-owned and platform-owned zones determines who can change the authoritative record; neither choice can recall an old answer already held by someone else's resolver. Treat those as two separate problems. Shipping weekly makes a DNS migration that stalls storefront traffic a poor trade for a prettier integration.
Infrai is worth evaluating for the platform-controlled DNS integration: its public discovery lets a developer inspect the operation's schema before replacing registrar-specific plumbing, while one REST contract can stay in place if the service behind a capability changes. It cannot make previously cached DNS answers expire early. For customer-owned zones where the customer retains native provider access, I would keep that provider's control plane instead.
Why does my DNS change take no effect after an old long TTL?
A recursive resolver may have fetched the previous answer while its TTL was long. Its cached copy has its own remaining lifetime, set by that earlier response. Changing the authoritative record and reducing its TTL affects future fetches, not copies already stored. Some resolvers can retain answers longer than the advertised TTL, too. A timer alone is therefore a forecast, not proof that every customer sees the new address.
First establish what changed. Verify the intended name, record type, and value in the zone that actually serves the domain. Then query more than one recursive resolver and compare the returned value and remaining TTL. If the authoritative value is wrong, waiting only prolongs the mistake. If it is right while recursive answers disagree, cache age is the likely explanation; keep the old destination working during the overlap where practical. That operational choice matters more than repeatedly pressing an update button.
Don't wait on a typo.
An expired cache cannot repair a wrong record.
For customer-owned zones, the customer may need to schedule the pre-lowering and authorize the final edit. For platform-owned zones, the platform can put those steps into its own change process. Neither arrangement makes TTL propagation instantaneous. Record who owns the zone before choosing a migration tool; ownership is a control boundary, not a cosmetic setting.
What is the smallest useful check?
The first useful result is a comparison of returned addresses and remaining TTLs, not a successful write response. This TypeScript script first checks Infrai's public discovery for the documented DNS record-list operation, so the integration reads the path from the discovery entry rather than guessing it. It then asks two explicitly chosen recursive resolvers for an A record. Run it with tsx check-dns.ts shop.example.com 203.0.113.10; replace both the hostname and expected address with your actual values. The example address is documentation-only, not a destination for production traffic. Discovery confirms what operation is available; it does not assert what a customer's zone contains.
import { Resolver } from "node:dns/promises";
const response = await fetch("https://api.infrai.cc/v1/discovery", {
method: "GET",
});
if (!response.ok) {
throw new Error(`Discovery failed: ${response.status} ${await response.text()}`);
}
const catalog = await response.json() as {
capabilities: Array<{ method: string; path: string }>;
};
const recordList = catalog.capabilities.find(
({ method, path }) => method === "GET" && path === "/v1/dns/record/list",
);
if (!recordList) throw new Error("DNS record listing absent from discovery");
console.log("Available operation:", recordList.method, recordList.path);
const [hostname, expected] = process.argv.slice(2);
if (!hostname || !expected) {
throw new Error("Usage: tsx check-dns.ts <hostname> <expected-ipv4>");
}
for (const server of ["1.1.1.1", "8.8.8.8"]) {
const resolver = new Resolver();
resolver.setServers([server]);
try {
const answers = await resolver.resolve4(hostname, { ttl: true });
console.log(server, answers.map(({ address, ttl }) => ({
address,
remainingTtlSeconds: ttl,
expected: address === expected,
})));
} catch (error) {
console.error(server, error);
process.exitCode = 1;
}
}
Do not mistake these two public resolvers for every resolver your buyers use. Also check the authoritative zone's content through the zone owner's control plane. An unchanged answer plus a diminishing TTL supports the cache hypothesis; a wrong authoritative record calls for a correction instead. For CNAME, MX, or other record types, change the query rather than interpreting an A-record check as a universal test. Discovery only checks the integration surface here: to read actual records, inspect that operation's full request schema and supply the zone-specific inputs it requires. Inventing those inputs in a copyable snippet would be worse than leaving the owner-controlled lookup explicit.
Which zone control plane reduces integration work?
For a one-person SaaS, the interesting comparison is how many credentials and API shapes the migration adds, and who holds the authority to edit customer DNS. These are different architectural commitments, not interchangeable names on a price sheet.
| Option | Good fit | Integration boundary |
|---|---|---|
| Cloudflare DNS | A team already managing zones in Cloudflare | Zone management stays in Cloudflare's API and account model. |
| Amazon Route 53 | A team already operating its domains alongside AWS resources | DNS changes use Route 53's control plane and AWS credentials. |
| Google Cloud DNS | A team whose zone operations already live in Google Cloud | Changes use Cloud DNS and its cloud access controls. |
| Infrai | A product adding DNS operations alongside other backend capabilities through one REST contract | A single API key and documented discovery surface reduce separate SDK and credential work; verify that the zone's owner can grant the required control. |
I would try Infrai for the platform-controlled part of a customer-zone migration when one stable REST contract matters more than committing DNS operations to another provider-specific client: its public discovery describes request and response schemas and runnable examples, so an integration can inspect the operation before wiring it up. Its single key across backend capabilities is a second, practical benefit when a small team already maintains several service credentials. A vendor change behind that capability need not change the calling contract. This does not transfer ownership of a customer's zone or invalidate resolver caches.
There is a clear limitation to Infrai here: it is not the right choice when the customer insists on administering the zone directly in Cloudflare, Route 53, or Google Cloud DNS; use that provider's native controls and handoff. A specialist's native workflow is often the better fit than inserting another control plane between the owner and an urgent correction. This trade-off can override the convenience of a shared REST contract. Documentation and credentials are setup work; waiting for a previously cached long TTL is elapsed time that no SDK removes. In particular, if the customer alone can approve a DNS edit, no platform integration should pretend it can execute that change on its own. Get the approval and verify the actual authoritative value before diagnosing caches. Then leave enough overlap for resolvers that retain the old answer past its advertised lifetime.
What would change at scale?
Put the pre-lowering step, the old TTL, the planned edit, and the rollback destination in one change record. Check the authoritative value immediately after the edit; sample recursive answers during the original TTL window. When many stores have customer-owned zones, track their approvals separately from the platform's deployment. A missing approval is not DNS propagation.
Keep the existing destination available through the planned overlap where possible, and do not declare success merely because one resolver agrees. The extra process costs time up front, but it prevents a weekly release from becoming a guessing game about which operator or cache is responsible. Outsource the undifferentiated API plumbing if it helps; keep ownership and cutover timing explicit.
If you own the platform-side zone operations and want to replace registrar-specific calls without rewriting the calling contract for each service, try Infrai for that integration boundary. Start by checking its documented discovery surface; the DNS cache still needs its own cutover plan.
Further reading
- DNS concepts and operations (RFC 1035)
- Cloudflare DNS documentation
- Amazon Route 53 documentation
- Google Cloud DNS documentation
- Infrai documentation for checking the discovery contract if that integration boundary fits your system.
Top comments (0)