这是典型问题，但本质上可以归结为“RFC 不允许这样做”。我认为这没什么帮助。我想知道到底是什么出了问题以及如何出问题？
假设有一个 DNS 服务器在顶点有一条 CNAME 记录。这会带来什么实际后果？除了“此行为不符合 RFC”之外，还应该有其他原因？
例如，一些邮件服务器可能看不到 MX 记录。好的，还有其他问题吗？
TLD 会删除该区域吗？这不是 RFC 要求他们做的事情，对吧？这意味着如果他们明确决定阻止这种“疾病”，他们就会这样做。但到目前为止，我的域名是有效的。显然有些 DNS 服务器允许在顶点使用 CNAME 记录（不是假设情况）。我的意思是真正的 CNAME 记录。而不是 Cloudflare 所做的。
这显然与标准相矛盾，为了安全起见，不应该这样做。另一方面，当 DNS 客户端收到顶级域的 CNAME 回复时，它会决定忽略该回复吗？我认为，有可能，但可能性不大（请参阅波斯特尔定律）。
至于区域传输（由 Håkan Lindqvist 建议），据我所知，它是一种用于将数据复制到辅助服务器的机制。但并非每个实现都使用它，它们可以出于安全原因被禁用（我希望它们大多数时候都被禁用）。并且如果注册商使用的实现（DNS 服务器）确实使用它们，则注册商不太可能在主/辅助服务器上使用不同的实现。尽管当注册商决定切换到其他实现时可能仍然会出现这种情况。
另一个问题是，通常您不能将 https 与此类别名一起使用。除非目标主机具有源域的证书。Cloudflare 之所以能做到这一点，是因为它代理了 http 请求（更准确地说，如果您告诉它代理请求，它就会起作用）。此外，只有区域所有者才能看到 CNAME 记录。世界其他地方看到的是指向 Cloudflare 服务器的 A 记录，因此这些服务器能够获得证书。
现在（考虑到最后一点）情况开始变得糟糕。但理论上还是有实际应用空间的（不需要邮件，目标服务器有证书）。
这正是我希望听到的。但是，我是否遗漏了什么？
有一次，我以为这可能是一条改变的道路。就像他们在 HTML5 中所做的那样（铺平牛路）。但考虑到限制，这似乎不太可能。
需要说明的是，我并不是在极力主张使用 CNAME。我只是认为“因为它破坏了这一点、这一点和这一点”比“因为它不被允许”更合理。
我觉得有趣的相关文章：
答案1
这不是真正可以说“什么坏了”的情况，而是概念上不可能按照要求去做。
因此，虽然“协议不允许”并不能解释为什么，它作为该问题的答案实际上是有一定意义的。
至于为什么：
添加CNAME记录定义了所有者名称（添加该记录的名称）是另一个名称的别名（正典名称记录CNAME指向的域名）。
作为别名的域名不能拥有自己的记录，因为这会与该名称是别名直接冲突。（明确地说，无论请求的记录类型如何，整个名称都是别名。）
区域顶点实际上并没有特别的行为，除了它总是需要有自己的记录。至少它必须有SOA和NS。这意味着使其成为别名（通过添加CNAME）在概念上是不可能的。
可以采用某种方式动态生成特定记录，而不是拥有记录，这是某些名称服务器实现所支持的CNAME。
这样做的好处是，在回答常规查询方面，它对 DNS 协议的影响很小，它只是特定名称服务器如何决定存在哪些记录以及它们具有哪些值的实现细节，但它确实导致在进行区域传输等方面的互操作性有限。
更好的是，如果此记录的预期用途是使用允许使用SRV/ 的某些协议SVCB，而不是依赖于直接引用主机名，则不需要基于CNAME的黑客攻击，就像通常用于“遗留”协议的黑客攻击一样（例如在使用SRV、SVCB等之前），例如典型的 Web 浏览器使用 HTTP/HTTPS。