A hosting platform may ask you to point your domain to a hostname using a CNAME. That works for a name such as www.example.com, but a conventional CNAME at the domain root—the apex—conflicts with the zone’s required SOA and NS records. Provider features called ALIAS, ANAME, or CNAME flattening can meet this need by returning address answers. Their supported targets, caching policies and operational requirements differ.
This guide explains the apex restriction, how providers synthesize address answers, and how Cloudflare handles proxied and DNS-only records. It also covers TTLs, DNSSEC, email records, TLS and a practical migration sequence. Following a target’s changing IP addresses does not mean automatically adopting a different target hostname. The destination platform must separately support your custom domain and the chosen connection method.
Why a Standard CNAME Cannot Be Used at the Apex
A CNAME identifies a DNS name as an alias of another name. It cannot coexist with ordinary data at that same name; associated DNSSEC signature and denial records are specific exceptions. A zone apex must contain SOA and NS records, which are not covered by those exceptions. Putting a standard CNAME at example.com therefore conflicts with the records required to operate the example.com zone. Enabling DNSSEC does not remove that conflict.
For an ordinary www CNAME, a resolver can follow the alias to the requested address data. At the apex, the authoritative service must also provide the zone’s mandatory records. A provider that accepts an apex CNAME in its dashboard can instead synthesize the address response, rather than publish an ordinary apex CNAME answer. Distinguishing the configuration shown in the dashboard from the answer returned over DNS explains why the interface may appear to allow something the basic record rules prohibit.
Static hosting services, CDNs and SaaS platforms often supply a target hostname because the addresses behind that name can change. Copying one observed address into a permanent A record may bypass the platform’s supported setup. A hostname-based provider feature can reduce that manual work, but only if both the DNS service and destination support the arrangement. Check the destination’s instructions before replacing a documented A/AAAA setup with a different mechanism.
Choosing Between the Root Domain and www
Consider a hypothetical team moving a website from a single VPS to a CDN. The vendor supplies a target hostname, while the team wants the homepage at the root domain and needs existing email, blog and API records to remain intact. That introduces the apex CNAME conflict. The team must confirm custom-domain registration, apex support, ownership verification and TLS readiness before deciding which DNS feature to use.
Static site hosts, store builders and multi-region platforms may use hostname indirection to change endpoints. That does not mean every platform accepts an arbitrary apex hostname or a second proxy in front of it. Some require a specific record type or verification record. Follow the supported integration, preserve those validation records, and check whether the destination expects DNS-only traffic or permits a Cloudflare proxy.
Another option is to serve the site at www using a normal CNAME and redirect the root to www. The redirect requires an HTTP(S) service; DNS itself does not issue a 301. Both names need working TLS when accessed over HTTPS, including the name that only redirects. If the root is the preferred public address, use an apex method supported by the platform and make www redirect to it. Branding, platform support and operations all influence the choice.
ALIAS and ANAME: Provider Features with Different Limits
ALIAS and ANAME are names used for provider features, not a single interchangeable DNS mechanism. In a service that supports external targets, an operator supplies a hostname and the authoritative infrastructure resolves its address data. It then returns an A or AAAA answer for the apex, according to the available address family and implementation. This is a synthesized response; it need not mean that permanent A/AAAA records have been written into the stored zone configuration.
The provider’s resolver and cache determine how target changes reach later answers. Updates are not necessarily immediate, and there is no universal number of minutes for convergence. A recursive resolver receives the synthesized address answer without having to follow the hidden CNAME chain itself. The authoritative service still depends on that target chain: failed lookups, a missing target or unavailable address records can affect the result.
Compare supported targets, returned TTLs, cache refresh and lookup-error behavior before selecting a provider. DNSSEC support needs valid signatures for synthesized responses in a signed zone; it must be confirmed separately. Health checks are also product-specific. A provider feature that follows a hostname is not automatically a failover service, and lowering an answer TTL does not by itself cause the provider to fetch the target on every query.
Amazon Route 53 Alias supports specified AWS resources and suitable records within the same hosted zone; it does not accept any arbitrary external SaaS hostname. The linked Route 53 Alias behavior guide describes CloudFront as one supported use case. By comparison, DNSimple’s ALIAS record guide explains a feature that resolves a configured target hostname through provider infrastructure and caching. Treat these as different product contracts, even though both can produce address answers at a zone apex.
Cloudflare CNAME Flattening at the Apex
When Cloudflare is authoritative for the zone, an apex CNAME entered with the name @ is flattened by default on all plans. Cloudflare resolves the target as needed to produce the relevant address answer instead of returning an ordinary apex CNAME. There is no separate apex switch to enable. This answers the DNS record constraint; it does not create the destination’s custom-domain configuration, issue its certificate or turn on DNSSEC.
With a proxied record, the DNS response exposes Cloudflare anycast addresses and supported web traffic passes through Cloudflare. With a DNS-only flattened record, the response contains the target’s resolved address data. Available A/AAAA answers depend on the target and configuration. A proxied answer is therefore not expected to match the origin’s IP address. Seeing Cloudflare addresses also does not prove that the origin is undiscoverable or protected from direct access; origin controls are separate.
The Cloudflare CNAME Flattening documentation describes the resolution process and its limits. Flattening all non-apex CNAME records or selecting individual records is a separate, plan-dependent option. A verification service that expects the CNAME itself may fail when that record is flattened. Keep the apex web record distinct from ownership-verification records. Also check the SaaS integration and cross-account restrictions before assuming that a Cloudflare proxy is supported.
For long-lived traffic, the DNS answer is only the first step. If the application uses WebSockets or gRPC through Cloudflare, verify protocol support, origin access, timeouts and connection behavior. The guide to keep WebSockets and gRPC happy behind Cloudflare covers that layer. A correct flattened answer cannot prevent an origin timeout or make an unsupported traffic path work; inspect application logs and proxy behavior when connections fail after successful resolution.
A Hypothetical Storefront Migration
Suppose a storefront is moving from a regional virtual machine to a platform that supplies store.edge.example.net as its target. The desired public name is example.com. This is a planning example, not a reported deployment or performance result. Before changing production DNS, register the intended custom hostname with the platform, verify its apex and proxy requirements, and establish how the certificate will be validated and served.
First, test a temporary hostname such as stage.example.com using the vendor’s supported record. Check the site’s routes, headers, caching, TLS and origin behavior. Leave the live www hostname untouched during this test. A successful staging hostname does not prove that the apex is registered or that its certificate is ready. Prepare the intended root/www redirect, keeping URL paths mapped to their relevant destinations, and document the records that must be preserved.
Second, where the DNS service permits TTL changes, lower the relevant answer TTL in advance and allow the previous TTL to elapse before the cutover. Cloudflare proxied records use a fixed Auto TTL, so this advice cannot be applied to every record. The guide to automating DNS changes with Terraform and Cloudflare can support a reviewed change plan. Record the prior target and rollback steps, remembering that cached answers also affect how quickly a rollback becomes visible.
Finally, switch the apex to the supported ALIAS or flattened configuration once platform and TLS checks are complete. Monitor DNS answers, HTTPS responses, redirects, application errors and essential transactions. Keep the previous service available during the observation period when the migration design permits. Following the target’s changing addresses can reduce manual IP edits, but it does not establish uninterrupted service or remove the need for recovery procedures.
Address Answers, Caches and Upstream Dependencies
A useful way to understand synthesis is to separate the configured destination name from the answer returned to a resolver. The DNS provider looks up the destination and answers the apex query with address data. The resolver can cache that answer without following the destination’s CNAME chain itself. The provider still has to resolve the chain successfully, and its internal caching determines which data is available to generate the answer.
An answer’s TTL describes its downstream cache lifetime; the provider’s target-resolution refresh policy is a different part of the system. Neither a low configured TTL nor a high one alone establishes exactly when a provider rechecks an upstream name. For a DNS-only flattened answer, Cloudflare documents the lower of the external record’s TTL and the Cloudflare CNAME record’s TTL. Inspect actual returned TTLs and the provider’s documented behavior instead of treating the dashboard value as a universal refresh timer.
Flattening can save a recursive resolver from following a chain that is not already cached, but it does not remove upstream chain failures. A signed zone also needs a provider implementation that signs its synthesized answers correctly. That signature belongs to the answering zone’s DNSSEC chain; it is not the target’s chain simply copied to the apex. Nor does the signed answer alone describe whether the provider validated the upstream lookup.
TTL, Email, Failover and DNSSEC Checks
For Cloudflare proxied records, Auto TTL is 300 seconds and cannot be edited. That is a cache setting for the returned Cloudflare addresses, not a promise that every user sees a change in exactly five minutes. DNS-only records have configurable TTL options, and flattened responses need their actual returned values checked. For a planned change, reduce an editable TTL early enough for the older cached value to expire; consider target refresh and local caches separately.
Preserve email records during an apex web change. MX and SPF TXT may be at the apex, while DMARC is normally under _dmarc and DKIM uses selector names. The linked guide to automated SPF flattening to beat the 10‑lookup wall addresses a different mechanism: publishing a maintained set of sender authorizations instead of repeatedly following SPF mechanisms. SPF flattening is not CNAME flattening. If the flattened sender list becomes stale, legitimate senders may fail checks or old addresses may remain authorized.
A hostname-tracking record does not automatically provide health checks or failover. Confirm whether those functions belong to the target platform, a DNS load-balancing product or a separate application layer. An ALIAS may point to a hostname serving a load balancer where supported, but the balancer still needs reachable backends, meaningful checks and a recovery design. The linked guide to HAProxy load balancing and health checks discusses those components; no DNS method by itself guarantees zero downtime.
Do not assume DNSSEC is enabled because Cloudflare flattening works. Cloudflare’s documented setup explicitly enables signing and provides a DS record for the registrar/parent step. Verify the resulting delegation with a validating resolver, including the synthesized answer. A staging zone can help test a provider’s support but cannot establish the production parent DS chain. If changing authoritative providers, use a coordinated DNSSEC migration procedure rather than carrying an old DS value into an incompatible zone.
Using www Alongside the Apex
Serving the site at www can be a straightforward supported design: www uses the vendor’s ordinary CNAME, while an HTTP(S) endpoint at the apex returns a permanent redirect. Provision the apex certificate before relying on its HTTPS redirect, and ensure that the destination certificate covers www. The record alone does not supply a redirect service or register either custom hostname at the vendor. Test complete URLs, not just the homepage.
If the root is the chosen public name, confirm that the destination supports it and then use its recommended apex method. ALIAS/ANAME or Cloudflare flattening can meet the address-resolution requirement while preserving ordinary apex records. A provider-specific feature has to be considered alongside the SaaS integration, DNSSEC and monitoring. It is a useful routing component, not a substitute for the rest of the application setup.
Both names can be configured at the same platform when supported, with one redirecting to the selected canonical address. Keep TLS valid for each HTTPS name and avoid competing redirects between the application and CDN. This can make later address-policy changes easier to prepare. However, apex and www pointing at the same service are not independent failover paths; an outage of that shared service can affect both names.
Performance and the Limits of Flattening
Flattening may reduce lookup work for a recursive resolver when it would otherwise have to follow an uncached CNAME chain. It receives address data for the apex instead. When the target data is already cached, the difference may be smaller, and the authoritative provider’s own resolution work still exists. There is no guaranteed saved round trip for every query or universal improvement to page load time. Measure DNS and application behavior separately when evaluating a change.
Long or broken target chains remain an operational dependency even when the final answer looks simple. A missing target, timeout or unavailable address family can affect synthesized answers. For example, Cloudflare documents an empty address response when a flattened target has no A/AAAA data. Cache refresh and error behavior vary by provider. Do not interpret a dashboard record’s presence as proof that all links in its target chain remain usable.
HTTPS and SVCB records offer another form of service discovery for compatible clients. RFC 9460 defines AliasMode for service-specific aliasing, including at the apex, while leaving other record types unaffected. This does not relax the ordinary CNAME coexistence rule. Older clients may still need fallback A/AAAA records, and destination support matters. Treat these records as a separate deployment choice with compatibility checks, rather than an automatic replacement for the apex methods described here.
A Repeatable Setup and Verification Process
Begin with an inventory of existing apex, mail, validation and subdomain records. Prepare a temporary test hostname on the vendor and verify application behavior before scheduling production changes. If Cloudflare proxies the traffic, check supported protocols, origin access and long-lived connections. The guide to keep WebSockets and gRPC happy behind Cloudflare expands those checks. Record what each expected DNS answer means so the Cloudflare edge addresses are not mistaken for a wrong origin address during testing.
For an authoritative Cloudflare zone, enter the vendor-supported apex CNAME; apex flattening already applies by default. Select proxy status according to the SaaS integration and TLS design. Proxied answers expose Cloudflare addresses; DNS-only flattened answers use the target’s resolved address data. With another ALIAS/ANAME provider, confirm that the target is supported and inspect its TTL and DNSSEC requirements. Route 53 Alias must use its supported resource or same-zone targets.
If Terraform manages the zone, review the plan before applying it and keep unrelated records intact. Use separate, observable steps for preparatory TTL changes, the target switch and any later TTL adjustment. A pipeline can make those operations repeatable, but it cannot compress DNS cache lifetimes or prove the vendor has finished certificate provisioning. The linked guide to automating DNS changes with Terraform and Cloudflare is useful for structuring that workflow without assuming a single timed run guarantees a clean transition.
After the switch, compare authoritative and recursive DNS responses and test the apex and www over HTTPS. Inspect response status, relevant paths, redirect loops, certificate names and application errors from the regions that matter. Retain the old service according to the recovery plan. Restore an editable TTL after the chosen observation period, based on operational needs rather than a universal number of hours. Continue monitoring the target, including certificate renewal and platform changes.
SSL certificates, ACME and Platform Readiness
With a proxy, consider both the browser-to-edge TLS connection and the edge-to-origin connection. In DNS-only mode, the destination serves the certificate for the requested custom name. Neither arrangement is ready merely because DNS resolves. Check the platform’s hostname registration, ownership validation and certificate deployment. For ACME HTTP-01, challenge requests must reach the correct token; DNS-01 uses TXT validation. Diagnose the supported validation flow before changing proxy status, rather than disabling the proxy as a routine fix.
CAA is an optional issuance policy that can restrict which certificate authorities may issue for a name. If you publish CAA, check it against the platform’s actual issuers and renewal requirements; having an ALIAS does not replace that check. Certificate identity still needs to cover each hostname in use. The guide to serving Dual ECDSA + RSA certificates on Nginx and Apache discusses key-type compatibility, which is separate from name coverage and cannot fix an unregistered custom hostname or a certificate for the wrong domain.
A self-hosted design can place a load-balancing tier behind a supported hostname target. In that hypothetical arrangement, ALIAS/flattening handles address answers while the balancing layer manages backend selection and health checks. Availability depends on the balancer design, backend reachability, application state and recovery procedures. The linked guide to HAProxy load balancing and health checks provides related implementation detail; its topic should not be read as an unconditional outcome from adding an apex record.
Troubleshooting DNS, TLS and Redirects
If users see an old endpoint, first compare authoritative answers with those from recursive resolvers and the affected client. Look for the expected mode: Cloudflare edge addresses when proxied, resolved target addresses when DNS-only. Inspect returned TTLs, upstream target resolution, local overrides and caches. Matching expected DNS addresses is only one check; it does not prove that the custom hostname, TLS certificate or application is healthy.
Next, test the requested host at the application layer. Confirm the HTTP status, TLS name, origin routing and important pages. If a CDN or load balancer is involved, inspect its health checks and logs as well as the origin. For root/www problems, follow the redirect chain to find loops or an unexpected canonical destination. A failed redirect or regional backend can look like a DNS problem to a visitor even while the DNS answer itself is correct.
If mail or unrelated subdomains stop working after the change, compare the zone against the saved inventory. Check MX, SPF TXT, DKIM selectors and _dmarc separately; an SPF lookup limit is not a general DMARC limit. The guide to beating the SPF 10‑lookup wall with a living flattened record covers a maintained sender-policy approach. Do not deploy SPF flattening as a generic repair for an apex migration: first identify the changed record and ensure that any sender list continues to reflect current authorization.
What the Hostname-Based Approach Solves
Suppose a supported SaaS target keeps the same hostname but replaces its underlying addresses. A provider’s ALIAS or flattening feature can follow that change through its own resolution and caching process, reducing the need to copy IP addresses manually. This is an illustrative behavior, not evidence of a completed migration or an outage avoided. If the vendor supplies a different target hostname, the configured value still needs an explicit update.
The useful operational boundary is clear: the DNS provider produces an answer, the platform accepts the requested custom hostname, and the HTTP/TLS layers deliver the site. Monitoring should cover all three. Following target addresses can reduce one maintenance burden while retaining dependencies on the DNS service and target chain. Document the supported setup so later changes preserve mail records, validation requirements and the chosen public address.
Selecting and Operating an Apex Configuration
A conventional CNAME cannot coexist with the apex SOA and NS records. ALIAS/ANAME and Cloudflare CNAME flattening can provide address answers through supported provider features, while Route 53 Alias has its own target restrictions. The dashboard label does not define every provider’s behavior. Confirm target support, returned addresses, caching, error handling and DNSSEC before treating two products as equivalent.
For a practical rollout, decide the canonical root/www address, prepare the vendor hostname and TLS, preserve unrelated records, and test on a temporary name. Plan editable TTL changes in advance, switch the supported apex configuration, then verify DNS and HTTP behavior together. Maintain a rollback plan and monitor the target after launch. The guide to turning DNS changes into quietly predictable Terraform runs can help document and review changes, but automation does not eliminate caching or service dependencies.
The result to aim for is a supported, observable configuration with clear responsibilities. DNS synthesis handles the apex address requirement; redirects, certificate coverage, mail records and application health remain part of the deployment. Choose the simplest supported method for the platform and verify its behavior before and after the change.
