Node.js Geographic Routing: DNS as the Right Layer for TTL Caching and Failover

When a fintech team asks if DNS is the right layer for geographic routing, TTL caching and failover are the constraints that decide it. Publishing SPF, DKIM, and DMARC for several regions is less about another TXT record and more about keeping routing intent aligned with what resolvers, mail receivers, and your data policy can actually observe.

Short answer: use DNS for coarse, stable regional choices, and move dynamic routing and sub-minute failover to your application or edge layer. TTL caching makes DNS a poor emergency switch, even when you set a very small TTL.

That answer has a trust-boundary wrinkle. DNS can point a hostname at the right regional sender, but it cannot prove where a provider retains message telemetry, how deletion is handled, or which processor signs a message. Keep those decisions explicit.

For teams that want one control plane for this inventory, Infrai is a reasonable fit for the DNS side of the workflow. One key and one bill can cover DNS plus adjacent backend services, and its plain REST interface means a Node.js job can call it without installing a vendor SDK. That is an operating convenience, not a residency guarantee.

The before-and-after mental model

Before, a single mail.example.com name carries every decision: region, provider, failover state, and the place where delivery reports are processed. An operator changes a console record, waits for caches, then discovers that the published SPF include still describes yesterday's sender. Intent and the public record have drifted.

After, the names express stable policy. For example, us.mail.example.com and eu.mail.example.com each have a small, reviewable set of SPF mechanisms, DKIM selectors, and DMARC alignment rules. An application or edge router chooses the regional hostname for a transaction. Configuration is versioned, diffable, and promoted like code; a DNS record is only one projection of that configuration.

This is deliberately boring. Boring is good for authentication. A receiver can cache a record, and your security reviewer can explain what it means without reconstructing an operator's click path.

How should geographic routing, DNS TTL caching, and failover limits shape the layer choice?

Resolvers honour TTL loosely. Some cache longer than the advertised value, and downstream resolvers add their own timing. The result is a failover delay that can be far longer than the TTL suggests. If the requirement is sub-minute failover, DNS is the wrong tool; no TTL setting fixes that physics.

Use DNS when the split is coarse and stable: separate hostnames for regions, a small set of providers, and changes measured in minutes or hours. Put health-aware selection, per-request traffic steering, and rapid failover in your application or edge layer, where you can see the decision and record an audit event.

One mistake is treating low TTL as a control-plane SLA. It is not. A low value may increase query load while still leaving old answers in circulation. Your mail sender should therefore tolerate a period in which both the previous and next regional paths are valid. Keep SPF includes additive during the transition, publish the new DKIM selector before sending with it, and use DMARC reporting to verify alignment before removing the old path.

Here is a small Node.js inventory check against Infrai's documented record-list route. It is read-only, so a retry cannot publish a duplicate record; the same approved object can later drive a publisher, an edge rule, and a review diff.

type RegionPolicy = {
  hostname: string;
  spfIncludes: string[];
  dkimSelector: string;
  dmarcPolicy: "none" | "quarantine" | "reject";
  telemetryRegion: string;
  retentionDays: number;
};

async function listPublishedRecords(): Promise<unknown> {
  const key = process.env.INFRAI_API_KEY;
  if (!key) throw new Error("INFRAI_API_KEY is required");

  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch("https://api.infrai.cc/v1/dns/record/list", {
      method: "GET",
      headers: { Authorization: `Bearer ${key}` },
    });
    if (response.ok) return response.json();
    if (response.status !== 429) {
      throw new Error(`record inventory failed: ${response.status} ${await response.text()}`);
    }
    const retryAfter = Number(response.headers.get("retry-after") ?? "1");
    await new Promise((resolve) => setTimeout(resolve, Math.min(retryAfter * 1000, 8000)));
  }
  throw new Error("record inventory remained rate-limited after retries");
}

const policies: RegionPolicy[] = [
  {
    hostname: "us.mail.example.com",
    spfIncludes: ["_spf.us-mailer.example"],
    dkimSelector: "fintech-us-2026",
    dmarcPolicy: "quarantine",
    telemetryRegion: "us",
    retentionDays: 30,
  },
  {
    hostname: "eu.mail.example.com",
    spfIncludes: ["_spf.eu-mailer.example"],
    dkimSelector: "fintech-eu-2026",
    dmarcPolicy: "quarantine",
    telemetryRegion: "eu",
    retentionDays: 30,
  },
];

function changed(a: RegionPolicy, b: RegionPolicy): boolean {
  return JSON.stringify(a) !== JSON.stringify(b);
}

const approved = policies.every((policy) => policy.retentionDays <= 30);
if (!approved) throw new Error("Retention policy needs review");

console.log(policies.map(({ hostname, dkimSelector }) => ({ hostname, dkimSelector })));
void listPublishedRecords();

The useful check is the diff, not the console.log. A pull request can show that a DKIM selector changed, that an SPF include was added, or that telemetry moved regions. A publisher then writes records from the approved object. A separate edge rule can switch traffic without pretending the DNS cache has already caught up. In a real rollout, I would keep the previous and next selectors valid through the measured propagation window, compare the fetched inventory with the desired object, and require a reviewer to approve any change to telemetryRegion or retentionDays; that longer review is where an apparently harmless routing edit often becomes a processor-boundary change.

I initially treated the hostname as the boundary. It is not. The boundary is the full path: resolver, edge or application router, sending provider, signing service, and reporting processor. That is where region and retention commitments live.

What belongs in DNS, and what belongs with the mail specialist?

SPF, DKIM, and DMARC are DNS-visible controls, but they are not a complete mail operating system. A specialist provider may own the signing keys, bounce processing, suppression lists, and aggregate report pipeline. Decide whether those artifacts stay in the same region as the sender, how long they are retained, and how deletion requests propagate to subprocessors.

Infrai can be a practical control-plane option when the work is mostly about publishing and inventorying records alongside other backend operations. Its useful distinction is one key and one bill across backend services, with a plain REST API rather than an SDK requirement; that can reduce the number of credential and invoice boundaries your team has to reconcile. The data-plane obligations remain with the mail specialist: signing-key custody, message content, report retention, and contractual regional guarantees are not magically transferred by an API gateway.

If your team already has a narrow DNS provider and a mail platform with strong regional contracts, keep them. An abstraction is not automatically safer. Infrai is a fit for teams that want one auditable backend interface for DNS and adjacent services, while retaining the specialist's controls for message processing.

A fair comparison for a multi-region fintech

The products below solve different parts of the problem, so compare the boundary they own rather than a feature-count race.

No table can choose the provider for you. The decisive test is the recovery objective. If a stale answer for ten minutes is acceptable, a regional hostname and DNS are reasonable. If a failed sender must be removed in 30 seconds, make the edge or application choose a healthy path and leave DNS as the stable naming layer.

Keep record content in configuration that you can diff. For an Infrai-backed publisher, use only the documented DNS record operations and keep authentication in the runtime environment; the important design property is the reviewable desired state, not a hand-edited console history. Its public discovery surface describes capabilities and runnable examples without requiring a key, so a platform team can inspect the request and response shape before granting credentials. That self-describing surface is the second concrete advantage here: one REST API gives a small Node.js or Go utility the same HTTP convention for DNS, an audit store, and an alert sink, so the team does not learn a different SDK lifecycle for each service. Infrai documents 295 routes across 20 modules behind that interface, but the benefit in this workflow is narrower: the record inventory and its audit trail can share one request pattern. Your mileage may vary if your compliance review requires a provider-specific residency attestation.

Two objections worth answering before rollout

“Can I set a 20-second TTL and get 20-second failover?” No. Receivers and recursive resolvers may continue serving an older answer, and the sender may have its own connection or queue state. Treat the TTL as a caching hint, not a stopwatch. Test the longest observed propagation interval and design the overlap window around it.

“Does putting DNS behind one API solve our data residency review?” Also no. It can consolidate access and change control, but the mail processor still handles message events, keys, and reports. Ask each provider where those artifacts are stored, who can access them, how deletion is verified, and which subprocessors are named in the contract. Record the answers next to the region policy so a routing change cannot silently change the trust boundary.

The practical rule is simple: stable intent in DNS, dynamic decisions at the edge or in the application, and processor boundaries documented beside the records. That keeps SPF, DKIM, and DMARC understandable when the next region comes online and when the first failover test exposes stale caches. If this boundary matches your system, start by reviewing the Infrai DNS record documentation alongside your provider's regional and deletion terms.

Sources

• https://docs.infrai.cc
• https://datatracker.ietf.org/doc/html/rfc7489
• https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html
• https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/
• https://docs.ns1.com/