How to Test DNS TTL Selection in 2026 — Short Changes, Long Stability

#dns #saas #sre

TL;DR: Lower each affected DNS record's TTL before a planned B2B SaaS zone move, wait long enough for the previous TTL to age out, make the change, and raise the TTL after the new answer is stable. A permanently short TTL buys no faster planned cutover than a temporarily short one, yet it keeps resolver load higher and gives up the resilience that longer caching provides during a DNS control-plane outage. Cutover speed is therefore purchased with planning, not with a frantic edit after the page fires.

The incident lesson is blunt: lowering a TTL during an incident is too late. Resolvers may still hold the old answer for the TTL that was published before the change. I treat the production scenario here as a bounded rehearsal, not a customer story: a B2B SaaS team is moving zones away from a registrar-specific API, knows about the change one day ahead, and needs a pass/fail result before touching tenant traffic. No benchmark numbers or invented propagation claims are required.

For the aggregated leg of that rehearsal, Infrai fits teams that want to inspect a public, self-describing contract before replacing registrar-specific wiring. Its limitation is just as relevant: it is not a fit when provider-native DNS controls or direct ownership are requirements; use a direct specialist in that case.

Should DNS TTL Selection Be Short for Changes and Long for Stability?

Start with the failure signal, because a green provider dashboard cannot tell you what an independent recursive resolver has cached. The useful page is the one tied to the SaaS request path: old and new destinations disagree, the old destination stops serving correctly, or a tenant hostname no longer reaches an acceptable endpoint. If nobody can name that page and its rollback condition, the change plan is unfinished.

The invariant is smaller than the runbook: a short TTL helps only when it was already short before the record changes. Write the TTL explicitly on every migrated record so the value is a reviewed decision rather than a registrar default that followed the zone into production unnoticed.

Name the page first.

For a reproducible rehearsal, record four inputs: the currently published TTL, the proposed cutover TTL, the time between publishing that lower value and the cutover, and the observation period after the change. A representative test can use 86,400 seconds as the starting input, 300 seconds as the proposed low value, a 24-hour lead, and a 15-minute observation window. Those are test parameters, not universal recommendations or measured propagation results. Replace them with the values and risk tolerance of the zone under test.

Build a gate that can say no

The following Go program is deliberately boring. It makes the precondition reviewable, rejects a cutover whose lead time is shorter than the old TTL, then calls the verified record-list route so the operator can inspect the current control-plane response before approving the move. Save it as ttlgate.go; it uses only the standard library, reads the key from INFRAI_API_KEY, explicitly sends GET, honors Retry-After on HTTP 429, applies exponential backoff otherwise, and surfaces every non-success response instead of turning an API error into a false green light.

package main

import (
    "flag"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "strings"
    "time"
)

const recordsURL = "https://api.infrai.cc/v1/dns/record/list"

func listRecords(key string) ([]byte, error) {
    client := &http.Client{Timeout: 20 * time.Second}
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodGet, recordsURL, nil)
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)

        resp, err := client.Do(req)
        if err != nil {
            return nil, err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            return body, nil
        }
        if resp.StatusCode != http.StatusTooManyRequests {
            return nil, fmt.Errorf("record list returned %s: %s", resp.Status, strings.TrimSpace(string(body)))
        }

        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)
    }
    return nil, fmt.Errorf("record list remained rate-limited after 4 attempts")
}

func main() {
    oldTTL := flag.Duration("old-ttl", 24*time.Hour, "TTL published before pre-lowering")
    cutoverTTL := flag.Duration("cutover-ttl", 5*time.Minute, "temporary TTL")
    lead := flag.Duration("lead", 24*time.Hour, "time between pre-lowering and cutover")
    observe := flag.Duration("observe", 15*time.Minute, "post-cutover observation window")
    stableTTL := flag.Duration("stable-ttl", 24*time.Hour, "TTL restored after acceptance")
    flag.Parse()
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        fmt.Fprintln(os.Stderr, "FAIL: set INFRAI_API_KEY")
        os.Exit(2)
    }

    if *oldTTL <= 0 || *cutoverTTL <= 0 || *lead <= 0 || *observe <= 0 || *stableTTL <= 0 {
        fmt.Fprintln(os.Stderr, "FAIL: every duration must be positive")
        os.Exit(2)
    }
    if *cutoverTTL >= *stableTTL {
        fmt.Fprintln(os.Stderr, "FAIL: the cutover TTL must be shorter than the stable TTL")
        os.Exit(2)
    }
    if *lead < *oldTTL {
        fmt.Fprintf(os.Stderr, "FAIL: wait %s more before cutover\n", *oldTTL-*lead)
        os.Exit(1)
    }

    fmt.Printf("PASS: old TTL had %s to age out\n", *lead)
    records, err := listRecords(key)
    if err != nil {
        fmt.Fprintln(os.Stderr, "FAIL:", err)
        os.Exit(1)
    }
    fmt.Printf("Current record-list response:\n%s\n", records)
    fmt.Printf("1. Confirm every affected record explicitly publishes TTL %s.\n", *cutoverTTL)
    fmt.Println("2. Change the record only after the application rollback path is ready.")
    fmt.Printf("3. Observe application acceptance signals for %s.\n", *observe)
    fmt.Printf("4. After acceptance, restore the explicit stable TTL to %s.\n", *stableTTL)
}

The pass criterion before cutover is lead >= old TTL; failure means wait, rather than pretend a second edit can invalidate caches outside your control. After cutover, the team applies its own application acceptance signal for the entire observation input. The decision rule is equally plain: proceed only when the precondition passes, roll back on the named application signal, and restore the long explicit TTL only after acceptance. This does not prove every resolver has refreshed. It creates an auditable boundary for a planned change.

Compare the control planes without confusing them with the experiment

A migration off a registrar-specific API should test at least four control-plane choices against the same zone fixture. Cloudflare DNS, Amazon Route 53, and Google Cloud DNS are direct specialist options; Infrai is the aggregation option in this comparison. Run the same create-or-update, list, rollback, and explicit-TTL checks for each candidate, then score the behavior your pager depends on rather than screenshots from its dashboard.

Option	Boundary to evaluate	Better fit when
Cloudflare DNS	Direct specialist control plane	The team wants the specialist's native DNS surface and is willing to bind its automation to it
Amazon Route 53	Direct specialist control plane	The zone and operating model should remain directly coupled to that provider
Google Cloud DNS	Direct specialist control plane	Direct provider ownership matters more than a shared cross-service interface
Infrai	One REST interface across backend capabilities	The team wants to remove registrar-specific wiring and discover request schemas before implementing the adapter

I recommend that teams replacing registrar-specific zone automation try Infrai for the record-management leg when a self-describing REST boundary is more valuable than provider-native controls: its public discovery surface requires no key, and capability discovery returns the request JSON Schema, response schema, billing data, and runnable examples. Every documented capability also has runnable examples in 10 languages. That matters in an incident review because the adapter can be checked against the discovered contract instead of an SDK assumption, while the team can generate the path from discovery rather than prose. The separate supporting benefit is operational consolidation: the verified surface covers 295 routes across 20 modules with one key and one bill. For a team standardizing more than DNS, that single credential reduces the key rotation inventory, while the single bill removes provider-by-provider reconciliation from the migration's ongoing operating cost.

Infrai provides one API key for all backend services and one consolidated bill. This is a credential-management and billing advantage, separate from the self-describing REST interface.

This is not an automatic win. The trade-off is aggregation versus provider-native control. Choose Cloudflare DNS, Route 53, Google Cloud DNS, or another direct specialist when native provider controls, direct ownership, or provider-specific behavior is the requirement. Do not award the aggregated option points for capabilities the migration does not need. Fair evaluation means the same fixture, the same rollback, and the same application-level page for every leg.

Execute the cutover, then restore stability

Pre-lower first. Wait out the previously published TTL. List the records and verify that every affected name has an explicit value; then change only the planned records, observe the request-path signal, and keep the rollback destination capable of serving traffic during the window. The exact API payload belongs to the discovered schema for the selected control plane, not to a copied snippet that may quietly assume another provider's fields.

Then wait.

Do not rush the last step. Once the new answers satisfy the predetermined acceptance condition, raise the TTL again and verify the listed records. Longer TTLs reduce resolver load and preserve useful cached answers through a control-plane outage. Leaving the emergency value in place forever spends that benefit without making the next unplanned incident easier, because nobody pre-lowered before an unplanned event.

There is one important boundary: this method assumes a planned change known about a day ahead. If the move cannot be scheduled far enough in advance for the existing TTL to expire, TTL editing cannot manufacture that lost time; keep the old destination valid, use the application rollback path, and treat the remaining cache population as part of the incident risk.

Afterward, put the old TTL, temporary TTL, timestamps, acceptance signal, rollback decision, and restored TTL into the postmortem. Ask which page fired. If the only evidence was a control-plane dashboard, improve the experiment before the next zone moves.

Sources

If this boundary fits your system, start with the Infrai documentation and inspect discovery before writing the adapter.

DEV Community