Apex address records

The apex is the bare domain — example.com with nothing in front of it — and its A and AAAA records are what answer when somebody types that into a browser. This check reads them from the domain's own nameservers and classifies each address returned.

Having none is not automatically a fault. A domain used only for mail, one held for a brand, or one serving everything from www legitimately has nothing at the apex. It becomes a warning only when www resolves and the apex does not, because that combination means there is a working site and a share of visitors typing the shorter form get a DNS error instead of a redirect.

An address that is not publicly routable is a failure, and it is usually not a typo. RFC 1918 space or a reserved range at the apex of a public zone is the signature of an internal view being published externally: the record is unreachable for every visitor, and it tells anyone who asks how the network behind it is numbered.

If the apex should serve the site, publish A and AAAA records for it — or use your provider's ALIAS, ANAME or CNAME-flattening feature where the target is a CDN endpoint that changes address. A plain CNAME at the apex is not an option, and the apex-CNAME check in this report explains why.

If the apex should not serve the site, the tidy answer is still to publish something: an address record pointing at a small host that answers 301 to the canonical name. That is one redirect to maintain, and it removes the "the bare domain does not work" class of complaint entirely.

For a leaked private address, fix the source rather than the record. One zone file serving both an internal and an external audience will republish it the next time the internal side changes; splitting the views is what stops it.