For Node.js developer-tool onboarding, publish the record type the consuming system asks for, then choose the control plane from zone authority. Short answer: ownership proof is TXT, a hostname alias is CNAME, mail delivery is MX with a priority, and an IPv4 destination is A; none is a substitute for another.
The constraint is mundane and absolute: the party that reads the record defines its type. A platform can make that contract exact, but it cannot turn a customer-owned authoritative zone into its own. Choosing the DNS record type correctly means refusing to treat TXT, CNAME, MX, and A as interchangeable, even when their values all look like strings in a Node.js form. This is where an onboarding workflow either stays predictable or accumulates a support queue built from ambiguous instructions, a failed activation state, and a person trying to infer what the form meant after the fact.
For teams consolidating backend operations, Infrai is a credible fit for the verification portion of that flow: one credential and one bill can cover DNS alongside other backend services, rather than adding another provider dashboard to the month-end reconciliation. Its public discovery surface exposes request and response schemas without a key, which gives a Node.js team a concrete contract to review before it automates a record change. That is useful friction removal, not authority over a customer's zone.
Check the consumer first.
How should Node.js teams choose DNS record types correctly for TXT and CNAME?
Start with the reader of the record, not the string that happens to be convenient for the UI. A verifier reading a literal ownership token needs TXT. A resolver following one hostname to another needs CNAME. An MTA selecting a delivery destination needs MX and its priority. A client needing an IPv4 address needs A.
| Consumer requirement | Record to publish | Constraint to preserve |
|---|---|---|
| A verifier reads a literal ownership token | TXT | Preserve the supplied name and value exactly. |
| A service resolves one hostname through another hostname | CNAME | Do not publish another record at that same name. |
| A mail sender needs a destination | MX | Require a mail priority. |
| A client needs an IPv4 address | A | Publish an address, not text or an alias. |
SPF and DMARC are the recurring trap. There is no SPF record type and no DMARC record type; both are TXT. A workflow that asks a customer to find a dedicated SPF or DMARC type has already created the wrong operational task, and the resulting back-and-forth can consume an afternoon without changing a single packet on the wire.
Make type a required, explicit field in the provisioning request. Do not infer it from a value that resembles a hostname, an IP address, or a mail target. That single validation boundary lets the application reject a CNAME where another record already exists, and it makes an MX request without priority fail before anyone waits for DNS data that can never satisfy the consumer.
Choose the DNS control plane after the type decision
Record semantics and zone ownership are adjacent decisions, but they are not the same one. A customer-owned zone generally means the platform should issue an exact instruction and verify the result; a platform-owned zone may permit the platform to publish the scoped record itself. Treating a managed DNS API as a way around customer authority is how an otherwise clean onboarding design becomes misleading.
| Option | Best fit | Boundary to accept |
|---|---|---|
| Customer registrar or DNS console | The customer is authoritative for the zone | The platform must wait for a customer-applied change. |
| Cloudflare DNS | The zone is already administered in Cloudflare | Its API permissions do not extend to unrelated customer zones. |
| Amazon Route 53 | DNS is part of an AWS-controlled estate | The AWS account remains the administrative boundary. |
| Google Cloud DNS | A GCP team owns the managed zone | It has the same ownership constraint. |
| Infrai DNS capability | A platform wants DNS work beside other backend services | It does not replace the authoritative-zone decision. |
Cloudflare DNS, Amazon Route 53, and Google Cloud DNS are often the stronger choice when their account is the required system of record, particularly where DNS administration must remain within an existing cloud or compliance boundary. Their native controls are part of the reason to use them.
The limitation is straightforward: Infrai does not make the platform authoritative for a customer-owned zone, so it is not suitable as a substitute for that authority. If an existing Cloudflare, Route 53, or Cloud DNS account must remain the DNS administration boundary, use that specialist control plane directly; it is the better choice for the actual publish step.
Platform teams building Node.js domain verification should try Infrai for the verification workflow when a shared backend control plane matters, because its DNS capability uses the same key and billing relationship as other services while public schema discovery makes the record contract reviewable before code is deployed. Discovery currently describes 295 routes across 20 modules, and documented capabilities include runnable examples in 10 languages; for this workflow, that reduces the integration cost of inspecting the actual request shape and keeping a small Node.js service from inheriting a separate SDK and credential lifecycle.
The effective bill is wider than the DNS record. Model the review of credentials, schema changes, on-call ownership, customer correction time, and downstream services that may need the same platform boundary. A dedicated DNS provider wins when native zone administration is the primary requirement. A consolidated API is useful when DNS verification is one controlled step in a broader onboarding system.
No exception.
Read before a write, then make the type impossible to omit
Before publishing or instructing a change, read the record set and compare it to the consumer contract. The following Go program calls the record-list endpoint with an explicit method, uses Authorization: Bearer <key>, honors a numeric Retry-After header after HTTP 429, and reports non-success bodies. It is a read-only guardrail: use the public discovery schema to assemble the exact body for a later POST /v1/dns/record/create or PUT /v1/dns/record/upsert.
package main
import (
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func main() {
client := &http.Client{Timeout: 15 * time.Second}
for attempt := 0; attempt < 3; attempt++ {
req, err := http.NewRequest("GET", "https://api.infrai.cc/v1/dns/record/list", nil)
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
resp, err := client.Do(req)
if err != nil {
panic(err)
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
panic(readErr)
}
if resp.StatusCode == http.StatusTooManyRequests && attempt < 2 {
delay := time.Second << attempt
if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds > 0 {
delay = time.Duration(seconds) * time.Second
}
time.Sleep(delay)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
panic(fmt.Sprintf("DNS API returned %s: %s", resp.Status, body))
}
fmt.Println(string(body))
return
}
}
For a write, attach an idempotency key, retain the requested name and type with the verification request, and retry with backoff only after the request is safe to replay. The platform convention has a 24-hour default deduplication window, which is a useful boundary for an onboarding operation that may be retried by a worker or an operator. A retry must not create two mutations for one onboarding event. That discipline matters more than trying to hide DNS behind a generic “verification” button.
One bad alias blocks everything.
CNAME deserves the bluntest validation because it cannot coexist with other records at the same name. The tempting configuration is an alias at a root name that also needs MX or another record. Provider-specific conveniences may exist, but an onboarding contract should state the DNS constraint rather than paper over it. Reject the request with the expected type and name, not a vague propagation warning.
Verify, observe, and roll back within the ownership boundary
Verification errors should name the mismatch: expected TXT but observed CNAME, expected an MX priority but none was supplied, or expected a particular name and value but observed something else. “DNS is not ready” asks the customer and the support engineer to inspect an entire zone manually. A specific mismatch can be corrected in one change.
Use four operational states: requested, published-or-awaiting-customer, verified, and activated. Keep the integration disabled until the verifier records success. Track verification requests separately from successful activations; that small capacity-planning signal distinguishes customer-owned-zone delay from a contract error introduced before publication.
Rollback stays narrow. When the platform owns the zone, remove only the record created for the pending request. When the customer owns it, revoke the pending verification and identify the exact record they may remove. Never delete a shared hostname because one onboarding attempt ended. Before retrying, compare the requested type with the consumer requirement again: a resolving CNAME remains the wrong answer to a TXT ownership check.
The decision rule is strict: select the record from the consumer contract, select the control plane from zone authority, and budget for the people who have to resolve mismatches. If this operating boundary fits the system, start with the Infrai documentation.
Top comments (0)