Querying every nameserver directly — this takes a few seconds.
Querying every nameserver directly — this takes a few seconds.
web.apex-cname
The zone apex must carry SOA and NS records, and a CNAME may not coexist with other records at the same name.
A CNAME says "this name is an alias for that one", and the rule in DNS is that a name with a CNAME may have no other records at all. The apex of a zone has to carry SOA and NS records by definition — that is what makes it the apex — so a genuine CNAME there is a contradiction the protocol does not permit.
The consequences of doing it anyway are not cosmetic. Depending on the server, either the CNAME wins and the delegation records are hidden, or they coexist and resolvers get inconsistent answers. Mail is a common casualty: a CNAME at the apex can suppress the MX lookup, so a domain that resolves for the web stops receiving mail.
The demand is real, though — people legitimately want example.com to follow a load balancer or CDN endpoint that changes address. Providers answer it with ALIAS, ANAME or "CNAME flattening": the provider resolves the target itself and serves ordinary A and AAAA records at the apex. That is a synthesis at the authoritative server, not a CNAME, and it is entirely correct.
If your DNS provider offers ALIAS, ANAME or CNAME flattening, use it. That is the supported answer and it behaves correctly for mail and for delegation.
If it does not, either move DNS to a provider that does, or point the apex at fixed A and AAAA records and accept that you now track changes at the target yourself.
Redirecting the apex to www at the HTTP layer is the other legitimate option, and often the simplest: an ordinary A record at the apex pointing at something small that answers with a 301.
Apex is not a CNAME is one of 49 checks in every report, alongside delegation, mail authentication, TLS and registration.