Hacker News Reader

Comment by saagarjha | Hacker News Reader

I think for most common domains it’s far to late to make a distinction; we already lost http:// and now www is pretty much gone everywhere. I wonder if we’ll get rid of .com anytime soon.

While we’re on the topic, I wonder why some websites chose to redirect to www and some keep the apex domain as their homepage. I use the latter because it’s cleaner and, well, my domain is primarily used for my website, but I wonder if there is a technical reason behind choosing one or the other.

View on HN

Besides the security questions people have already talked about, there's a sizeable number of non-technical people for whom "www" signals "type this into a browser address bar", whereas the plain apex domain doesn't give that context because it's also in your email addresses, other subdomains etc.

I don't think many people get seriously confused by it, but accessibility is for everyone and it just makes it that much easier for people to know what to do.

One reason is that you "can't" CNAME your apex domain. So redirecting foo.com to www.foo.com might give you a little more deployment flexibility. The servers hosting the redirect don't need to be super beefy like your main site so just a A/AAAA might not lose you much.

Just a guess.

Of course, were WWW browsers like a lot of other softwares are, there would be a SRV lookup of the domain, plus the protocol and transport, and the deployment flexibility would be in that mechanism. (-:

* http://jdebp.uk./FGA/dns-srv-record-use-by-clients.html

Problems are more along the lines of conflicts with internal Active Directory deployment and "split horizon" DNS service.

* http://jdebp.uk./FGA/web-allowing-omission-of-www.html

* http://jdebp.uk./FGA/dns-split-horizon-common-server-names.h...

There should be no scare quotes around can’t. CNAMEs on the apex don’t exist because CNAMEs are not allowed to coexist with other record types, and you can’t have an apex without NS records or SOA records or whatever else it may be.

You can have a wacky DNS server that allows you to do weird things like ‘alias’ records, but those are sidestepping the DNS RFC: They’re answering with A records, but in a dynamic fashion.

If you use www.example.com and then add forum.example.com the probably external forum.example.com can't reach your cookies. If you put everything on example.com and then later add forum.example.com you have to think about security/privacy.

Whoa! I had no idea this had changed. It used to be that cookies for .example.com and example.com were different -- one was accessible by foo.example.com and the other wasn't. Seems RFC 6265 changed the behavior[0].

I assume the RFC explains the reasoning, but prima facie, this seems like a bad change to me.

[0] https://stackoverflow.com/posts/23086139/revisions

I would hope one would always more than think about security or privacy when implementing a public web site.

Thinking one can take care of every aspect of security or privacy when implementing a public website, especially one that publishes UGC, is similar to believing in ability to deliver bug-free software: very likely presumptuous. However, a good way of achieving reasonable security is by reducing the scope of things you have to think about in the first place, preferably by offloading them to trusted implementations someone else (e.g., browser vendors) took care of where possible. Scoping cookies to subdomains, for example, comes in very handy.

I think the point the GP is trying to make is that if one has thought about security and privacy then one is more likely to use www.example.com instead of example.com for one's website for this very reason.

The suggestion is that using basename.tld instead of www.basenamne.tld adds to the security matters you need to think about, if not now then later if/when you add features on a subdomain that you (and/or your users) want to keep separate in terms of cookie sharing.

In that sense using www.basename.tld is thinking about (or at least autonomicly mitigating, by way of scope limiting) those potential security/privacy issues.

> [..] and now www is pretty much gone everywhere.

I don't think this is true. There was a time about 15 years ago when everyone fancy went without www but the pendulum has swung back completely in the meantime. Most sites nowadays redirect to the www version. Twitter is the only page I am aware of which was no-www from the very beginning and stuck to it consistently until today.

Ah, that was poor wording on my part. What I meant was "users type in the apex domain and either stay there or get redirected to www", instead of "users still type www".

Got it, I'm certainly like that, I never type the dub dub dub.

Netscape Navigator used to automatically prefix "www" and suffix "com", and this carried through to Mozilla as "domain guessing". What you are describing is the state of the art regressing to that. (-:

I am waiting for Chrome to automatically “I’m feeling lucky” single word queries so we slide further into URL ambiguity…

No doubt directing to an AMP page, as well.

Using a CNAME is more resilient against DDoS attacks. Using apex introduces potential problems with subdomains and cookie "leakage".

it stems from the old ages when there was more than http to the internet and `www` it was simply the web server machine, and `ftp` would go to the ftp server ...

now everything is HTTPS (or tunneled over HTTPS) so it makes little sense to specify mundane things such as the machine you want to connect to and the protocol to use... there is only one machine (the apex domain) and only one protocol

Even if everything is HTTPS as you claim (spoiler, it is not, there's still plenty of other protocols in use today) subdomains are still relevant information used in SNI to serve virtualhosts.

There is no reason that imposes www.example.net to serve the same content as example.net. Whether or not it does is left to decide by the website operator.

You're right that it isn't everything, but the non-https stuff out there is super buggy. I had a Canon 5D Mark 4 and it had the option to (s)ftp up raws so I wouldn't have to take out the card. So I went to the trouble of setting up my own secure ftp server. Guess what. It didn't work. I tried everything from raw IP, to a naked domain, to a ftp domain, whatever it was there was absolutely no way of getting Canon to make the connection securely.

That's why everything is moving to HTTPS endpoints. It's simple. You just give a url and it works.

> (s)ftp

Technical point: FTPS is FTP with TLS, but SFTP is a completely different protocol based on SSH.

Specifically SFTP is a SSH subsystem, when your client connects to a SSH server it gets to specify what subsystem it intends to talk to, and so a remote SSH server can choose to offer the "traditional" shell service, an SFTP server, or any arbitrary thing. In this way SSH subsystems are rather like ALPN in TLS (except years earlier) which is how HTTP/2 works among other things.

The SFTP protocol itself, the thing spoken over SSH to the remote SFTP subsystem, is pretty simple, although I don't think it was ever formally standardised, https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13

You could in principle talk SFTP over some transport other than SSH (e.g. you could use ALPN to select it over TLS), but nobody does.

Reply on news.ycombinator.com