Score:0

What are practical outcomes of adding a CNAME record to an apex? What breaks?

cn flag

There's this canonical question, but it essentially comes down to "it's not allowed by the RFCs." I don't think that's helpful. What I'd like to know is what exactly breaks and how?

Let's say there's one DNS server with a CNAME record at an apex. What are the practical consequences of this? There must be something other than "this behavior doesn't conform to the RFCs"?

For example, some mail servers might not see the MX records. Okay, anything else?

TLD will drop the zone? That's not something the RFCs mandates them to do, right? Which means that they'll do this if they specifically decide to stop this sort of "disease." But so far my domain works. And apparently there are DNS servers that allow CNAME records at an apex (not a what-if situation). I mean real CNAME records. Not what e.g. Cloudflare does.

This clearly contradicts the standard, and one shouldn't do this to be on the safe side. On the other hand, when a DNS client receives a CNAME reply for an apex domain, will it decide to ignore the reply? I think, possible but unlikely (see the Postel's law).

As for zone transfers (suggested by Håkan Lindqvist), AFAICS it's a mechanism used to replicate data to secondary servers. But not every implementation uses it, they can be disabled for security reasons (and I'd expect them to be disabled most of the time). And if the implementation (of a DNS server) used by a registrar does use them, it's unlikely that the registrar will use different implementations on primary/secondary servers. Although there's probably still the case when a registrar decides to switch to some other implementation.

Another issue is that generally you can't use https with such aliases. Unless the target host has a certificate for the source domain. The reason Cloudflare gets away with this is: it proxies the http requests (to be more precise, it works if you tell it to proxy the requests). Moreover, only the zone owner sees the CNAME record. The rest of the world sees A records pointing to the Cloudflare servers, which are thus able to obtain a certificate.

And now (considering the last point) this starts looking bad. But theoretically there's some room for practical application (no need for mail and the target server has the certificate).

That's what I'd have liked to hear. Still, am I missing something?

At some point I thought that this might be a path for a change. Like they did in HTML5 (pave the cowpaths). But considering the limitations this doesn't seem very likely.

To make it clear I'm not arguing for CNAMEs at an apex. I just think that "because it breaks this, this and this" is a better reason than "because it's not allowed."

The relevant articles I find interesting:

cn flag
@Zac67 I gave this link myself, so apparently it doesn't.
Zac67 avatar
ru flag
It does, because CNAME doesn't coexist with any other record and SOA & NS are mandatory in the root. In other words, once you create a CNAME in the root you break the other records, subsequently breaking the root zone.
vidarlo avatar
ar flag
The accepted answer on that question literally spells out what breaks. If you believe it is not a duplicate, I would suggest a bounty on the linked question, where you explain what you're looking for in an answer.
cn flag
@vidarlo What the accepted answer there literally says is that it breaks the standard. But programs can't break standards. They can not conform to them. Now, what happens when a DNS server doesn't conform to the standard (it has a CNAME record at an apex)? There must be something that breaks. Like, a conforming client makes a request and receives an unexpected result or something?
cn flag
@Zac67 So conforming agents would ignore all the other records but CNAME? What happens next? E.g. I might be okay with not receiving mail. Is there anything else that breaks?
vidarlo avatar
ar flag
You don't anymore have a NS record. That's kinda... not expected. Basically you have a standard that says CNAME can't coexist with other records, yet for the apex other records are required.
Zac67 avatar
ru flag
@x-yuri Not only DNS clients, but TLD servers would likely also decide to drop that domain.
cn flag
@Zac67 I don't think so. And at least a couple of days my domain works. You might also want to check out my updated question.
cn flag
@vidarlo You might want to check out my updated question. Notifying you because I'm not sure if you'll notice the change otherwise.
jp flag
@Zac67 why would TLD care what is in someone's zone file? They have their glue records and that's all. They don't even care about lame delegation (on average 10-15% of all domains are lame).
Score:1
cn flag

This is not an example of a situation where one can really say "what breaks" so much as that it's conceptually not possible to do what is asked.
So while "it's not allowed by the protocol" doesn't explain why, it actually makes some sense as an answer to the question.

Regarding why:

Adding a CNAME record defines that the owner name (the name where that record is added) is an alias for a different name (the canonical name that the CNAME record points to).
A domain name that is an alias cannot have records of its own, as that would be in direct conflict with this name being an alias. (To be clear, the entire name is an alias, regardless of the requested record type.)

The zone apex is not actually special in terms of this behavior, other than it always needs to have records of its own. At the very least it must have SOA and NS. This means that making it an alias (by adding CNAME) is conceptually impossible.

What is possible, and is supported by some nameserver implementations, is some means of dynamically generating specific records instead of having a CNAME record.
That has the advantage that it has little DNS protocol impact in terms of answering regular queries, it's just an implementation detail of how that particular nameserver decides what records exist and what values they have, it does however results in limited interoperability in terms of being able to do zone transfers and such.

Better yet, if the intended use for this record is with some protocol that allows use of SRV/SVCB, rather than relying on directly referencing hostnames, that has no need for CNAME-based hacks, like what is often used for "legacy" protocols (as in predating the use of SRV, SVCB, etc) such as typical web browser use of HTTP/HTTPS.

cn flag
"Is not allowed" makes some sense, but there must be some practical outcome? I added a paragraph to the question. Maybe it will clarify my question. I might be wrong but there must be some practical consequences. because breaking an RFC at a fundamental level is no joke. Imagine what happens when a CNAME record is added to an apex at one DNS server. What happens next? There must be some programs that start misbehaving? In what way? Will the alias work?
cn flag
I've rewritten my question. You might want to check it out.
Nikita Kipriyanov avatar
za flag
Nothing happens, a decent DNS server will refuse to load such a zone or/and refuse to accept the change if it was live. Why are you asking, try it. You can test it in pretty much confined environment, you don't need a public DNS to do the test. Just run a DNS server with two zones one of which is subdomain of other and have a delegation, and then try adding your CNAME. No sane person had this doing in their life however, because there is absolutely no practical value in knowing what exactly happens, so don't expect a sane answer.
Nikita Kipriyanov avatar
za flag
Moreover, this site is dedicated to *practical* problems, or, even if theoretical, they must have a practical importance. I am surprised even that someone tried to answer this question *again*. The topic of your question is too unreal for the plausible "what if" scenario. You'll never ever encounter this in real life, so there is no value to know "what if". This is off topic, no matter how you spell it.
cn flag
@NikitaKipriyanov This is a practical problem. I want to run a website on a GCP bucket. And then it suddenly appears that I can't use the root domain. Also, I want to know all the options, their pros and cons. And you probably missed the part about me having added a CNAME record at my registrar. You can call them decent or not, but they do exist. As for sanity, many sane people blamed SPA websites, and yet they're a commonplace these days. So don't give me that. Also I don't argue *for* using CNAMEs at an apex. "RFCs don't allow it" just doesn't cut it for me as an explanation.
jp flag
The assumption that if you have a CNAME then you lose NS records is correct in the theory. But in practice there are DNS server implementations which allow a CNAME in the apex and happily return all records, including NS even if there is a CNAME present in the apex, so it doesn't break the requirement to have NS and SOA in a zone. So this answer doesn't really answer the question what really breaks.
cn flag
@AlexD Fair enough, but then it's more of a "this is how my n favorite implementations react to the deliberately inconsistent data in these m different scenarios" type answer, which will probably never be comprehensive. However, if someone feels they have good such information they are of course free to post it. In terms of operating a reliable zone for production use, I consider the overall answer to be pretty clear: just don't do it. And then the "what actually breaks" is more of a curiosity, anyway.
jp flag
The OP didn't ask whether he should use CNAME with apex. His curiosity question "what actually breaks" is very good opportunity to learn inner working of DNS resolvers - how they process DNS responses in general and how they process incorrect DNS responses. I find myself asking whether a DNS resolver processes RR one by one or do they sanitize the entire answer first? Would a resolver reject all other RR when it encounters a CNAME RR? Would it drop associated cached records (esp glue records)? But, unfortunately this question is closed.
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.