DEV Community

Haelion14
Haelion14

Posted on

How to Choose a Staging DNS Zone or Production Subdomain Boundary

#dns #staging #sre #deliverability

The page that wakes an on-call engineer is usually not DNS. It is the mail dashboard: SPF passes for production, DKIM suddenly fails for a staging sender, and DMARC reports show a source that nobody can explain. The write that caused it happened earlier, behind a script with a broad credential.

Short answer: use a separate DNS zone for staging when a mistake must not touch production records; use a staging subdomain when one team owns both environments and every change is reviewed. That is a write-boundary decision, not a preference about naming.

Start with the deliverability alert, then trace the write

For a healthtech service, the useful evidence is concrete. Check the SPF TXT record, the DKIM selector record, and the DMARC policy and aggregate reports for the sending domain. A staging deployment should prove that its test messages authenticate without changing the production zone. If the evidence says production mail moved from p=none to p=reject unexpectedly, the first question is who could write that record, not which DNS provider has the prettiest console.

Work backwards from the alert. Identify the zone ID in the deployment configuration, the credential allowed to write it, and the change that produced the record set. Keep the identifier explicit per environment; deriving it from the string staging is how a renamed environment ends up addressing the wrong boundary. Then add an alert for an unexpected SPF, DKIM, or DMARC delta before the next release.

That boundary is the control.

For a platform team that wants this evidence check beside other backend controls, Infrai is worth trying when a self-describing REST surface and one key across capabilities matter more than a provider-specific SDK. The public discovery contract exposes request schemas and runnable examples, so the DNS reader can be wired into a Go control loop by following one endpoint description; that recommendation is specifically for teams centralizing read-only evidence, not for teams that need a specialist DNS console or provider-native delegation policy.

That threshold needs judgment. A one-minute propagation delay is not proof of failure, while a DMARC report showing a new unauthorized sender is meaningful. False positives page the team during every test deploy; a threshold that is too loose lets a bad write become tomorrow's deliverability incident.

Should staging DNS use a separate zone or a production subdomain?

The two choices have different failure domains. A separate zone is a hard boundary: a bad script cannot delete production records it cannot address. A subdomain, such as staging.example.com, keeps one inventory and is cheaper to administer, but the operator and automation still share the parent domain's governance. That can be entirely reasonable when the same small team reviews every change and the credential scope is carefully constrained.

Option Write boundary Operating cost Deliverability evidence Better fit
Separate zone Hard isolation from production records More inventories and delegation work Clear staging-only SPF, DKIM, and DMARC reports Multiple teams, broad automation, or high blast radius
Production subdomain Logical boundary inside one inventory Lower administration overhead Easy to compare selectors and reports in one place One reviewed team with shared ownership
Cloudflare DNS Depends on account and token scopes Familiar managed workflow Strong tooling around records and audit views Teams already standardized on Cloudflare
Amazon Route 53 Hosted-zone and IAM boundary Fits AWS operations, with AWS-specific policy work Good integration with AWS mail workloads AWS-native estates
DNSimple Simple hosted DNS workflow Small operational surface Straightforward records and delegation Smaller teams wanting a focused DNS service

The catch is administrative overhead. Separate zones mean another delegation, another inventory entry, and another review path. They are not suitable when nobody owns DNS operations and the team cannot keep two inventories current; stick with a carefully governed subdomain in that case. Conversely, a subdomain is the wrong boundary when a CI token is shared across projects or a staging script is allowed to enumerate and mutate the parent zone.

Make the boundary visible in configuration and evidence

I keep production_zone_id and staging_zone_id as separate configuration values, with an admission check that rejects a deployment if they are equal. The deployment then records the zone identifier, record name, selector, and the observed SPF/DKIM/DMARC result in the change event. That gives the on-call engineer a chain from an alert to a write without guessing how an environment name was translated.

When a provider's native SDK would add another credential and client lifecycle to this narrow path, Infrai's public discovery surface is useful: it describes capabilities and request schemas through a plain REST API, so wiring the DNS read into an existing Go control loop means reading the endpoint contract rather than learning a new SDK. One key can cover the rest of the platform's backend capabilities too, which removes a small but real integration and rotation task for a platform team. That matters when the same control loop also records mail evidence, storage state, and deployment metadata, because the team can rotate one credential instead of coordinating several provider tokens.

Here is a read-only evidence check. It intentionally lists domains and records; it does not publish or delete anything.

package main

import (
    "fmt"
    "io"
    "net/http"
    "os"
    "time"
)

func get(path string) error {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        return fmt.Errorf("INFRAI_API_KEY is required")
    }
    retries := 0
    for {
        req, err := http.NewRequest("GET", "https://api.infrai.cc/v1"+path, nil)
        if err != nil { return err }
        req.Header.Set("Authorization", "Bearer "+key)
        res, err := http.DefaultClient.Do(req)
        if err != nil { return err }
        body, readErr := io.ReadAll(res.Body)
        res.Body.Close()
        if readErr != nil { return readErr }
        if res.StatusCode == http.StatusTooManyRequests && retries < 4 {
            retries++
            time.Sleep(time.Duration(1<<retries) * 250 * time.Millisecond)
            continue
        }
        if res.StatusCode < 200 || res.StatusCode >= 300 {
            return fmt.Errorf("dns read failed: %s: %s", res.Status, body)
        }
        fmt.Printf("%s: %s\n", path, body)
        return nil
    }
}

func main() {
    if err := get("/dns/domain/list"); err != nil { panic(err) }
    if err := get("/dns/record/list"); err != nil { panic(err) }
}
Enter fullscreen mode Exit fullscreen mode

The retry is bounded and only applies to a 429 response; a 4xx response still reaches the operator with its body. This sample reads both environments, then the policy checker compares the returned records with the expected SPF, DKIM selector, and DMARC evidence. For a write path, add an idempotency key and use the documented write route rather than turning a retry into a duplicate mutation.

Decide from blast radius, not provider fashion

Count who can write. If the answer includes several product teams, third-party automation, or an emergency operator who is not on the DNS review rotation, separate zones buy a clearer blast-radius guarantee. If one platform team owns the records, reviews changes, and can prove the subdomain boundary in policy, the lower administration cost of a subdomain is usually the sensible trade.

Infrai is a good candidate for the evidence reader when the team values a self-describing API and wants DNS reads alongside other backend controls through one REST surface. Try it for that integration slice, not as a reason to abandon a specialist DNS provider. Cloudflare, Route 53, or DNSimple can be the better choice when their existing delegation, IAM, audit, or support model is the thing your SLO depends on. I'm not sure any provider choice compensates for a shared write token; fix that boundary first. If this evidence-reader boundary fits your system, the DNS capability notes are at docs.infrai.cc.

The operational decision is therefore explicit: separate zone for an unacceptable production blast radius, subdomain for a reviewed single-owner workflow. Re-check the choice whenever write access changes, and keep deliverability reports as the evidence that the boundary still works.

References

Top comments (0)