Join Log in
Score:1
going avatar Server

Domain registrar allows @ CNAME for root domain, is this reliable?

in flag
going

Due to a gap in my knowledge I set up a Windows VM on Azure then I went to Namecheap and registered a domain. Somewhere I got the idea to put in a CNAME record against @ and the FQDN and it works.

In my name records there are literally 2 entries @ and www for CNAME against the Azure VM FQDN. Everything works sweetly.

Yesterday, the guy I'm doing work for went to switch over the name servers on the planned domain which was not at Namecheap (I was using a dummy domain I registered at Namecheap) and couldn't do what I did, and we spent a few hours looking into it.

Today, I used a tool to look up the site and it appears that Namecheap uses the domain I provided to lookup the IP address and enters an A record against that IP, but it doesn't appear on the management page. So it's done in the background. Yesterday I reset the VM and the IP changed and the domain was back up in a couple of minutes.

How normal is this? How stable is this? I don't have a dedicated IP on Azure.

I now understand that @ on non-www domain is not normal (i.e. can't typically place @ against a CNAME record). But are there reputable domain hosts that are providing this service for free? Is it something I can search for? (Secondary problem is Namecheap is currently not willing to take on transfer of a this domain because apparently .com.au domains are tricky to transfer).

If this is rare, are my only options paying Azure for a static IP and using A records?

80
0 + 0
Score:2
avatar Server
gg flag
Stuggi

CNAMEs at the root aren't really supported by any standard, but some providers does it since it's quite handy. The problem, as you've noticed, is that since it's not a standardised solution, the implementations vary, like for example querying the name in the CNAME, resolving it and inserting the IP as an A-record.

I wouldn't recommend this practice, since there's actual reasons for why the root record needs to be an A or AAAA record.

The proper ways to handle this is either to pony up and pay for a static IP from Azure, or alternatively, if you were hosting a lot of these sites, is to get a single static IP for a load balancer/reverse proxy, and let it forward requests to your dynamic web applications.

Or, you could use Cloudflare, since they've actually managed to make an RFC-compliant CNAME at root implementation. https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/

0 + 0
Patrick Mevzek avatar
cn flag
Patrick Mevzek
The new standard will be `SVCB` and `HTTPS` records which will allow the same feature than CNAME but also at apex. They are already used by iOS and CloudFlare at least.
1
Reply
gg flag
Stuggi
Neat, I hadn't heard about that!
0
Reply
user160357 avatar
gb flag
user160357
Please explain why, this is not recommend?
0
Reply
gg flag
Stuggi
Technically, you could have a CNAME at the root, but according to the standard no other records with the same name can coexist with a CNAME, which makes it impossible to have a CNAME at the root since there are other records with the same name that must coexist with the root record. The Cloudflare blog post explains it quite well.
0
Reply
Score:-1
avatar Server
de flag
Error Messages

CNAME just means alias. Its just as reliable as A record only that multiple domains are using the same ip. However if the domain you are using a CNAME to expires or stops existing, then you will run into the same problem of finding where your domain points to.

A records:

domain1 ip

domain2 ip

is the same as :

domain1 ip

domain2 domain1

only that in the 2nd situation if domain 1 ip updates, so to does domain 2, but in the first one both domains need to be individually updated on ip changes.

0 + 0
Patrick Mevzek avatar
cn flag
Patrick Mevzek
You forgot about the specific use case of the apex and the rule that `CNAME` can NOT coexist with any other records, while apex already has other records (`NS` and `SOA` to start with). So your answer may be vaguely ok in general but not at all for apex.
0
Reply
de flag
Error Messages
It also depends on the DNS software/service used. Some will allow some won't However what i wanted to explain is that in general a CNAME or A record makes no difference irregardless of the domain level. This is because whether a subdomain or top level there are other things above it such as .com at the back, while www.domain.com can work and typically uses a CNAME it is considered a subdomain though. If a webserver has both domains it will make sense to CNAME the main domain of the server incase the A record gets updated if the NS is not the same which would help in cloudflare but isnt allowed
0
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
"It also depends on the DNS software/service used." No it doesn't. Of course you can publish whatever crap in your zone... that doesn't mean recursive nameserver will accept it. So even if you find a bogus nameserver allowing you to put a CNAME at apex (and for example bind would not), it does not mean it will work. Quite the contrary.
1
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
"That in general a CNAME or A record makes no difference irregardless of the domain level." In general maybe, at apex not. And the question was SPECIFICALLY about apex. So the answer should be about that first. You can extend in general after, but not answering the core point of apex makes your answer less relevant than others.
0
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
`CNAME` was useful 40 days ago when no tool existed for mass updates. Today, it is largely irrelevant and we can live without it. Any good provisioning software could generate all needed `A`/`AAAA` records without relying on CNAME.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.