DNS Settings – Web Hosting Without a Subdomain (www)

cname-recorddomain-name-systemweb-hosting

I've been trying to find a more elegant solution to allow for better DNS updates for my webserver and the handful of websites that I host on it.

So you have a webserver for example at a VPS provider for example with the domain name apache1.vpshost.com. If I wanted my website that has a domain name www.example.com to be hosted on that webserver, I could simply put a CNAME record in that says www.example.com is apache1.vpshost.com. This has the advantage that if the ip address for the webserver changes, you only need to update that in one place, and all the websites hosted there will be good.

There is a growing movement to drop the www. from web addresses, but the only way I know of doing that is to set the root A record to be the same IP address as apache1.vpshost.com since you cannot make the root dns a CNAME. The major downside of doing this that I see is that if the ip address of the webserver changes, then you are stuck updating all of your dns settings on all the hosted web addresses.

I've tried googling for this multiple times, but if there is a better solution to this out there, I'm getting lost in the weeds since my search terms are very common.

Best Answer

There is currently no good solution for the "CNAME at apex" use case. It wouldn't have been a problem if web browsers did support DNS SRV records but they never did and never will

Various DNS providers offer various kludges called sometimes ANAME or APEXCNAME or ALIAS or whatever. The important point is that nothing is standard here. It will appear in some way on their UI/API, it can't be copied as is to another provider (if you change) and of course it doesn't appear at all on the DNS resolution side, as they will somehow (either dynamically when the requests come, or through some caches filled in advance) generate A and AAAA replies for the apex based on the configuration.

Technically it does involve having basically an authoritative nameserver also being a little recursive because at some points it does need to resolve the name you used in your "fake" CNAME to some IP address.

Which is why the future DNS records called SVCB or HTTPS will finally solve that. They are not fully standardized yet as the IETF RFC is still being written, but they already exist in the DNS with allocated resource record types, and various companies (Apple, Google, CloudFlare to name a few) are already using them.

Anyway, I recommend investing time only around this future foolproof standard solution (so finding DNS providers supporting them, and watching how/when browsers will use them, they "all" said they will do), and not invest time into current kludges as they are inferior, not standard, and bound to disappear in the apparition of the above new DNS records.

Related Topic