www versus apex domain: the CNAME restriction, cookie scope and which one to redirect to

What it is

example.com (the apex or root of the zone) and www.example.com are two hostnames that usually serve the same site. RFC 1034 states that if a CNAME record is present at a node, no other data should be present there. The apex always holds the zone's SOA and NS records, so it cannot be an alias; it needs literal A and AAAA records. www is an ordinary name and can be a CNAME to a hosting provider's target, which lets the provider change addresses without the customer editing DNS. Some DNS providers offer a workaround at the apex: Cloudflare's CNAME flattening resolves the alias itself and returns the final IP address instead of a CNAME record; its documentation notes that a target without A/AAAA records yields an empty answer, and that flattening can break services that verify ownership by reading the CNAME.

Cookies are the second difference. RFC 6265 says that a cookie set without a Domain attribute is returned only to the origin server; a cookie set with Domain=example.com is sent to every subdomain. A site served on the apex therefore tends to share cookies with api., static. and any future subdomain, while a site on www can keep them host-only.

Why it matters

The choice affects hosting flexibility (CNAME or not), cookie exposure to subdomains, certificate coverage and every link ever published. It is cheap to decide once and expensive to change.

How to apply

• Choose the canonical form. www when the site is hosted on a provider that moves addresses or when other subdomains must not see the site's cookies; the apex when short URLs matter and the DNS provider offers flattening or stable addresses.
• Put both names in the certificate and serve both over HTTPS; redirect the non-canonical name to the canonical one with a permanent status, preserving path and query.
• Keep AAAA and A consistent on both names; a www CNAME inherits the target's records, the apex must be maintained by hand.
• Set application cookies host-only unless subdomains need them, and use the __Host- prefix where the cookie article recommends it.
• Check dig example.com A, dig www.example.com CNAME, and the redirect in both directions after every DNS or hosting change.

Pitfalls

A CNAME placed at the apex by a permissive provider interface that silently drops MX or TXT records. HSTS includeSubDomains set on the apex before every subdomain serves HTTPS. Redirect loops when both names redirect to each other after a configuration split.