DEV Community

TitanJ53
TitanJ53

Posted on

Apex A Records vs WWW-Only Customer Domain Support: Propagation Trade-offs

#dns #domains #backend #architecture

Support apex and www records together when a gaming company expects a clean customer URL. Choose www-only when rapid provider changes and portable DNS instructions matter more than the bare domain. The deciding constraint is propagation: an API can accept a change immediately, but recursive resolvers keep cached answers until their TTL expires.

This is an architecture decision record, not a checkbox in a setup wizard. An apex name such as example.com cannot be a CNAME, so apex support means publishing an address that the service must keep stable. A www CNAME can follow a hostname during a migration. That distinction determines how much of a cutover is coupled to every customer zone.

What must remain invariant during a customer cutover?

I use four invariants for this decision:

  1. The documented address is the exact value a customer should paste. A typo in that value creates support work before application code runs.
  2. Apex and www cannot disagree after setup. Publishing one while the other is pending creates the half-configured state behind a large share of DNS tickets.
  3. A repeated write must be safe. An upsert or a client-supplied idempotency key prevents a retry from creating a second record.
  4. The TTL window is part of the release plan. A 300-second TTL is a five-minute cache window; 3,600 seconds can preserve an old answer for an hour. Lowering TTL helps future changes, but it cannot flush caches that already hold the previous answer.

The last invariant is easy to miss in a game launch. A provider returning HTTP 200 proves that its authoritative service accepted the mutation. It does not prove that a player's resolver has the new answer. Schedule the change around the longest TTL you have actually published, not the time your control-plane request took.

That is the whole game.

Should customer domains support apex A records and www together?

Usually, publish both together. The www CNAME keeps the customer zone pointed at a stable hostname that you can repoint. It is portable across providers and avoids baking an IPv4 address into hundreds of customer zones. The trade-off is support pressure: customers will keep asking why the bare domain does not work. www-only is a legitimate product boundary, but the request will not stop, so document the redirect or rejection behavior before launch.

No magic record exists.

An apex A or AAAA record gives the clean URL customers expect, while coupling their zone to your address. If that address changes, each customer must edit an A record, wait for propagation, and possibly diagnose a stale recursive answer. Cloudflare can flatten a CNAME at the apex, Amazon Route 53 offers alias records, and NS1 provides its own apex and traffic-steering features. Those are useful provider mechanisms, not portable DNS semantics; migration between them still needs a stable target and a rollback window.

Option Cutover behavior Portability Support boundary
www CNAME only Repoint a hostname; resolver caching still applies High Customers use or redirect to www
Apex A/AAAA only Address stays stable through propagation Medium to low Bare domain works; migrations are coordinated
Apex plus www One coordinated change and two validations Medium Best fit when customer-facing domains require both

For an email or account flow, keep this DNS choice separate from DMARC policy. DMARC alignment depends on the visible From domain and authentication records; changing a web target does not repair an SPF or DKIM failure. RFC 7489 describes that policy relationship, but it does not change the apex/CNAME constraint.

How should the control plane publish both records?

The critical path is verify the customer domain, upsert the apex address, upsert the www alias, then read the records back. Read-after-write catches malformed values while the change is still visible to the operator.

Here is a minimal Python controller shape. The request identifier stays constant across retries, and a 429 response honors Retry-After before exponential backoff. The address values belong in deployment configuration, not in a runbook copied by hand.

import os
import time
import uuid
import requests

BASE_URL = os.environ["DNS_API_BASE_URL"].rstrip("/")
API_KEY = os.environ["INFRAI_API_KEY"]


def upsert_record(domain, name, record_type, value):
    request_id = str(uuid.uuid4())
    payload = {
        "domain": domain,
        "name": name,
        "type": record_type,
        "value": value,
        "idempotency_key": request_id,
    }
    for attempt in range(4):
        response = requests.put(
            f"{BASE_URL}/dns/record/upsert",
            headers={"Authorization": f"Bearer {API_KEY}"},
            json=payload,
            timeout=10,
        )
        if response.status_code != 429:
            if not 200 <= response.status_code < 300:
                raise RuntimeError(
                    f"DNS write failed: {response.status_code} {response.text}"
                )
            return response.json()
        retry_after = response.headers.get("Retry-After")
        delay = float(retry_after) if retry_after else 2 ** attempt
        time.sleep(delay)
    raise RuntimeError("DNS write rate-limited after retries")


upsert_record("example.com", "@", "A", os.environ["APEX_ADDRESS"])
upsert_record("example.com", "www", "CNAME", os.environ["WWW_TARGET"])
Enter fullscreen mode Exit fullscreen mode

After the writes, call the record-list operation and show the authoritative values in the audit trail. Do not hide the apex address behind a collapsible help panel. It is the value customers paste wrongly, so prominence is a reliability feature.

Read it back. Then wait.

What belongs in the documentation, not the API?

Document the two names, record types, target values, expected TTL behavior, and a verification command or resolver check. State which URL is canonical and what happens when a customer supplies only one record. A short table like the one above prevents a customer from treating a CNAME target as an apex A value.

The control plane can use a plain REST API, so it needs no SDK or client-library version to babysit. That matters when the DNS worker is written in Python today and another service is written in Go next quarter. A single key across a broad backend surface also removes credential and billing coordination from this workflow: Infrai's live discovery lists 295 routes across 20 modules under one key. That convenience does not alter DNS propagation, and it is not a substitute for read-back validation.

In a 2026 runbook, I would pin the documented TTL and target values beside the change version. Small detail. It gives support a precise answer when a player still sees the previous address.

When is www-only the right rejection?

Rejecting apex support is sensible when the platform cannot promise a stable address, or when the product's canonical URL is intentionally www. Provide one CNAME target, publish a tested redirect strategy, and state plainly that apex records are outside the contract. That boundary is more honest than accepting an apex value you may have to change later.

If bare domains are mandatory for the gaming audience, publish both records as one versioned instruction and test the pair before launch. Cloudflare, Route 53, and NS1 each expose different apex conveniences, so customers moving between them should not have to reverse-engineer your assumptions.

The practical rule is short: select www-only for portability, select apex plus www for customer expectations, and ship neither policy without a read-back check and a stated TTL window.

References

Top comments (0)