A standard CNAME cannot sit at the DNS zone apex because that name already has SOA and NS records. Use a provider's ALIAS, ANAME, or CNAME flattening when a CDN or application gives you a hostname rather than a stable IP. The public answer should be A or AAAA; the feature and its target restrictions depend on the DNS host.

An application platform may ask you to point example.com at edge.vendor.example. A conventional CNAME works for www.example.com, but the root name is different. RFC 1034 says a name with a CNAME must not have other data. A zone apex has SOA and NS even if you do not use email. A panel that rejects the record is enforcing the protocol, not being needlessly restrictive.
What the resolver sees after apex flattening
ALIAS and ANAME are provider features rather than standardized DNS record types that a public resolver must understand. The authoritative service resolves the configured target and answers the client's A or AAAA question with addresses. Cloudflare calls its version CNAME flattening. An empty dig example.com CNAME response is therefore compatible with a working website. Test the address types separately and inspect the authoritative answer before blaming propagation.
| Configuration | Client question | Public result | Main caveat |
|---|---|---|---|
Standard CNAME on www | www.example.com A | CNAME chain, then target address | The target must resolve. |
| ALIAS/ANAME at the apex | example.com A | Provider-generated A | Refresh behavior is provider-specific. |
| Flattening at the apex | example.com AAAA | AAAA when supported and available | IPv4 success does not prove IPv6 works. |
HTTP redirect to www | example.com A | Redirect host's address | The root still needs DNS and TLS. |
A redirect changes the URL shown by the browser. Flattening preserves the root hostname while following a changing target address. If you only need to forward visitors, a redirect is simpler. If an application must answer on the apex itself, pick the DNS feature the application and your authoritative host both support. See the record reference for the ordinary A, AAAA, MX, and CNAME rules.
Which of eight DNS hosts offers a documented route
This comparison uses vendor documentation reviewed on 13 November 2026. “Not documented here” does not mean an undocumented API or enterprise option cannot exist. It means there is not enough evidence to promise the feature to a reader planning a migration.
| DNS host | Documented apex route | Decision point |
|---|---|---|
| Cloudflare | Apex CNAME flattening on all plans | Proxied answers are Cloudflare addresses; DNS-only answers follow the target. A dangling target can produce NODATA. |
| Amazon Route 53 | Alias A/AAAA to supported AWS resources or eligible zone records | This is not an arbitrary external-hostname alias. An apex alias to an in-zone CNAME is not allowed. |
| Azure DNS | Alias record set to supported Azure resources | The integration is resource-linked; confirm the exact target service. |
| DNSimple | ALIAS to a hostname at the apex | The authoritative service resolves the target and serves A/AAAA; target failure matters. |
| Yandex Cloud DNS | ANAME alongside MX and TXT | Yandex warns against using ANAME for its CDN delivery hostnames because geographic selection can be wrong. |
| Selectel DNS hosting | UI guide excludes apex CNAME; API enum includes ALIAS | Public UI and API docs differ. Confirm ALIAS availability for your zone before moving nameservers. |
| REG.RU | A at the root and CNAME for www in the reviewed guide | That guide does not establish ALIAS/ANAME support; ask the host if the target IP changes. |
| DigitalOcean DNS | A with @ for the apex in the reviewed guide | CNAME is described for subdomains; general apex ALIAS support is not documented there. |
Cloudflare and DNSimple address the arbitrary hostname case most directly in their published instructions. Route 53 and Azure DNS are strong when the destination is one of their supported resources. Yandex Cloud DNS offers ANAME, with an explicit CDN caveat. Check the target requirement before changing your NS delegation: mail, verification TXT, CAA, and DNSSEC can fail even when the website's A answer looks correct. The dig command guide shows how to compare parent and child NS.

Verify the authoritative answer before cutover
Query each authoritative nameserver for A and AAAA. Then ask at least two independent recursive resolvers. Differences between authoritative servers point to zone publication or delegation; differences confined to recursive answers may be cached responses. A synthesized address has its own TTL and refresh behavior, so do not assume it changes at the same instant as the target. The TTL guide and DNS propagation guide cover those timing layers.
dig +short NS example.com
dig @ns1.example.net example.com A +norecurse +noall +comments +answer
dig @ns1.example.net example.com AAAA +norecurse +noall +comments +answer
dig @1.1.1.1 example.com A +noall +comments +answer
dig @8.8.8.8 example.com A +noall +comments +answer
dig example.com MX +short
dig example.com TXT +short
Replace the example names with your actual domain and authoritative NS. Compare the target's A/AAAA with the apex response, but remember that a proxy may intentionally return its own edge IPs. Use the enterno DNS tool as a quick public-view check, followed by direct authoritative queries for the source of truth.
A control observation, and its limit
On 13 November 2026, we queried the authoritative server for enterno.io. It returned an A address and an MX record on the apex, with NOERROR and zero CNAME answers. This is an ordinary A setup, not a live proof of ALIAS or flattening on enterno.io. It demonstrates the narrower diagnostic point: a missing CNAME answer does not identify the website's DNS configuration or availability.
$ dig @dns1.yandex.net enterno.io A +norecurse +noall +answer
enterno.io. 3600 IN A 81.163.20.249
$ dig @dns1.yandex.net enterno.io MX +norecurse +noall +answer
enterno.io. 3600 IN MX 1 smtp.google.com.
$ dig @dns1.yandex.net enterno.io CNAME +norecurse +noall +comments +answer
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr aa; QUERY: 1, ANSWER: 0
If the apex A/AAAA is right but the site still fails, test the web endpoint and certificate independently. Follow the DNS failure route rather than changing records that already answer correctly.
How we made this
We compared eight vendors' official documentation on 13 November 2026 and recorded Google US and Moscow Yandex results with SerpAPI. Yandex Wordstat region 225 returned an empty object for the exact Russian head term, so we do not claim it has zero searches. The direct dig queries and their exit codes are archived with the draft. We did not provision zones in all eight accounts; the matrix describes documented capabilities and limits, while the command output is a separate public DNS observation.
Frequently asked questions
Can I put a CNAME at @ if I do not use email?
No. SOA and NS still exist at the zone apex. Use a provider-supported apex mechanism or addresses.
Why is dig example.com CNAME empty?
ALIAS, ANAME, and flattening can expose A/AAAA to public resolvers. Query those types and inspect the provider's configuration separately.
Can a Route 53 alias point to any external hostname?
No. Route 53 alias targets have documented resource and record-type restrictions. Check the exact destination before choosing it.
Should I copy the current CDN IP into an A record?
Only if the CDN explicitly assigns a stable address for that purpose. A DNS lookup reveals a current answer, not a promise that the address will stay fixed.