0

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:

x-yuri
  • 2,526

1 Answers1

1

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.