6 ms·

If you're really old-school, you know that it makes sense to require the "www" prefix. Why should the machine pointed to by the bare domain be the web server, i

by cesarb 4y ago

If you're really old-school, you know that it makes sense to require the "www" prefix. Why should the machine pointed to by the bare domain be the web server, instead of for instance the FTP server or the Gopher server? It's not necessarily the same machine which provides all these protocols, and putting the web server there is privileging one protocol over another. Of course, that ship has long sailed; everyone uses HTTP now, even for things where it doesn't make sense, and one should at least have a tiny web server pointed to by the bare domain which redirects to the correct "www"-prefixed address. The fate of bare domains was sealed when browsers started prefixing "www." and suffixing ".com" whenever one typed a bare word in the address bar.

drexlspivey 4y ago
So what protocol should the bare domain point to in order to not privilege one protocol over the others? Or should it not resolve at all?
- cesarb 4y ago
  > Or should it not resolve at all? Exactly. To put it simply, in that old-school thinking, the bare domain should have only SOA and NS (these two being required for the domain to work), MX and SRV (these two being protocol-specific), things like TXT for SPF, and the DNSSEC stuff, but not A or AAAA or CNAME (and AFAIK using CNAME in a bare domain can cause problems, since it's not supposed to be used together with anything else, and a bare domain always has at least SOA and NS).
  - throwaway09223 4y ago
    This is inaccurate. There's never been a reason to not assign an A record to @. The historic structure of DNS is that names were given to systems within a domain. So you might have pikachu.company.com, squirtle.company.com, etc. It wouldn't make sense to just assign an address to the domain itself because we simply didn't have the technology to drive sophisticated consolidated sites on one system. You might need to get some files off one host, and some off another. We didn't have load balancers, and we often didn't have drive space to hold everything in one place. MX doesn't have this problem of scale, as MX specifies multiple systems per SMTP spec. Sometimes people would create www.pikachu.company.com, and sometimes they wouldn't. The www prefix was sometimes a handy default, but certainly wasn't ubiquitous. The real change here is the rise of single endpoints for a domain. This began by assigning "www" as place to look for web content for the entire domain and almost in unison people began to also add A records to the domain itself. After all, why wouldn't we? CNAME is different, of course, because CNAME aliases all record types - not just A records.
- throwaway09223 4y ago
  Domains do not point to protocols. They point to addresses, to systems. Any protocol can be used to talk to a system. They are all equal.
cperciva 4y ago
If you're opening a connection to TCP/80 it's a safe assumption that you want the web server. That said, I think it's a shame SRV hasn't been more widely adopted.
- cesarb 4y ago
  > If you're opening a connection to TCP/80 it's a safe assumption that you want the web server. Yes, and if you're opening a connection to TCP/21, it's a safe assumption that you want the FTP server. But what if these two are different machines, possibly even in separate and distant networks?
  - cperciva 4y ago
    There's nothing stopping your routers from looking at the TCP port number to decide which network/host to route packets to. ;-)
    - xxpor 4y ago
      What if we called these routers with L4 decision making "load balancers"? ;)
throwaway09223 4y ago
"it makes sense to require the "www" prefix." Not at all. It makes sense to allow it, but never makes sense to require it. "Why should the machine pointed to by the bare domain be the web server, instead of for instance the FTP server or the Gopher server?" We use ports to distinguish protocols. A more salient question is: Why should there only be one web server in a domain? In fact, it used to be common to have dozens of web servers on differently named hosts in a domain, all of which might be running several internet servers like http, ftp, etc. If you're actually old-school you'll remember knowing the names of individual machines at a site and visiting urls like http://foo.building.company.com http://foo.building.company.com There are some technical reasons why you might not want your web server's A record in the @ for a zone, but they mostly no longer apply. www has never, ever been required.
Mo3 4y ago
> instance the FTP server or the Gopher server? Lol, I see your point, but if a bank has an un-firewalled FTP or Gopher server on their domain there might be a couple of bigger issues to contemplate
sigg3 4y ago
I recall getting the "no-www" button for my weblog footer table.
t_mann 4y ago
> browsers started prefixing "www." and suffixing ".com" whenever one typed a bare word in the address bar Your browser does that? Mine opens a (hard to change) default search engine.
- MarkSweep 4y ago
  This does work if you press Control+Enter instead of just Enter.
- cesarb 4y ago
  Nowadays they do that, but in the past (think of the old Netscape and MSIE days) they used to just prefix "www." and suffix ".com"; there was no "default search engine" back then.
tsimionescu 4y ago
Actually, what makes sense is to put the most important server people may access from your systems at the shortest possible host name. If you're mainly doing FTP file hosting, it makes sense for your FTP server to be domain.net, while your less used web server can live at www.domain.net. Bonus, if you can, run your FTP and your HTTP servers on the same physical system, and allow the L4 port to determine which to talk to. Of course, it's even better if you can use an L4 load balancer, put that on the root domain, and tell it what internal machines to access based on port.
- jrockway 4y ago
  I always wanted user agents and DNS to do a little bit more coordination here. The user agent should ask the DNS server "how do I get to http for example.com", and then DNS should reply with an IP address and a port number (so if you can't bind 443, you don't have to). Additionally, these records should have extra information, perhaps related to location (so that the entire world has a consistent view of A records associated with the host, but can still find the CDN edge node closest to them), and health checking (so if you have 1.2.3.4, 1.2.3.5, and 1.2.3.6 as options, and 1.2.3.6 is being rebooted, the browser could test them all and use the one that is supposedly working). Oh, and maybe we could go totally crazy and add some information about authentication, so the user agent could get a token from its identity provider of choice and send that with the initial request (if the user's preferences allow it), and save engineers from ever having to implement sign up / sign in / account recovery / etc. As it stands now, we have conventions for port numbers, and load balancers / VIPs for mapping the address in the DNS response to an actual computer running the desired services. We could kill a lot of complexity by letting user agents do the work of the load balancer here. (The port number is a personal pet peeve of mine. I want to run HTTP/3 for my website, but my cloud provider's load balancer can't represent a configuration where port 443/TCP and port 443/UDP are both managed by the same load balancer. Interestingly, browsers are configured to do HTTP/3 with an Alt-Svc on an HTTP/2 or HTTP/1.1 response, which includes the port number. Chrome refuses to use anything other than port 443, while Firefox is happy with something like 30443. As a result, I have to reconfigure my network, or my cloud provider has to fix their bugs... and there is just no need. The browser could do this for me for free!)
andsoitis 4y ago
Make the common case easy and the other cases possible.

by cesarb 4y ago

drexlspivey 4y ago

So what protocol should the bare domain point to in order to not privilege one protocol over the others? Or should it not resolve at all?

cesarb 4y ago
> Or should it not resolve at all? Exactly. To put it simply, in that old-school thinking, the bare domain should have only SOA and NS (these two being required for the domain to work), MX and SRV (these two being protocol-specific), things like TXT for SPF, and the DNSSEC stuff, but not A or AAAA or CNAME (and AFAIK using CNAME in a bare domain can cause problems, since it's not supposed to be used together with anything else, and a bare domain always has at least SOA and NS).
- throwaway09223 4y ago
  This is inaccurate. There's never been a reason to not assign an A record to @. The historic structure of DNS is that names were given to systems within a domain. So you might have pikachu.company.com, squirtle.company.com, etc. It wouldn't make sense to just assign an address to the domain itself because we simply didn't have the technology to drive sophisticated consolidated sites on one system. You might need to get some files off one host, and some off another. We didn't have load balancers, and we often didn't have drive space to hold everything in one place. MX doesn't have this problem of scale, as MX specifies multiple systems per SMTP spec. Sometimes people would create www.pikachu.company.com, and sometimes they wouldn't. The www prefix was sometimes a handy default, but certainly wasn't ubiquitous. The real change here is the rise of single endpoints for a domain. This began by assigning "www" as place to look for web content for the entire domain and almost in unison people began to also add A records to the domain itself. After all, why wouldn't we? CNAME is different, of course, because CNAME aliases all record types - not just A records.
throwaway09223 4y ago
Domains do not point to protocols. They point to addresses, to systems. Any protocol can be used to talk to a system. They are all equal.

cperciva 4y ago

If you're opening a connection to TCP/80 it's a safe assumption that you want the web server. That said, I think it's a shame SRV hasn't been more widely adopted.

cesarb 4y ago
> If you're opening a connection to TCP/80 it's a safe assumption that you want the web server. Yes, and if you're opening a connection to TCP/21, it's a safe assumption that you want the FTP server. But what if these two are different machines, possibly even in separate and distant networks?
- cperciva 4y ago
  There's nothing stopping your routers from looking at the TCP port number to decide which network/host to route packets to. ;-)
  - xxpor 4y ago
    What if we called these routers with L4 decision making "load balancers"? ;)

throwaway09223 4y ago

"it makes sense to require the "www" prefix." Not at all. It makes sense to allow it, but never makes sense to require it. "Why should the machine pointed to by the bare domain be the web server, instead of for instance the FTP server or the Gopher server?" We use ports to distinguish protocols. A more salient question is: Why should there only be one web server in a domain? In fact, it used to be common to have dozens of web servers on differently named hosts in a domain, all of which might be running several internet servers like http, ftp, etc. If you're actually old-school you'll remember knowing the names of individual machines at a site and visiting urls like http://foo.building.company.com http://foo.building.company.com There are some technical reasons why you might not want your web server's A record in the @ for a zone, but they mostly no longer apply. www has never, ever been required.

Mo3 4y ago

> instance the FTP server or the Gopher server? Lol, I see your point, but if a bank has an un-firewalled FTP or Gopher server on their domain there might be a couple of bigger issues to contemplate

sigg3 4y ago

I recall getting the "no-www" button for my weblog footer table.

t_mann 4y ago

> browsers started prefixing "www." and suffixing ".com" whenever one typed a bare word in the address bar Your browser does that? Mine opens a (hard to change) default search engine.

MarkSweep 4y ago
This does work if you press Control+Enter instead of just Enter.
cesarb 4y ago
Nowadays they do that, but in the past (think of the old Netscape and MSIE days) they used to just prefix "www." and suffix ".com"; there was no "default search engine" back then.

tsimionescu 4y ago

Actually, what makes sense is to put the most important server people may access from your systems at the shortest possible host name. If you're mainly doing FTP file hosting, it makes sense for your FTP server to be domain.net, while your less used web server can live at www.domain.net. Bonus, if you can, run your FTP and your HTTP servers on the same physical system, and allow the L4 port to determine which to talk to. Of course, it's even better if you can use an L4 load balancer, put that on the root domain, and tell it what internal machines to access based on port.

jrockway 4y ago
I always wanted user agents and DNS to do a little bit more coordination here. The user agent should ask the DNS server "how do I get to http for example.com", and then DNS should reply with an IP address and a port number (so if you can't bind 443, you don't have to). Additionally, these records should have extra information, perhaps related to location (so that the entire world has a consistent view of A records associated with the host, but can still find the CDN edge node closest to them), and health checking (so if you have 1.2.3.4, 1.2.3.5, and 1.2.3.6 as options, and 1.2.3.6 is being rebooted, the browser could test them all and use the one that is supposedly working). Oh, and maybe we could go totally crazy and add some information about authentication, so the user agent could get a token from its identity provider of choice and send that with the initial request (if the user's preferences allow it), and save engineers from ever having to implement sign up / sign in / account recovery / etc. As it stands now, we have conventions for port numbers, and load balancers / VIPs for mapping the address in the DNS response to an actual computer running the desired services. We could kill a lot of complexity by letting user agents do the work of the load balancer here. (The port number is a personal pet peeve of mine. I want to run HTTP/3 for my website, but my cloud provider's load balancer can't represent a configuration where port 443/TCP and port 443/UDP are both managed by the same load balancer. Interestingly, browsers are configured to do HTTP/3 with an Alt-Svc on an HTTP/2 or HTTP/1.1 response, which includes the port number. Chrome refuses to use anything other than port 443, while Firefox is happy with something like 30443. As a result, I have to reconfigure my network, or my cloud provider has to fix their bugs... and there is just no need. The browser could do this for me for free!)

andsoitis 4y ago

Make the common case easy and the other cases possible.