"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 s

"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.