There is lots on the DNS already. For the security argument: Consider you run on `example.com` and at a later stage add `[blog|forum|support|...].example.com` suddenly cookies from `example.com` might leak to those Subdomains. If you put cookies on `www.example.com` they won't leak to those.
Sidenote: If leaking cookies to your own subdomains is a risk, one might also have other problems already. Point is: I explained the potential risk. Evaluating one has to do oneself
unless I am hosting separate sites/IPs on subdomains, or have a complex cookie situation, I think the www. prefix seems vestigial/legacy and completely unneeded. I am actually in the opposite camp of not including it at all and redirecting to non-www. it sounds awfully ambiguous in speech ("double-u double-u double-u dot", "all the double-us dot", "dub dub dub dot", etc.) and most times multiplies the syllabic length of a "catchy" address. I even had an older client who said "stop" instead of "dot", and another who used @www. in an email address. I also think it looks silly and unprofessional on business cards, on the side of vans, etc., especially when http:// and/or a trailing fowardslash is also included cringe. if it MUST exist, DNS does not always have to be involved, it could just be a simple http 301 forward or vhost config. we don't add :80 or :443 to the end of a web address. let the browser handle all that.
It's worth making it exist and doing a 301 redirect. There's some people that will still type it, and others that will link it without checking, and they'll just think your site is broken. You're fighting against the grain for what's essentially a couple lines of config.
It's not much different than using TLS for everything, but still handling and redirecting http:// traffic (also doing a 301 redirect).
It's also useful to set hsts for the whole domain.
I'm opinionated enough to say if you type http://example.org/foo, I'm just going to redirect that to https://www.example.org/ but reasonable people could disagree (especially since Chrome has been going back and forth on displaying the actual URL and something that's vaguely similar to it)
Now that Chrome is hiding the "www." it's going to look more and more legacy. I still use the "www." and probably will continue using, but for business cards and things like that I always use the bare domain.
It depends on your audience, but setting it up just so you don't cringe could well be alienating a bunch of your potential user base. Seems like a strange trade-off.
I think people here often forget that there's a mass of people out there who are nowhere near as technically literate and wouldn't have the faintest idea of what "DNS" stands for.
> Regarding cookies, the issue is that they are passed to subdomains so cookies that you set for `example.org` are also accessible from `*.example.org`.
This is only true for cookies that are not set as `HostOnly` as far as I'm aware.
The DNS server provide implements this differently, but the two "common" methods I know of is either aggressive caching or caching on request. In both cases the server becomes the client, breaks geoip, and create complexity where errors can easily slip in.
Re: "... only true for cookies that are not set as 'HostOnly'"
Technically, you're right -- but that implies a commitment to vigilance in setting that attribute on every instance of every cookie across every page or endpoint on your apex domain. Further, if you ever want to support some use of a subdomain, you have to deal with the ability of any page therein to set cookies on ".example.com". And when you inevitably miss any instance of any of these, you're unlikely to notice, because everything will still function normally. So in practice, using the apex paints you into a corner and makes the domain less useful.
There's also the issue of DDOS attacks and related problems, for which the fastest and simplest mitigation is updating DNS entries for your CNAME(s). Why take that option off the table?
The standard should be amended for the modern web then. AWS's (and I'm sure many other's) implementation of this for their various load balancing, CDN services, etc. are critical to the health of the web now.
From the DNS client's perspective, there is a positive and a negative.
Positive: since the server with an alias record actually returns an A/AAAA, a client doesn't have to contact any more servers to get the results.
Negative: the servers for the CNAME target may be faster, relevant if the name is used beyond the A/AAAA TTL but sooner than the TTL would be set for a CNAME); or the servers for the target may be providing much finer targeting than is possibly by proxying.
Noob question:
Lets say i am fine with all going to www. or other subdomains mainly because i like using cname to point to other server. I still need to set some Apex record no? if A is blank i dont have anything to do the redirect to www. or what i am missing? Thank you!
Yes, you still need an apex record with an actual IP address. And ideally something listening at that IP address that will redirect to the www address on both http and https.
