这是关于区域顶点（或根部）上的CNAME的规范问题。
相对常见的知识是，域顶部的
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也是如此。让我们关闭这个婴儿。
#1 楼
最初创建CNAME记录是为了允许将提供同一资源的多个名称别名为该资源的单个“规范名称”。随着基于名称的虚拟主机的出现，将它们用作IP地址别名的通用形式已变得司空见惯。不幸的是，大多数来自Web托管背景的人都希望CNAME记录表明DNS中的等效性，而这从来都不是故意的。顶点包含记录类型，这些记录类型显然不用于标识规范的主机资源（NS，SOA），如果不从根本上破坏标准，就不能对其进行别名。 （特别是在区域削减方面）不幸的是，原始DNS标准是在标准管理机构意识到定义定义的行为（RFC 2119）之前必须进行显式修饰之前编写的。有必要创建RFC 2181来澄清措辞含糊的几种极端情况，并且更新后的用法更清楚地表明，在不违反标准的前提下，无法使用
CNAME实现顶点别名。 > 6.1。区域权限NS记录中枚举了区域的权威服务器
，以指示区域的来源，该区域的服务器与“授权开始”（SOA）记录一起是每个区域中的强制性记录。对于不在一个区域中的区域中的所有资源记录，这样的服务器是权威的。指示区域切割的NS记录是创建的子区域的
属性，以及该子区域或其子域的所有
其他记录。用于
区域的服务器不应返回与另一个区域中的
名称相关的查询的权威答案，该区域中包括NS以及可能是A记录的区域剪切中的
，除非它也发生成为另一个
区域的服务器。
这样可以确定
SOA和NS记录是强制性的，但它并没有说明A或此处出现的其他类型。那时我引用这似乎是多余的，但是稍后它会变得更加重要。RFC 1034对于
CNAME与其他记录类型并存时可能出现的问题有些含糊。 RFC 2181消除了歧义，并明确声明了允许与它们并存的记录类型：10.1。 CNAME资源记录
存在DNS CNAME（“规范名称”）记录以提供与别名相关联的
规范名称。任何一个别名可能只有一个这样的规范名称。该名称通常应为
DNS中其他位置存在的名称，尽管在DNS中有一些罕见的
别名为标准名称
的应用程序。别名（CNAME记录的标签）可能
（如果正在使用DNSSEC）具有SIG，NXT和KEY RR，但可能没有其他数据。也就是说，对于DNS中的任何标签（任何域名）
，下列条件之一完全正确：
存在一个CNAME记录，并可选地包含SIG，NXT，和
KEY RR，
存在一个或多个记录，都不是CNAME记录，
该名称存在，但没有任何类型的关联RR，
该名称不存在全部。
在本文中，“别名”是指
CNAME记录的左侧。项目符号列表明确表明，在同时出现SOA的节点上看不到NS，A和CNAME记录。当我们将其与6.1节结合使用时，不可能在顶点处存在CNAME，因为它必须与必需的SOA和NS记录并存。（这似乎可以完成工作，但是如果有人有较短的举证途径，请加以说明。）
更新：
似乎Cloudflare最近的决定允许在域的顶点定义非法的CNAME记录，而他们将为此合成A记录，这引起了更多的混乱。如链接文章所述，“符合RFC”指的是Cloudflare合成的记录可以很好地与DNS配合使用。这不会改变它是完全自定义行为的事实。
我认为这对较大的DNS社区不利：它实际上不是CNAME记录，它使人们误以为其他软件不足以禁止它。 （如我的问题所示）
评论
我同意这种证明，并且我认为这两步证明的路径不是特别漫长或令人费解。 （1.保证区域顶点至少具有SOA + NS记录； 2。不允许CNAME记录与其他数据共存）
–Håkan Lindqvist
14年7月19日在11:19
总的来说，我认为这是一个很好的解释。如果可以添加任何内容，我认为这可能会进一步解释CNAME记录的实际含义，因为这可能是最被误解的记录类型。即使这超出了要点，我认为这是一个FAQ，这是许多（大多数？）对CNAME缺乏正确理解的直接结果。
–Håkan Lindqvist
14年7月19日在11:23
是的，这是非法的，但这有意义吗？为什么具有CNAME的域需要NS和SOA记录？如果可以，为什么不能拥有它们呢？
–丹尼斯·豪（Denis Howe）
2015年5月4日在21:18
@Denis无法在评论中全面回答。最简短的答案是，您需要阅读RFC（1034、1035）并充分了解什么是引用，引用所需的行为是什么（权限，SOA记录存在等）以及为什么使用这种类型的引用。 “无引用”别名在功能级别上违反了DNS服务器的许多期望。这只是开始。这个问题在这里不是一个好话题，因为它是推测性的，而不是根源于使用正确设计的，符合标准的DNS服务器时会遇到的问题。
–安德鲁（Andrew B）
2015年5月4日23:13
@Ekevoo有人可以说HTTP实现应该改为采用SRV，这也将使它成为非问题。问题不限于此处讨论的内容；与普遍的看法相反，CNAME并不是所需的最佳选择。最后，由于CNAME不能像人们期望的那样工作（！）并且不能进行追溯性重新设计，并且由于HTTP实现不使用SRV，因此“别名”样式功能似乎更可能迎合HTTP（记录）在后台实施的特定于类型的别名，而不是作为可见的记录类型）
–Håkan Lindqvist
2015年10月30日14:41
#2 楼
Internet系统联盟最近在区域的顶部发布了有关CNAME的文章，存在此限制的原因以及许多其他选择。不幸的是，这不可能很快改变：我们不能更改特殊CNAME记录的使用方式，而又不能同时更改世界上所有的> DNS服务器实现。这是因为其含义和解释是在DNS协议中严格定义的；当前所有的DNS客户端和服务器实现都遵守此规范。尝试“放松”在权威服务器中如何使用CNAME而不同时更改当前正在运行的所有DNS解析器将导致名称解析中断（Web和电子邮件服务对于那些实施“放松”权威服务器解决方案的组织间歇性地不可用。
，但有希望：
当前正在讨论的另一种可能的解决方案将添加一种新的dns资源记录类型，供浏览器查找，该类型可以在顶点出现，这将是一个应用程序。特定于HTTP请求的主机名（类似于MX的工作方式）。
缺点：尚不可用，并且需要浏览器客户端更新。
评论
“希望”？已经有一个“解决方案”，即HTTP SRV记录，但是这些记录被普遍拒绝。尚不清楚“问题”是什么。
–迈克尔·汉普顿
18/12/31在5:32
我什至不知道HTTP SRV，所以我不知道为什么它被拒绝。希望这种潜在的新解决方案无论何时/如果出现，都能获得更好的接收。
–丹尼尔（Daniel Liuzzi）
'18 / 12/31在16:23
#3 楼
如果要重定向整个区域，则应使用DNAME。根据RFC 6672，DNAME RR和CNAME RR [RFC1034]导致查找
（可能）返回对应于不同域名的数据
从查询的域名。两种
资源记录之间的区别在于，CNAME RR将在其所有者的
数据上查找到另一个单一名称，而DNAME RR在其所有者的后代的数据上直接查找
。将名称命名为树的不同（单个）节点下的相应名称。
例如，浏览区域（请参阅RFC 1034 [RFC1034]，
4.3节。 2，对于域名“ foo.example.com”执行第3步），并在“ example.com”上找到一个
DNAME资源记录，指示对“ example.com”下的所有
查询进行定向到“ example.net”。 lookup
进程将返回到步骤1，新的查询名称为
“ foo.example.net”。如果查询名称为“ www.foo.example.com”，
新查询名称将为“ www.foo.example.net”。
评论
这是一个错误的解释。请参阅RFC 6672§2.2中表格的第二行。顶点DNAME不会导致查询类型与顶点处DNAME以外的其他查询不匹配，即不会导致顶点A或AAAA记录的实际别名。
–安德鲁（Andrew B）
17 Mar 27 '17在17:17
顶点DNAME不会导致对顶点名称查询的重定向。说将导致不匹配，从技术上讲是不正确的。如果查询顶点名称实际存在的NS，SOA或任何其他RR类型，您仍然会得到匹配。从RFC 6672：“如果在区域顶点存在DNAME记录，则仍然需要在其中具有常规的SOA和NS资源记录。这样的DNAME无法用于完全镜像区域，因为它不能镜像区域顶点。”
– Quuxplusone
17年12月27日在21:16
评论
RFC 1034在时间和经验上确实比RFC 2119早。