4 ms·

If only we had something other than the subdomain to indicate what protocol we want to use to access the host in question. Like maybe some kind of... port numb

by jgowdy 8y ago

If only we had something other than the subdomain to indicate what protocol we want to use to access the host in question. Like maybe some kind of... port number and/or protocol prefix. "www." is useless. Eliminating it wouldn't be a bad thing. "m." for mobile sites is extremely archaic. Sites should work on mobile without special subdomains. If you issue subdomains to strangers on your root domain, the URL bar showing the subdomain shouldn't be your "security model." The root domain is the root authority behind the site in question. Chrome showing users that information in a clear and concise way isn't "subverting the domain name system". Safari has been doing this for a long time, and Chrome/Chromium have settings/flags that allow you to turn this behavior off. The amount of crying over this change is ridiculous in my opinion. As long as they keep this configurable (in fact, they should add a UI config for it) I see no problem here.

furi 8y ago
"www." is useless until you have multiple servers. Say you run a game server and a website on a web server for that game server as well. You need to give them separate domains so that they can resolve to separate IP addresses i.e. "www.example.com" might resolve to <web server IP> and "example.com" might resolve to <game server IP>. This is far more robust, faster and simpler (and how the system was intended to be used) than trying to set up some kind of proxying system on one of the servers to handle traffic really intended for the other one. In real world usage of course you'd probably put the game server at "game.example.com" and the web server at "example.com" but either way you end up with a subdomain, the arrangement with "www." as the subdomain instead of "game." is not really any more useless. I believe this can possibly be worked around with SRV records but then you have to rely on whatever your client might be handling SRV records. > If you issue subdomains to strangers on your root domain, the URL bar showing the subdomain shouldn't be your "security model." What do you propose instead? Azure gives me custom subdomains for my servers that are immensely useful, being much more regular and memorable than IP addresses. I only see two solutions here: stop doing that or let anybody with access to subdomain creation pretend to be "azure.com". One of them is comically dangerous and the other is throwing out a perfectly good feature to save a handful of characters in the URL bar.

by jgowdy 8y ago

furi 8y ago

"www." is useless until you have multiple servers. Say you run a game server and a website on a web server for that game server as well. You need to give them separate domains so that they can resolve to separate IP addresses i.e. "www.example.com" might resolve to <web server IP> and "example.com" might resolve to <game server IP>. This is far more robust, faster and simpler (and how the system was intended to be used) than trying to set up some kind of proxying system on one of the servers to handle traffic really intended for the other one. In real world usage of course you'd probably put the game server at "game.example.com" and the web server at "example.com" but either way you end up with a subdomain, the arrangement with "www." as the subdomain instead of "game." is not really any more useless. I believe this can possibly be worked around with SRV records but then you have to rely on whatever your client might be handling SRV records. > If you issue subdomains to strangers on your root domain, the URL bar showing the subdomain shouldn't be your "security model." What do you propose instead? Azure gives me custom subdomains for my servers that are immensely useful, being much more regular and memorable than IP addresses. I only see two solutions here: stop doing that or let anybody with access to subdomain creation pretend to be "azure.com". One of them is comically dangerous and the other is throwing out a perfectly good feature to save a handful of characters in the URL bar.