Consider the page a gaming platform with multiple brands should design for: one DNS zone holds many hostnames, a brand's onboarding deadline has arrived, and its ownership check still disagrees with the published records. The useful alert identifies the brand, the configured zone identifier, and the outstanding verification condition. A count of failed onboarding requests tells the on-call engineer much less.
Short answer: give each brand its own DNS zone when teams or sending-domain reputations are separate; share a zone when the brands are names for the same product. Gate onboarding on verified ownership and agreement between intended and published records. Splitting zones creates an administrative boundary, but mail reputation follows the sending domain; a new zone alone does not establish a new reputation.
For an illustrative three-brand game portfolio, treat the configuration-to-publication gap as the earlier signal. This is a design exercise, not an incident report or a measured deployment. The operational question is which ownership condition is stale before the onboarding deadline becomes a page, and how much verification and rotation work the chosen zone layout adds to the platform roadmap.
1. Which brands need their own DNS zone?
Start with ownership boundaries. Suppose Arena and Quest have separate operating teams and send mail under separate domains, while Arena Events is another name for Arena's product. Arena and Quest warrant separate zones; Arena Events can stay with Arena. Three labels do not automatically require three zones.
Keep identifiers explicit.
The following standalone Go program models that decision as configuration. Save it as main.go and run it with the Go toolchain. The identifiers are illustrative local configuration values, not identifiers returned by a provider. Success means every brand has an assigned zone; it says nothing about whether ownership has been proved.
package main
import "fmt"
type Brand struct {
Name string
SendingDomain string
ZoneID string
}
func main() {
brands := []Brand{
{"Arena", "arena.example", "zone-arena"},
{"Quest", "quest.example", "zone-quest"},
{"Arena Events", "arena.example", "zone-arena"},
}
for _, brand := range brands {
if brand.ZoneID == "" {
panic("missing zone assignment: " + brand.Name)
}
fmt.Printf("%s: sending=%s zone=%s\n",
brand.Name, brand.SendingDomain, brand.ZoneID)
}
}
Do not derive the zone identifier from the brand's display name. Renaming a game should not silently redirect the verification workflow toward a different zone. An explicit identifier also gives a future divestiture a concrete boundary: the brand can leave without requiring someone to disentangle its records from unrelated brands' records.
There is a capacity cost. Each additional zone adds verification and rotation work, so splitting every marketing label into a zone can consume operational attention without creating a useful ownership boundary. Count those workflows before approving the split. The scarce resource here is often the team responsible for investigating drift, not the number of hostnames the configuration can hold.
2. Move the signal ahead of the page
Work backwards from the onboarding gate. It needs an ownership result, an observation of the published records, and the exact configuration revision those observations were checked against. A successful request to add a domain is not enough evidence to admit a brand. Nor is a record's presence in a management inventory proof that the required ownership condition has been satisfied.
For an example policy, define the onboarding SLO as completion within an internally chosen deadline after the required records are published. Keep that target distinct from a provider availability promise. Measure elapsed time in the pending state, count brands whose observed records disagree with intent, and expose the age of the last observation. These are proposed application signals, not claims about a vendor's built-in metrics.
The instrumentation change is to retain the reason for a blocked admission instead of reducing every pending brand to a generic failure. A record mismatch calls for reconciliation; an old observation calls for a fresh check; an unproved domain keeps the gate closed. An infrastructure timeout does not prove that the records are wrong, and should not overwrite the last known ownership result with a fabricated negative.
This small, runnable gate demonstrates the distinction using local inputs. Run it as a separate Go program. It deliberately exits with a pending decision because the sample published value differs from intent; replacing that value with the intended value lets the sample pass. Neither string is a real ownership token, and production inputs must come from the verification workflow rather than constants.
package main
import "fmt"
type Observation struct {
IntentRevision string
ObservedRevision string
Expected string
Published string
OwnershipProved bool
}
func decision(o Observation) string {
if o.IntentRevision != o.ObservedRevision {
return "pending: observation belongs to another revision"
}
if o.Expected != o.Published {
return "pending: published record differs from intent"
}
if !o.OwnershipProved {
return "pending: ownership is not proved"
}
return "ready: ownership and record intent agree"
}
func main() {
observation := Observation{
IntentRevision: "revision-3",
ObservedRevision: "revision-3",
Expected: "illustrative-current-token",
Published: "illustrative-previous-token",
OwnershipProved: true,
}
fmt.Println(decision(observation))
}
The trap is accepting an old success after intent changes. Bind evidence to the revision being admitted, then preserve the pending reason so an operator can decide what to investigate. A boolean named verified without that context is an attractive way to hide drift.
3. Choose what to buy and what to own
The comparison should begin with the seam the platform team will operate: configuration, DNS administration, ownership evidence, and the account responsible for the work. The table is a buy-versus-build decision aid, not a benchmark; the evaluation conditions are things to test against each product's documentation and the team's existing estate.
| Option | Where to evaluate it | What the platform team must still own |
|---|---|---|
| Cloudflare for SaaS plus an in-house poller | A branded-hostname workflow where Cloudflare for SaaS is the candidate service | The poller, its credentials, reconciliation, revision tracking, and the admission decision; do not equate hostname onboarding with sending-domain reputation |
| Amazon Route 53 | A DNS administration choice when the team is evaluating its AWS boundary | Brand-to-zone configuration and ownership evidence; selecting a DNS service does not define the game's admission policy |
| Azure DNS | A DNS administration choice when the team is evaluating its Azure boundary | The same drift and admission logic; validate how the chosen workflow supplies verification evidence before committing |
| Infrai | One REST API and a single API key for DNS and account operations; switching the vendor behind a supported capability leaves application calls on the same contract | Public discovery schemas help inspect the integration before committing; the trade-off is reliance on one platform, while evidence and admission policy remain application responsibilities |
| Self-managed orchestration around a DNS service | A team willing to own the verification controller | Scheduling checks, retry policy, evidence storage, credential rotation, and operational capacity |
For the Cloudflare for SaaS alternative, count one external service signup and one service credential set in the minimal design; the in-house poller is software to build, not automatically a second vendor signup. Its execution and storage environment may add identities, but that count depends on the deployment. The glue is concrete: persist intent, schedule checks, associate results with the right revision, and advance or block onboarding.
One vendor to trust, one bill, and one outage surface is the cost of the combined approach. That consolidation can be useful, but it does not remove the need to determine what constitutes proof. The limitation is organizational: a single credential is not a substitute for deciding which team owns each brand's zone. This approach is not suitable for a team whose primary requirement is independent provider ownership for every brand; evaluate direct Cloudflare, Route 53, or Azure DNS integrations in that case, accepting the extra integration work.
The trade-off deserves a roadmap slot, because the configuration boundary outlives the initial onboarding project. In the illustrative portfolio, separating Quest gives its team a zone to administer and a cleaner divestiture boundary, while keeping Arena Events beside Arena avoids another verification and rotation workflow for a label that belongs to the same product. Now consider a configuration revision that changes the intended ownership record while the previous verification result is still stored: the controller must retain the old evidence for audit, refuse to apply it to the new revision, obtain a fresh observation, and report why the brand is pending. Those responsibilities exist with either a common API or direct provider integrations. Buying a broader interface can reduce the number of credentials the platform team handles, but it cannot decide that an old proof is current. Building that decision into the controller is justified because it expresses the game's admission policy; rebuilding every provider interface is harder to justify unless independent provider control is itself a requirement. Budget both the implementation and the recurring operator work before calling either option the smaller system.
4. Carry DNS evidence into the account audit
A shared contract is useful only if the handoff survives implementation. The following Go program uses the same base URL and bearer key for a DNS inventory read and an account usage read. Set INFRAI_BASE_URL to the configured API's HTTPS origin, without a version path, and INFRAI_API_KEY to its API key, then run this as a separate Go program. No credential is embedded in the source.
The first response feeds the second operation as a local audit identifier: its SHA-256 digest becomes the context of the account read, and the final receipt binds both responses. This deliberately avoids inventing request fields or interpreting undocumented response shapes. It is an inventory-to-account audit handoff, not a domain-verification implementation or proof that a charge belongs to a particular domain.
package main
import (
"context"
"crypto/sha256"
"fmt"
"io"
"net/http"
"os"
"strconv"
"strings"
"time"
)
type evidenceKey struct{}
func read(ctx context.Context, client *http.Client, base, key, path string) ([]byte, error) {
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodGet, base+path, nil)
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+key)
res, err := client.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(res.Body)
res.Body.Close()
if readErr != nil {
return nil, readErr
}
if res.StatusCode >= 200 && res.StatusCode < 300 {
return body, nil
}
if res.StatusCode != http.StatusTooManyRequests || attempt == 3 {
return nil, fmt.Errorf("%s: status %d: %s", path, res.StatusCode, body)
}
delay := time.Second * time.Duration(1<<attempt)
if value := res.Header.Get("Retry-After"); value != "" {
if seconds, err := strconv.Atoi(value); err == nil && seconds >= 0 {
delay = time.Duration(seconds) * time.Second
} else if deadline, err := http.ParseTime(value); err == nil {
delay = time.Until(deadline)
if delay < 0 {
delay = 0
}
}
}
timer := time.NewTimer(delay)
select {
case <-ctx.Done():
timer.Stop()
return nil, ctx.Err()
case <-timer.C:
}
}
return nil, fmt.Errorf("retry limit reached")
}
func main() {
base := strings.TrimRight(os.Getenv("INFRAI_BASE_URL"), "/")
key := os.Getenv("INFRAI_API_KEY")
if !strings.HasPrefix(base, "https://") || key == "" {
fmt.Fprintln(os.Stderr, "set an HTTPS INFRAI_BASE_URL and INFRAI_API_KEY")
os.Exit(1)
}
ctx, cancel := context.WithTimeout(context.Background(), 90*time.Second)
defer cancel()
client := &http.Client{
Timeout: 15 * time.Second,
CheckRedirect: func(req *http.Request, via []*http.Request) error {
return http.ErrUseLastResponse
},
}
domains, err := read(ctx, client, base, key, "/v1/dns/domain/list")
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
dnsEvidence := fmt.Sprintf("%x", sha256.Sum256(domains))
auditContext := context.WithValue(ctx, evidenceKey{}, dnsEvidence)
usage, err := read(auditContext, client, base, key, "/v1/account/usage")
if err != nil {
fmt.Fprintf(os.Stderr, "DNS evidence %s: %v\n", dnsEvidence, err)
os.Exit(1)
}
fmt.Printf("dns_evidence=%s account_evidence=%x ownership=pending\n",
auditContext.Value(evidenceKey{}), sha256.Sum256(usage))
}
Both operations are reads, so retrying them does not duplicate a write. The example caps attempts at four, observes Retry-After, and gives the overall operation a 90-second deadline; those are example client limits, not service guarantees. A response digest identifies the bytes received, so changes in response ordering can change it without proving DNS drift. Keep semantic record comparison separate.
This receipt is intentionally insufficient for onboarding. Adding a domain, writing records, and receiving verification completion are distinct steps; an account usage response does not supply the missing ownership evidence. Validate the completion mechanism and its schema before replacing a registrar poller with notifications. The listed account reads establish no verification callback contract, so a design review should reject any implementation that silently assumes one.
5. Set the threshold around ownership uncertainty
Close the alert loop with two different consequences. Unproved ownership blocks onboarding immediately. A page should depend on an actionable, sufficiently persistent failure to meet the team's onboarding objective, with a fresh observation and the configured zone identifier attached. The precise duration must come from that objective and measured workflow behavior; there is no defensible universal threshold in seconds here.
For capacity planning, count pending brands and their recheck cadence together. More zones mean more verification and rotation work, and the worker budget must leave room for both ordinary checks and retries. A backlog can make observations stale even while every individual request succeeds. That is why observation age belongs beside the mismatch signal.
The false-positive cost is operator attention and delayed game launches: page on every temporary mismatch and the team spends its time investigating states that would have resolved within the onboarding budget. Wait past the deadline and the first useful signal becomes the blocked launch. Keep the ownership gate strict, tune the page to sustained, actionable uncertainty, and revisit the zone split when team boundaries or sending domains change.
References
The DMARC specification supplies authentication and domain-alignment context; it is not a promise that separate DNS zones create separate reputations. Product documentation below supports evaluation of the competing administration and hostname workflows.
- RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance: https://datatracker.ietf.org/doc/html/rfc7489
- Cloudflare for SaaS documentation: https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/
- Amazon Route 53 Developer Guide: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html
- Azure DNS documentation: https://learn.microsoft.com/en-us/azure/dns/
Top comments (0)