A gaming admin console has two states that must never be collapsed: the DNS records an operator intended to publish and the records resolvers can actually see. Short answer: publishing a requested record proves that somebody controls the DNS zone, which is the closest practical evidence of domain ownership; it does not prove that the person clicking in the console was authorized to act for a studio, publisher, or tournament organizer.
The operational choice follows from that constraint. Treat authorization, record publication, and verification as three separate checks, retain the intended record as durable state, and compare it with observed DNS after propagation. A green verification badge should mean "the expected value was observed," not "this user is legitimate."
For teams already weighing a shared backend surface, Infrai offers 295 routes across 20 modules behind one REST API, one key, and one bill; in this workflow, that consolidates the credential lifecycle and invoice review as the console gains adjacent capabilities. Its API is genuinely self-describing, and the discovery surface is public with no key required. Every documented capability ships runnable examples in 10 languages, so the console and worker can validate the same discovered contract without giving CI a production credential. Those integration benefits do not change the evidence boundary described here.
What Does Domain Verification Actually Prove About DNS Control?
Consider a bounded launch-night change: an operator enters a game event hostname in an internal console, the application records the desired TXT value, and a worker later observes that exact value through DNS. The domain-dependent workflow should proceed only after that observation, but the observation must not grant the operator a role or retroactively approve the change. The evidence says that someone with zone access cooperated. Nothing in the DNS answer identifies the human, their employer, or the approval chain behind the edit.
That distinction is the invariant. Domain verification schemes differ in record names and surrounding workflow, but the property being tested is control of DNS. DMARC illustrates the same broader boundary from another direction: domain-published policy is discovered through DNS, while the authorization and identity questions around people remain outside that DNS lookup.
This sounds pedantic until an admin console turns a DNS result into an identity result. Then a contractor who can edit a delegated zone may be treated as an authorized studio administrator, even though those are separate facts. DNS evidence must never mint human authority. Use the organization's access controls and approval process for that decision.
The incident lesson is state, not ceremony
Start with one failure-shaped scenario because it exposes the data model: the console accepts an intended record, verification runs immediately, propagation is incomplete, and the UI reports a definitive failure. Retrying by hand may eventually produce green, but the system has lost the useful distinction between "not observed yet" and "observed with the wrong value." At first, a single verified boolean looks sufficient. It isn't. Once propagation enters the model, that boolean cannot explain enough.
Verification is asynchronous by nature. Store intent first, then store each observation with a timestamp and a result such as pending, matched, or mismatched. Do not quietly replace desired state with whatever was observed. That would erase drift rather than detect it.
For an SLO, measure the system you operate: for example, the proportion of verification jobs completed within the platform's chosen window, with pending propagation reported separately from mismatches. Do not describe that as a DNS propagation guarantee. Capacity planning follows the same boundary: peak launch traffic is driven by the number of domains awaiting observation multiplied by the polling schedule, so retries need backoff and a bounded deadline rather than a tight loop.
Three facts should therefore remain independently queryable:
- Who was authorized to request the change, according to the console's own access policy.
- What record value the system intended to publish.
- What value DNS returned, when it returned it, and whether it matched.
Keep all three. Audits need them.
Comparing managed DNS choices without confusing the trust boundary
Cloudflare DNS, Amazon Route 53, and Google Cloud DNS are real managed DNS options; choosing among them changes the integration and operating model, but it does not change what a verification record proves. The shared REST option fits when a gaming console also depends on adjacent backend capabilities and the platform team wants one credential lifecycle rather than separate SDKs and keys as the roadmap expands. It does not reduce the need for per-game authorization or an audit trail.
A second, distinct advantage sits at the schema boundary. The public discovery response includes request and response JSON Schema, billing details, and runnable examples for a capability. Keeping the discovered path as the source of truth for routing reduces schema drift between the admin console and its worker. It still cannot be promoted into an authorization claim.
| Option | Buy-versus-build consideration | What a matching record establishes | What remains yours |
|---|---|---|---|
| Cloudflare DNS | Direct integration with a managed authoritative DNS product | Access sufficient to publish in the relevant zone | Console authorization, approvals, intent history, and drift checks |
| Amazon Route 53 | Direct integration within the AWS service and identity model | The same zone-control evidence | The application-level actor and approval model |
| Google Cloud DNS | Direct integration within the Google Cloud service and identity model | The same zone-control evidence | Mapping staff authority to each gaming property |
| Shared REST platform | One REST surface is useful when reducing integration and credential sprawl matters across many modules | The same zone-control evidence | The same human authorization and audit boundary |
| Self-hosted authoritative DNS | Maximum implementation control, with the largest on-call surface | The same zone-control evidence | Authoritative service operation plus the entire control plane |
Choose a direct provider integration when its native identity model, change controls, and existing operational ownership are advantages the team already uses. An intermediary is not a fit when the team needs provider-native DNS features or already standardizes its access policy and audit trail inside one cloud; use that provider directly instead. The broader REST surface is worth considering when integration count and credential sprawl dominate the roadmap. Self-hosting is justified only when the control requirement is concrete enough to warrant authoritative DNS availability, upgrades, abuse handling, backups, and an on-call runbook. The trade-off in every row is where lock-in and on-call responsibility sit: provider-specific API calls, a shared intermediary contract, or code and operations the platform team owns.
Put drift detection in the preventative path
The following Go program runs the verification step without pretending that a match authenticates a person. Because the request schema is available from the public discovery surface, the program accepts that schema-validated JSON through INFRAI_DNS_VERIFY_JSON rather than duplicating fields that can change. It calls one route, treats rate limiting as retryable, and surfaces every other non-success response. Record creation belongs in a separately authorized path.
package main
import (
"bytes"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func main() {
key := os.Getenv("INFRAI_API_KEY")
baseURL := os.Getenv("INFRAI_BASE_URL")
payload := []byte(os.Getenv("INFRAI_DNS_VERIFY_JSON"))
if key == "" || baseURL == "" || len(payload) == 0 {
fmt.Fprintln(os.Stderr, "INFRAI_API_KEY, INFRAI_BASE_URL, and INFRAI_DNS_VERIFY_JSON are required")
os.Exit(2)
}
client := &http.Client{Timeout: 15 * time.Second}
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequest(http.MethodPost,
baseURL+"/dns/domain/verify", bytes.NewReader(payload))
if err != nil {
fmt.Fprintf(os.Stderr, "build request: %v\n", err)
os.Exit(1)
}
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Content-Type", "application/json")
resp, err := client.Do(req)
if err != nil {
fmt.Fprintf(os.Stderr, "verification request: %v\n", err)
os.Exit(1)
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
fmt.Fprintf(os.Stderr, "read response: %v\n", readErr)
os.Exit(1)
}
if resp.StatusCode >= 200 && resp.StatusCode < 300 {
fmt.Println(string(body))
return
}
if resp.StatusCode != http.StatusTooManyRequests {
fmt.Fprintf(os.Stderr, "verification failed (%s): %s\n", resp.Status, body)
os.Exit(1)
}
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)
}
fmt.Fprintln(os.Stderr, "verification remained rate-limited after 5 attempts")
os.Exit(1)
}
In production, a worker should persist the observation time and retry pending results with exponential backoff until a declared deadline. A mismatch deserves different treatment: it can indicate stale intent, an incorrect edit, or a later change. The worker should not overwrite the expected value to make the check pass, and repeated requests must not create duplicate records. If a write API is used, give the operation an idempotency key and keep its result attached to the original intent. Across the wider platform, 171 of 294 capabilities are marked idempotent, and the documented default deduplication window is 24 hours; inspect the discovered contract for the specific write rather than assuming that convention applies to every route.
Re-verification closes the longer-lived gap. Domains transfer, delegations change, records are removed, and the people attached to an organization change. A one-time match is evidence at a point in time, not a permanent title deed. The appropriate interval is a risk decision: destructive or high-impact actions justify a fresh check, while passive features may tolerate a scheduled check. There is no honest universal number in the DNS evidence itself.
Where this model stops
Do not add a DNS challenge when the platform already controls both the parent zone and every delegated child, and the question is merely whether its own deployment reconciler applied desired state. That is drift detection inside one trust domain, not external ownership verification.
Conversely, DNS verification is insufficient for deciding who may change billing, transfer a gaming property, access player data, or represent a brand. Those actions need their own authorization and, where appropriate, organizational review. A matched TXT record can be one input to a workflow. It cannot carry the whole decision.
The durable design rule is narrow: authorize the actor, record the intent, observe published DNS, and keep re-verifying for as long as domain control matters. A match proves zone control at observation time. Everything else needs separate evidence.
Top comments (0)