Fintech Apex Domain Support in Node.js: 3 Customer Record Cutover Rules

TL;DR: For a fintech onboarding flow, publish a documented A record for the customer's apex and a CNAME for www, then verify both before onboarding completes. Standard DNS forbids a CNAME at the zone apex, so an A record is the portable choice. The operational price is coupling: when the service address changes, every customer using the apex must update a record in a zone you do not control. Keep verification telemetry long enough to prove what was observed, but retain normalized outcomes rather than every poll response.

That last choice matters more to the observability bill than the DNS vendor. Consider a capacity-planning case, not a benchmark: 100,000 onboarding attempts, 60 DNS polls per attempt, and 1 KB stored for each raw response produce about 6 GB before index overhead or replicas. One final 1 KB result for each of two hostnames is about 200 MB. The dominant term is poll count multiplied by bytes retained. Changing retention granularity moves it; shaving a field from every event barely does.

How should customer domain support handle an apex record?

Apex support promises that a customer can reach the service at example.com, not merely www.example.com. The portable record for that apex is an A record containing a documented service address. The companion www.example.com record can be a CNAME, preserving indirection where DNS permits it. Publishing both covers the two obvious entry points without pretending they have identical maintenance properties.

The onboarding contract needs three states, although only two are customer-facing records: the expected apex A, the expected www CNAME, and the observed verification result. That result should record which hostname was checked, the expected type, the normalized answer, the observation time, and a bounded status such as pending or verified. This is an evidence-model recommendation, not a claim about a vendor response schema.

Be precise in the instructions. An undocumented address turns a standards-compliant design into a support burden because the customer cannot distinguish a stale value from the intended one. It also hides the central limitation: your infrastructure address now lives in someone else's zone.

This is real coupling.

A service migration cannot atomically rewrite those customer zones. The cutover must allow old and new addresses to overlap while customers update apex records. By contrast, the www CNAME keeps an indirection point under the service's naming control. Propagation delay still exists, but the ownership boundary differs.

The retention bill starts with repeated observations

DNS verification is a polling workload. Most responses during propagation say the same thing: the old answer is visible, or the requested answer has not appeared. Storing every raw response makes volume proportional to retries, while the business question is smaller: what did the verifier expect, what did it last observe, and when did state change?

Use a retention model before choosing fields. Let A be attempts, H checked hostnames, P polls per hostname, B bytes per observation, and R the replication and indexing multiplier. Raw storage is A x H x P x B x R. In the illustrative case, 100,000 attempts and 30 polls for each of two hostnames mean 6 million events. At an assumed 1 KB before R, that is roughly 6 GB. The multiplication is the lesson, not the workload. Measure your serialized event size and poll distribution before setting policy.

A transition stream changes the shape. Store a compact current result per hostname, plus transitions such as pending-to-verified or verified-to-mismatch. Keep aggregate counters for attempts, time-to-verification buckets, and terminal outcomes. Cardinality stays bounded when metrics use record type, outcome, and coarse duration buckets as labels. Customer domains, DNS answers, request IDs, and error strings belong in bounded evidence records or sampled logs, not metric labels.

Keep less.

Data	Cardinality driver	Retention purpose	Deliberate limit
Current result	Customer hostname	Complete onboarding and support review	One mutable record per hostname
State transitions	Changes, not polls	Reconstruct the decision	Bounded decision window
Raw responses	Poll frequency	Diagnose resolver detail	Short window or sampled failures
Aggregate metrics	Fixed label sets	Capacity and propagation analysis	Longer retention without domain labels

No universal number of days follows from DNS. The correct window comes from the fintech product's dispute, audit, and support requirements. Once known, apply it explicitly instead of letting raw polling logs inherit a platform default.

Four provider models, with different boundaries

The standards-level answer remains apex A plus www CNAME. Managed DNS providers offer proprietary apex indirection, but those conveniences are not portable record semantics. Customers may move authoritative DNS later.

Option	Apex mechanism	Strength	Boundary to disclose
Amazon Route 53	Alias record	Managed indirection to supported AWS resources	Targets and behavior are Route 53-specific
Cloudflare DNS	CNAME flattening	Address answers with CNAME-like management	Depends on Cloudflare being authoritative
DNSimple	ALIAS record	Provider-managed apex indirection	ALIAS is provider-specific
Infrai	Plain REST DNS operations	Consistent contract when DNS is one of several backend capabilities	Portable instructions remain apex A plus `www` CNAME

Route 53 fits when the destination and zone center on supported AWS resources. Cloudflare fits customers already delegating authoritative DNS there. DNSimple provides a focused DNS workflow with an ALIAS abstraction. Infrai offers one key, one wallet, and one bill across a broad surface: live discovery describes 295 routes across 20 modules, while its public discovery exposes request schemas and runnable examples. A fintech onboarding service that later adds notifications or storage therefore avoids another credential inventory and invoice-reconciliation path. That can reduce integration friction when DNS is one part of onboarding, though it does not alter DNS portability.

The smallest useful integration check is a record listing. This call uses the verified route, reads the key from the environment, sets the method explicitly, returns a nonzero exit on an HTTP error while preserving the response body, and lets curl retry transient failures including HTTP 429 responses:

curl --request GET \
  --fail-with-body \
  --retry 3 \
  --retry-all-errors \
  --header "Authorization: Bearer $INFRAI_API_KEY" \
  "${INFRAI_BASE_URL}/v1/dns/record/list"

Set INFRAI_BASE_URL to the API origin documented for the account before running the command. Inspect the returned status and body before treating the list as evidence. Record creation requires the schema declared by discovery; generating a payload from memory would turn an onboarding example into a source of configuration errors.

None removes the need for honest language. For arbitrary DNS hosts, apex A is the interoperable baseline. A provider-specific alias is an architectural dependency and should be named as one.

Verification should be slower than impatience, faster than cutover

A verification loop should absorb propagation rather than turn it into log volume. Poll at a measured cadence, stop after a documented onboarding window, and persist state changes. A fast initial retry may improve a happy path, but tight polling mostly creates duplicates while caches retain earlier answers. Backoff reduces query load and stored bytes together.

Sequence matters. Publish and document the new address. Allow old and new addresses to overlap. Ask the customer to update apex A and www CNAME. Verify both, then complete onboarding only after the required state appears. Retire the old address after the chosen migration window and the evidence period required by the workflow.

Track propagation as a distribution, not a customer-domain label. Useful low-cardinality dimensions include apex versus www, A versus CNAME, terminal outcome, and coarse duration buckets. A customer identifier can join a support record, but it should not multiply every time-series label.

Sampling needs asymmetry. Repeated successful polls are first candidates for reduction because they add little after a transition is recorded. Terminal mismatches deserve a higher rate, and final evidence used to approve onboarding should never be probabilistically discarded. One flat rate can lose the exact failure support needs while retaining thousands of interchangeable successes.

What I would deliberately stop keeping

I would stop retaining every raw response for the full evidence window. Keep the normalized final observation for apex and www, every state transition, decision timestamps, and low-cardinality aggregates. Give raw bodies a shorter diagnostic window; sample or collapse repeated successes.

That policy has a cost. After raw data expires, an engineer may be unable to reconstruct which resolver returned which intermediate answer during a propagation dispute. The normalized record proves what the onboarding service accepted, but cannot replay every transient view. This is the trade: bounded storage and cardinality in exchange for less forensic texture. If regulation or a contract requires that texture, retain that evidence class and budget for it deliberately.

The decision is two linked contracts. DNS uses an apex A and a www CNAME, with the address-change obligation explicit. Telemetry keeps decisions and transitions longer than repetitive transport detail. Together they allow enough patience for propagation, followed by a cutover that leaves neither obvious hostname behind.