这是一个典型问题关于区域顶点（或根部）的 CNAME
众所周知，CNAME在域名的顶层进行记录是一种禁忌做法。
例子：
example.com. IN CNAME ithurts.example.net.
在最好的情况下，名称服务器软件可能会拒绝加载配置，而在最坏的情况下，它可能会接受该配置并使 example.com 的配置无效。
最近，一家网络托管公司向一个业务部门发出指示，要求我们将域名的顶点 CNAME 到一条新记录。我知道，如果将此配置提供给 BIND，那将是自杀式配置，因此我告诉他们，我们无法遵守，这通常是无稽之谈。网络托管公司的立场是，标准定义 RFC 并未完全禁止这样做，并且他们的软件支持它。如果我们无法 CNAME apex，他们的建议是根本不要有 apex 记录，他们不会提供重定向网络服务器。...什么？
我们大多数人都知道RFC1912坚持认为A CNAME record is not allowed to coexist with any other data.，但让我们诚实一点，RFC 只是信息性的。据我所知，最接近禁止这种做法的措辞来自RFC1034：
如果节点上存在 CNAME RR，则不应存在其他数据；这确保了规范名称和其别名的数据不会有所不同。
不幸的是，我在这个行业工作了很长时间，知道“不应该”并不等同于“必须不”，而这足以让大多数软件设计师自食恶果。我知道，除了简洁的扣篮链接之外，任何内容都是在浪费我的时间，我最终让公司逃脱了责骂，因为我推荐的配置可能会破坏常用软件，而没有适当的披露。
接下来是问答环节。这一次我希望我们真的关于顶点 CNAME 的疯狂的技术，而不是像我们通常在有人就该主题发表帖子时那样回避这个问题。RFC1912是禁止的，我没想到这里适用的任何其他信息性 RFC 也是如此。让我们关闭这个宝贝。
答案1
CNAME记录是起初创建名称别名是为了允许将提供相同资源的多个名称别名为该资源的单个“规范名称”。随着基于名称的虚拟托管的出现，将它们用作 IP 地址别名的通用形式已变得很普遍。不幸的是，大多数有网络托管背景的人都希望CNAME记录表明DNS 中的等价性，这从来都不是我们的本意。apex 包含的记录类型显然不是用于识别规范主机资源（NS，SOA），如果不从根本上打破标准，则无法对其进行别名化。（特别是关于区域切入）
不幸的是，最初的 DNS 标准是在标准管理机构意识到需要明确的措辞来定义一致的行为之前编写的（RFC 2119）有必要创造RFC 2181澄清由于措辞模糊而导致的几个极端情况，更新后的措辞更清楚地表明CNAME 不能用于实现顶点混叠而不破坏标准。
6.1. 区域权限
区域的权威服务器在该区域来源的 NS 记录中枚举，该记录与授权开始 (SOA) 记录一起是每个区域中的强制性记录。 此类服务器对某个区域中不属于其他区域的所有资源记录具有权威性。指示区域划分的 NS 记录是所创建子区域的属性，该子区域或其任何子域的来源的任何其他记录也是如此。某个区域的服务器不应返回与另一个区域中的名称相关的查询的权威性答案，该区域包括区域划分处的 NS 记录，也许还有 A 记录，除非它恰好也是其他区域的服务器。
这确立了SOA和NS记录是强制性的，但并未提及A此处出现的其他类型。我引用这段话可能显得多余，但稍后它会变得更加相关。
RFC 1034CNAME对于与其他记录类型共存时可能出现的问题有些模糊。RFC 2181消除了歧义并明确说明了允许与它们一起存在的记录类型：
10.1. CNAME 资源记录
DNS CNAME（“规范名称”）记录用于提供与别名关联的规范名称。每个别名只能有一个这样的规范名称。该名称通常应该是 DNS 中其他地方存在的名称，尽管在极少数情况下，别名的附带规范名称在 DNS 中未定义。 如果使用 DNSSEC，别名（CNAME 记录的标签）可能具有 SIG、NXT 和 KEY RR，但可能没有其他数据。 也就是说，对于 DNS 中的任何标签（任何域名），以下情况之一恰好为真：
- 存在一条 CNAME 记录，可选地附带 SIG、NXT 和 KEY RR，
- 存在一条或多条记录，但无一是 CNAME 记录，
- 该名称存在，但没有任何类型的关联 RR，
- 该名字根本不存在。
在此上下文中，“别名”是指记录的左侧CNAME。项目符号列表明确指出，在出现 a 的节点上看不到a SOA、NS和记录。当我们将其与第 6.1 节结合起来时， a 不可能存在于顶点，因为它必须与强制性和记录共存。ACNAMECNAMESOANS
（这似乎可以完成工作，但如果有人有更短的证明路径，请尝试一下。）
更新：
最近的混乱似乎来自于Cloudflare 最近的决定允许在域的顶点定义非法的 CNAME 记录，它们将为其合成 A 记录。链接文章中描述的“符合 RFC ”是指 Cloudflare 合成的记录将与 DNS 很好地配合。这并没有改变它是一种完全自定义的行为这一事实。
在我看来，这对更大的 DNS 社区来说是一种伤害：它实际上不是一个 CNAME 记录，并且它误导人们相信其他软件因为不允许这样做而存在缺陷。（正如我的问题所表明的那样）
答案2
2022 年 6 月更新
新SVCB记录和HTTPS资源记录启用顶级域的别名并简化与 HTTP 源等服务的连接查找。许多 DNS 提供商和浏览器已经支持它们，因此这似乎将成为规范最终确定的事实标准。
资源
- SVCB 和 HTTPS DNS 记录类型的用例和优势 （简要概述）
- SVCB（类型 65，服务绑定）RR 的用例是什么 （相关问题的出色回答）
- 通过 DNS（DNS SVCB 和 HTTPS RR）进行服务绑定和参数指定 （完整草稿）
互联网系统联盟最近发表了一篇关于区域顶点的 CNAME，为什么存在这种限制，以及许多替代方案。遗憾的是，这种情况不太可能很快改变：
我们不能在不同时更改世界上所有 DNS 服务器实现的情况下更改特殊 CNAME 记录的使用方式。这是因为其含义和解释在 DNS 协议中严格定义；所有当前 DNS 客户端和服务器实现都遵守此规范。如果尝试“放宽”权威服务器中 CNAME 的使用方式而不同时更改当前运行的所有 DNS 解析器，将导致名称解析中断（并且对于那些实施“放宽”权威服务器解决方案的组织来说，Web 和电子邮件服务将间歇性不可用）。
但仍存在希望：
目前正在讨论的另一种潜在解决方案是添加一种浏览器会查找的新的 DNS 资源记录类型，该记录类型可能存在于顶点。这将是一个特定于应用程序的 http 请求主机名（类似于 MX 的工作方式）。
优点：这与 DNS 设计完全一致。
缺点：目前尚不可用，需要更新浏览器客户端。
答案3
如果要重定向整个区域，则应使用 DNAME。根据RFC 6672，
DNAME RR 和 CNAME RR [RFC1034] 导致查询（可能）返回与查询域名不同的域名对应的数据。这两个资源记录之间的区别在于，CNAME RR 将其所有者处的数据查询指向另一个单个名称，而 DNAME RR 将其所有者名称的后代处的数据查询指向树的不同（单个）节点下的相应名称。
例如，通过区域（参见 RFC 1034 [RFC1034]，第 4.3.2 节，步骤 3）查找域名“foo.example.com”，并在“example.com”处找到 DNAME 资源记录，表明“example.com”下的所有查询都将定向到“example.net”。查找过程将返回到步骤 1，新查询名称为“foo.example.net”。如果查询名称为“www.foo.example.com”，则新查询名称将为“www.foo.example.net”。