为什么不能在域的顶点（即根）使用CNAME记录？

这是关于区域的根（或根）处的C​​NAME 的规范问题

相对常见的知识是，CNAME在域的最高端进行记录是一种禁忌做法。

例： example.com. IN CNAME ithurts.example.net.

在最佳情况下，名称服务器软件可能会拒绝加载配置，在最坏的情况下，它可能会接受此配置并使example.com的配置无效。

最近，我有一家虚拟主机公司将指令传递给业务部门，我们需要将其域名CNAME更改为新记录。我知道这是在给BIND喂食时会自杀的配置，所以我建议他们不能遵从，这通常是不明智的建议。该网站托管公司采取的立场是，标准定义的RFC并没有完全禁止它，并且其软件支持它。如果我们不能为顶点创建CNAME，则他们的建议是根本没有顶点记录，并且他们将不提供重定向的Web服务器。...什么？

我们大多数人都知道RFC1912坚持要求A CNAME record is not allowed to coexist with any other data.，但是在这里我们实话实说，RFC只是信息性的。我所知道的最禁止这种做法的说法是来自RFC1034：

如果节点上存在CNAME RR，则不应存在其他数据。这样可以确保规范名称及其别名的数据不能不同。

不幸的是，我从事该行业已经足够长的时间了，知道“不应该”和“必须不”是不一样的，对于大多数软件设计师来说，这足够了。知道除了与灌篮的简洁链接之外的任何事情都将浪费我的时间，我最终让该公司责无旁贷地推荐配置，这些配置可能会在没有适当披露的情况下破坏常用软件。

这使我们进入了问答环节。一次，我希望我们能真正了解顶点CNAME的精神错乱，而不是像有人在主题上发帖时通常那样，绕开这个问题。RFC1912超出了我的范围，我没有想到的其他适用于此的信息性RFC也是如此。让我们把这个婴儿关掉。

CNAME最初创建记录是为了允许将提供相同资源的多个名称别名为该资源的单个“规范名称”。随着基于名称的虚拟主机的出现，将它们用作IP地址别名的通用形式已变得司空见惯。不幸的是，大多数来自Web托管背景的人都希望CNAME记录表明DNS中的等效性，但这从来都不是故意的。顶点包含有明确记录类型不是在一个规范的主机资源（的标识使用NS，SOA），这离不开在最基本的层面打破了标准的别名。（特别是在区域削减方面）

不幸的是，最初的DNS标准是在标准管理机构意识到明确的语言对定义一致行为（RFC 2119）之前编写的。有必要创建RFC 2181来澄清措辞含糊的几种极端情况，并且更新后的用法更清楚地表明，在不违反标准的前提下，CNAME 不能使用a来实现顶点别名。

6.1。区域权限

在区域的NS记录中枚举了该区域的权威服务器，该记录连同该区域的授权开始（SOA）记录是每个区域中的强制性记录。 对于不在一个区域中的一个区域中的所有资源记录，这样的服务器是权威的。指示区域切割的NS记录是创建的子区域的属性，该子区域的原始记录或其子域的任何其他记录也是如此。某个区域的服务器不应返回与另一个区域中名称相关的查询的权威性答案，该查询包括一个区域切割处的NS记录（可能包括A记录），除非它也恰好是另一个区域的服务器。

这就证明SOA和NS记录是强制性的，但它说，无事A或其他类型的出现在这里。那时我引用这似乎是多余的，但是稍后它会变得更有意义。

RFC 1034对于当a CNAME与其他记录类型并存时可能出现的问题有些含糊。RFC 2181消除了歧义，并明确声明了允许与其并存的记录类型：

10.1。CNAME资源记录

存在DNS CNAME（“规范名称”）记录以提供与别名相关联的规范名称。任何一个别名都可能只有一个这样的规范名称。该名称通常应该是DNS中其他位置存在的名称，尽管对于别名带有在DNS中未定义的规范名称的一些罕见应用程序。 如果使用DNSSEC，则别名（CNAME记录的标签）可能具有SIG，NXT和KEY RR，但可能没有其他数据。 也就是说，对于DNS中的任何标签（任何域名），以下条件之一完全正确：

• 存在一条CNAME记录，并可选地随附SIG，NXT和KEY RR，
• 存在一个或多个记录，都不是CNAME记录，
• 该名称存在，但没有任何类型的关联RR，
• 该名称根本不存在。

在这种情况下，“别名”指的是CNAME记录的左侧。该项目符号列表使得它明确清楚的是SOA，NS和A记录不能在其中一个节点可以看出CNAME也会出现。当我们将其与第6.1节结合使用时，a不可能CNAME存在于顶点，因为它必须与强制性记录SOA和NS记录并存。

（这似乎可以完成工作，但是如果有人可以通过较短的途径证明，请对此加以说明。）

更新：

似乎最近的混乱来自Cloudflare最近的决定，该决定允许在域的顶点定义非法的CNAME记录，并为这些记录合成A记录。如链接文章所述，“符合RFC”指的是Cloudflare合成的记录可以很好地与DNS配合使用。这不会改变它是完全自定义行为的事实。

在我看来，这对更大的DNS社区不利：它实际上不是CNAME记录，它使人们误以为其他软件不足以允许它。（如我的问题所示）

Internet系统联盟最近在区域顶部发布了有关CNAME的文章，存在此限制的原因以及许多其他选择。不幸的是，这不太可能很快改变：

如果不同时更改世界上所有> DNS服务器的实现，我们就无法更改特殊CNAME记录的使用方式。这是因为其含义和解释是在DNS协议中严格定义的；当前所有的DNS客户端和服务器实现都遵守此规范。尝试“放松”在权威服务器中如何使用CNAME而不同时更改当前运行的所有DNS解析器将导致名称解析中断（并且Web和电子邮件服务对于实施“放松”的权威服务器解决方案的组织间歇性地不可用。

但是有希望：

当前正在讨论的另一种可能的解决方案是添加一个新的dns资源记录类型，浏览器将查找该类型，该类型可能存在于顶点。这将是HTTP请求的特定于应用程序的主机名（类似于MX的工作方式）。

优点：这与DNS设计完全一致。
缺点：这尚不可用，并且需要浏览器客户端更新。

如果要重定向整个区域，则应使用DNAME。根据RFC 6672，

DNAME RR和CNAME RR [RFC1034]导致查找以（可能）返回与不同于所查询域名的域名相对应的数据。两条资源记录之间的区别在于，CNAME RR将其所有者的数据查找定向到另一个单一名称，而DNAME RR将其所有者名称的后代的数据查找定向到一个不同的（单个）节点下的对应名称。那个树。

例如，浏览域名“ foo.example.com”的区域（请参阅RFC 1034 [RFC1034]，第4.3.2节，第3步），然后在“ example.com”中找到DNAME资源记录，指示将“ example.com”下的所有查询都定向到“ example.net”。查找过程将返回到步骤1，新的查询名称为“ foo.example.net”。如果查询名称为“ www.foo.example.com”，则新的查询名称将为“ www.foo.example.net”。