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

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

번역이 없어 원문을 표시합니다. 원문

The standards-track answer to the apex problem now exists: RFC 9460 (2023) defines the SVCB and HTTPS resource records, and an `HTTPS` record in AliasMode (priority 0) is permitted at the zone apex, where a CNAME is not, so `example.com. HTTPS 0 www.example.com.` aliases the apex for clients that query the record. Chrome, Firefox and Safari query `HTTPS` records and use the ServiceMode parameters (`alpn` for HTTP/3, `ipv4hint`/`ipv6hint`, `ech` for Encrypted Client Hello), and Cloudflare publishes them for proxied hostnames; provider-side flattening, ALIAS and ANAME records remain the answer for every other resolver, and the A/AAAA records at the apex still have to exist for clients that do not ask. `dig example.com HTTPS` shows the record (`TYPE65` with an older `dig`). Route 53's alias records are the same idea implemented inside one provider, with the restriction that the target must be an AWS resource or a record in the same hosted zone.

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

번역이 없어 원문을 표시합니다. 원문

The cookie argument for `www` ('a site on `www` can keep them host-only, while a site on the apex tends to share cookies with `api.`, `static.` and any future subdomain') mixes up two directions and overstates the one that matters. A cookie set without `Domain` is host-only on the apex exactly as on `www`; the apex shares cookies only if the application sets `Domain=example.com`, which is a choice, not a consequence of the name. The direction that is a consequence of the name goes the other way: RFC 6265 permits any subdomain to set a cookie with `Domain=example.com`, and that cookie is sent to `www.example.com` and to the apex alike, so a compromised `blog.example.com` or a third-party service on `promo.example.com` can plant a session cookie into the canonical site whichever form it uses (the attack known as cookie tossing). Choosing `www` therefore protects nothing against siblings; the `__Host-` prefix does, on either name, because a `__Host-` cookie is accepted only without `Domain`, with `Secure` and `Path=/`, and a subdomain cannot set one for the parent. I would strike the cookie criterion from the choice and keep the two that hold: CNAME flexibility for `www`, and the `__Host-` prefix with host-only cookies as the rule regardless of the choice.