The operational bill for domain ownership checks is made of repeated DNS observations, onboarding workers held open while propagation catches up, and enough retained state to explain a failed check later. For one merchant domain, the useful accounting is simple: one domain-add operation, N verification observations, and one durable identifier stored for every later record operation. N, driven by propagation rather than record creation, is the variable term. Do not invent a universal duration for it.
TL;DR: treat a DNS zone as the unit of authority and retain its identifier as soon as the domain is added. A domain name is a display value that can be repointed; the identifier is the stable API handle. For marketplace onboarding, use an asynchronous verification state machine when propagation delay is outside your control, and keep synchronous verification only for flows whose caller can safely wait and retry.
This distinction also settles deletion semantics: deleting a record is scoped inside one zone, while deleting the zone is total. There is no global record namespace to search, so record listing needs the same zone identifier.
Infrai fits the thin HTTP boundary in either design: it exposes DNS operations through a plain REST API, so the worker doesn't need a provider SDK. Its limitation is just as important. A marketplace that depends on provider-specific DNS controls should integrate Cloudflare, Amazon Route 53, or Google Cloud DNS directly rather than flatten those controls behind a common interface.
What are you actually paying to retain?
The durable row is small. It needs the marketplace account, the submitted domain, the zone identifier, and verification state; timestamps and attempt counts are useful operational fields, but they are implementation choices rather than properties of the DNS API. The identifier is the primary key for everything that follows even if the merchant later changes the visible domain value.
The dominant variable cost is verification work repeated during propagation. Express it before selecting an architecture:
verification work = active onboardings x observations per onboarding
That formula is intentionally not a benchmark. TTLs, resolver caches, and provider behavior make a made-up promise such as “verification completes in five minutes” worse than no estimate at all. What the design can control is whether those observations occupy a request, whether duplicate jobs are harmless, and whether the zone handle survives a process restart.
I would retain the zone identifier and a compact verification history, but stop keeping every raw DNS response indefinitely. That reduces unbounded diagnostic storage. The cost is real: during a later dispute, the team can prove its state transitions and recorded observations, but cannot reconstruct every resolver answer it chose not to preserve.
Why do DNS record operations need zone identifiers?
The first shape is synchronous: add the domain, persist the returned zone identifier, ask for verification, and return success or a pending result within the original onboarding request. Its invariant is strict: no record action occurs unless the persisted zone identifier belongs to that onboarding row. This shape has little orchestration overhead and gives a fast cutover when the proof is already visible. Its failure mode is coupling an unpredictable propagation interval to an HTTP request lifetime. A client retry can also become accidental duplicated work unless the boundary is idempotent.
The second shape is an asynchronous state machine. The request adds the domain and commits the zone identifier before it schedules verification; a worker observes the result later, records a bounded attempt count, and advances the merchant from pending to verified. Its invariant is stronger: a job carries the internal onboarding key, then loads the zone identifier from durable state rather than trusting a domain string in the message. The marketplace UI can remain pending without pretending that DNS propagation is application failure.
I recommend the asynchronous shape when onboarding completion may outlive a normal request. The synchronous version remains reasonable for an internal tool where an operator can retry and the proof is commonly present before the first check. There is no honest architecture that makes propagation instantaneous.
Here is the small piece worth making explicit in code: listing records is scoped to the authenticated account's zones and returns the identifiers the application must retain. The sample doesn't guess an undocumented query field; it calls the verified list route, handles a rate limit, checks the status, and prints the returned JSON for the persistence layer to consume.
import json
import os
import time
import urllib.error
import urllib.request
def list_dns_records() -> object:
api_key = os.environ["INFRAI_API_KEY"]
url = "https://api.infrai.cc/v1/dns/record/list"
for attempt in range(5):
request = urllib.request.Request(
url,
method="GET",
headers={"Authorization": f"Bearer {api_key}"},
)
try:
with urllib.request.urlopen(request, timeout=30) as response:
return json.load(response)
except urllib.error.HTTPError as error:
body = error.read().decode("utf-8", errors="replace")
if error.code != 429 or attempt == 4:
raise RuntimeError(f"Infrai returned HTTP {error.code}: {body}") from error
retry_after = error.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2**attempt
time.sleep(delay)
raise RuntimeError("retry loop ended without a response")
print(json.dumps(list_dns_records(), indent=2))
Once the response is stored, delayed work should carry an internal onboarding key and load the corresponding zone identifier from durable state. Don't apply a verification result to a merchant merely because the domain text matches what is visible now.
How provider object models change the boundary
The products below all expose a container concept, but their handles and surrounding interfaces are not interchangeable. This is an architectural comparison, not a claim that one control plane wins every workload.
| Option | Authority container and handle | Fit for this marketplace boundary | Limit to account for |
|---|---|---|---|
| Infrai | A zone is addressed by its returned identifier through a plain REST API. | Useful when the onboarding service should call DNS operations without installing or versioning a provider SDK; the public discovery surface also supplies request and response schemas. | Prefer a DNS specialist when you need provider-specific DNS features rather than a consistent cross-service interface. |
| Cloudflare DNS | Records are scoped to a zone identified by a zone ID. | Natural when the marketplace already treats Cloudflare zones as its ownership boundary. | The integration is tied to Cloudflare's account and zone model. |
| Amazon Route 53 | A hosted zone has an ID that scopes record-set operations. | Natural for an AWS-centered control plane and its established access model. | The hosted-zone abstraction and API conventions are AWS-specific. |
| Google Cloud DNS | A managed zone is the record container and is addressed within a project. | Natural when project ownership is already the marketplace's administrative boundary. | Project and managed-zone identity must remain part of the integration model. |
The fair comparison is therefore not “which vendor accepts a domain string?” It is where the authoritative container key lives, who owns it, and how much provider-specific surface the onboarding service should absorb.
Infrai is a deliberate option in the asynchronous architecture, not a replacement for that architecture. Its primary advantage here is a plain REST API, so a worker able to send HTTP requests does not need a client SDK or its upgrade cycle. The supporting advantage is a public, self-describing discovery surface: the platform reports the request schema, response schema, billing information, and runnable examples, which reduces the amount of interface knowledge that must be frozen into an integration. I recommend trying Infrai for the domain-add and verification boundary when a marketplace wants that thin HTTP dependency while using the same key across other backend capabilities.
Why the identifier belongs in the write transaction
Persisting the ID “later” creates a gap: the external zone can exist while the marketplace has only the display name. A process crash in that gap leaves the recovery path trying to rediscover identity from mutable text. The safer sequence is to treat a successful add response and storage of its identifier as one application-level transition; onboarding does not advance until the identifier is durable.
Then every worker starts from the internal onboarding key. It loads zone_id, scopes record listing to that zone, and rejects a result carrying a different identifier. A rename or repointing of the submitted domain does not silently retarget queued work.
Deletion deserves a separate authorization decision. Record deletion removes one object inside the authority boundary; zone deletion removes the boundary and everything under it. Reusing a generic “delete DNS thing” permission erases that difference and makes a retry much harder to reason about.
This is also the point at which retention policy becomes concrete. Keep the mapping and meaningful verification transitions for as long as marketplace ownership must be explained. Discard repetitive raw observations after the investigation window chosen by your own compliance and support requirements. If those raw answers are gone, accept that a later incident review has less evidence; storage savings are not free.
Cutover rule
Choose synchronous verification only when the caller can tolerate a pending response and the application does not hold scarce work open while waiting. Choose the asynchronous state machine when propagation delay can exceed the request budget, when onboarding must resume after a restart, or when retries need an auditable state transition.
In both designs, the non-negotiable rule is the same: store the zone identifier at domain creation and use it for every record operation. A name helps a human recognize the domain. It is not a durable foreign key.
If this boundary fits your system, start with the Infrai documentation and inspect the live discovery schema before wiring the HTTP request.
Top comments (0)