DEV Community

BrennThorn8571
BrennThorn8571

Posted on

Why I Choose Apex Records in 2026: WWW Support and Coupling

#dns #apex #support

Short answer: I support both apex domains and www, but I treat them as different operational contracts. For a developer tool, www through a CNAME is the less coupled default; apex A or AAAA records are an explicit exception, accepted only when the platform can keep stable addresses, detect drift, document every required value, and prove rollback before activation. The deciding constraint is not hostname aesthetics. It is how reliably declared customer intent stays aligned with records actually published through DNS.

This is a capacity-planning problem wearing a documentation badge. Every additional record shape multiplies the states that onboarding, certificate issuance, health checks, incident response, and support must distinguish. I set an SLO for domain readiness and measure each transition instead of promising that DNS is "connected" after one lookup.

Should customer domains support apex records or WWW?

An apex A record places literal IPv4 addresses in the customer's zone; AAAA does the same for IPv6. A CNAME aliases one domain name to another, but DNS rules prohibit a CNAME from coexisting with other data at the same owner name. The zone apex already has SOA and NS data, so a conventional CNAME cannot sit there. That is why www.customer.example is easier to delegate, and why some DNS operators offer provider-specific apex aliasing.

The sharp edge is temporal. A dashboard can retain yesterday's intended A record while resolvers receive today's record, an old record, or no record, depending on caching and which authoritative server answered. An address change creates a coordinated migration across zones the platform does not control. A hostname target preserves indirection, letting the platform change target addresses without asking every customer to edit a zone.

No record type removes drift. A customer can delete a CNAME, leave a stale verification token, publish conflicting address families, or update only some authoritative servers. Negative answers may be cached too. The runbook needs separate observations for configuration intent, authoritative DNS, recursive DNS, certificate state, and application routing.

Five checks. One badge cannot explain them.

Mail-bearing domains need extra care during broad DNS edits. DMARC policy is published in DNS and can affect mail handling; web-domain instructions must never imply that replacing unrelated zone contents is harmless. Scope every instruction to named records.

Choose the contract before writing the setup page

I use this buy-versus-build table as a review gate. "Buy" means relying on a DNS operator's alias behavior, not endorsing a service. The table makes the team account for on-call load and coupling instead of hiding them in a friendly wizard.

Contract Customer publishes Main coupling Operational consequence
www alias CNAME to a platform hostname Target name stays valid Address migrations remain behind the alias
Apex addresses A and, when offered, AAAA Zone stores platform addresses Each address change needs customer migration
Apex operator alias Operator-specific alias Behavior depends on DNS operator Less address coupling, more portability risk
Redirected apex Apex reaches a redirect service Two hostname paths stay healthy Clear canonical host, another monitored hop

My default for developer tools is the first row, with apex support only when requirements justify it. The decision rule is concrete: if an address rotation cannot keep old and new addresses serving concurrently for at least the published TTL plus a safety margin, direct apex addresses fail change-readiness review. The margin belongs in the deployment plan; TTL influences caching but is not a delivery deadline.

There is no universal winner. Some customers require the bare domain, and www may need a redirect or an operator feature. Apex addresses avoid that dependency while transferring coordination risk to the platform and its customers. The limitation of www-only support is product-facing: the bare hostname cannot be the primary entry point unless another system redirects it. The limitation of direct apex records is operational: address ownership is split across many customer zones, so it is not suitable for a team that cannot maintain overlapping capacity during migrations. Operator-specific aliases trade that address coupling for control-plane portability and less uniform diagnostics. These are real trade-offs, not reasons to label one row the winner.

Implement a state machine, not a connected badge

Use explicit states: pending verification, verified, DNS mismatched, certificate pending, active, and rollback in progress. Transitions depend on observed evidence. Saving expected values in a form is not evidence that DNS serves them.

Documentation should show the exact owner, type, and value for each path; explain that a control panel may display the apex as @; state whether IPv6 is supported; and warn users not to delete MX, TXT, NS, or unrelated records. Separate www and apex instructions. Combining them encourages customers to publish both when they selected one contract.

This Go verifier asks a configured recursive resolver for A records and normalizes the result. Production verification should also query every authoritative server because one recursive view cannot reveal partial publication.

package main

import (
    "context"
    "fmt"
    "net"
    "sort"
    "time"
)

func normalizedA(ctx context.Context, resolver *net.Resolver, name string) ([]string, error) {
    lookupCtx, cancel := context.WithTimeout(ctx, 3*time.Second)
    defer cancel()
    addrs, err := resolver.LookupNetIP(lookupCtx, "ip4", name)
    if err != nil {
        return nil, fmt.Errorf("resolve %s: %w", name, err)
    }
    values := make([]string, 0, len(addrs))
    for _, addr := range addrs {
        values = append(values, addr.String())
    }
    sort.Strings(values)
    return values, nil
}
Enter fullscreen mode Exit fullscreen mode

Three seconds is an example lookup budget, not a DNS guarantee or recommended SLO. Set it from the verification job's latency budget, retries, resolver diversity, and zone scale. Polling every pending domain every few seconds creates query load; polling too slowly stretches activation. Back off unchanged states, add jitter, and prioritize planned migrations.

Store each observation with its timestamp, queried server, response code, record set, and remaining TTL when available. Keep customer-declared intent separately. Compare intended and authoritative sets, answers across all listed authorities, multiple recursive views, certificate names, and application route ownership.

Verify from the authority outward

Discover the zone's NS records, query each authoritative server for the precise hostname and supported types, and require agreement before advancing. Then query independent recursive resolvers. Only after DNS verification should certificate readiness and an application request using the customer hostname gate activation.

Start the domain-readiness SLO clock after authorities consistently publish a supported set; otherwise customer change time becomes platform unavailability. Measure pre-verification age separately, since unclear instructions can strand domains even while serving is healthy.

Metrics need low-cardinality state and reason labels such as mismatch, timeout, negative answer, authoritative disagreement, certificate pending, or route missing. Put literal hostnames in structured logs and traces, where support can search them without creating a time series for every customer.

During migration, publish new addresses first, prove they serve every mapped hostname, and retain old addresses while customers update. Then model the ugly middle explicitly: one authority can return only the old set, another only the new set, and a third a mixed set while recursive caches preserve earlier answers. All serving addresses must therefore accept the same hostname and route it to the same tenant before documentation tells anyone to change a record. Track the number of zones in old, mixed, and new states; alert on zones that stop progressing; and reserve enough address and certificate capacity for the whole overlap window plus rollback. Observe adoption through authoritative answers, not dashboard acknowledgments. Do not retire the old path merely because the nominal TTL elapsed: caches can have observations from different times, and a customer may never have completed the edit. A quiet support queue is not evidence that cached or low-traffic domains moved. The exit condition should be a reviewed record-set inventory with every remaining old address assigned an owner and disposition.

Silence proves nothing.

Roll back the serving change, not customer intent

For www pointing to a stable platform hostname, restore that target's prior addresses and routing while customer records remain untouched. With apex A or AAAA records, the platform cannot reverse customer-owned zones instantly, so both address generations must coexist through rollback. That is the price of address coupling.

Never rewrite declared customer intent after failed verification. Preserve it, mark the observed mismatch, and show the divergent records. If certificate or route deployment fails after DNS verifies, keep the domain out of active traffic and roll back the platform artifact; asking for DNS churn slows recovery and destroys evidence.

A game-day test should rotate a non-production target through old, mixed, new, and rolled-back states. Prove that authoritative disagreement blocks activation, recursive lag remains visible, both address generations serve during overlap, and rollback restores routing without a customer edit.

The final choice is conditional. Prefer www aliasing when reduced address coupling and simpler migrations matter most. Offer apex addresses when the bare hostname is mandatory and the team can fund overlapping capacity, drift detection, migration communication, and rollback time. Consider operator-specific apex aliasing only when its portability and diagnostic boundaries are acceptable. In 2026, an operable failure model still outranks hostname aesthetics.

References

Top comments (0)