这是关于区域顶点（或根）的CNAME的典型问题
CNAMElogging在域顶是比较常见的知识，是禁忌的做法。
例如： example.com. IN CNAME ithurts.example.net. example.com. IN CNAME ithurts.example.net.
在最好的情况下，名称服务器软件可能会拒绝加载configuration，最坏的情况是它可能会接受此configuration，并使example.com的configuration无效。
最近，我有一个网站托pipe公司向业务部门传递指令，我们需要将CNAME域名的顶点logging到一个新的logging。 知道这将是一个自杀的configuration时，给了BIND，我build议他们，我们将无法遵守，这是一般的bunkbuild议。 这个虚拟主机公司采取的立场是，它并没有被标准的定义RFC所彻底禁止，而且他们的软件也支持它。 如果我们不能CNAME顶点，他们的build议是根本没有顶点logging，他们不会提供一个redirect的networking服务器。 …什么？
我们大多数人都知道， RFC1912坚持认为A CNAME record is not allowed to coexist with any other data. ，但是让我们在这里诚实地对待自己，RFC是唯一的信息。 我知道最接近于禁止这种做法的措词是从RFC1034 ：
如果CNAME RR存在于一个节点上，则不应该存在其他数据。 这确保了规范名称和别名的数据不能不同。
不幸的是，我在这个行业已经有足够长的时间来知道“不应该”和“不可以”是不一样的，这对大多数软件devise人员来说是足够的了。 知道任何缺乏简洁的链接来扣篮都会浪费我的时间，我最终让公司放弃了推荐configuration，可能打破常用软件没有适当的披露。
这带来了我们的问答。 有一次，我想让我们真正地掌握关于顶点CNAME的疯狂的技术，而不是像我们通常在有人发表主题时那样避开这个问题。 RFC1912是不受限制的，正如其他任何其他适用的信息RFC，我没有想到。 让我们closures这个婴儿。
CNAMElogging最初创build的目的是允许多个名称提供相同的资源作为资源的单个“规范名称”。 随着基于名称的虚拟主机的出现，使用它们作为IP地址别名的通用forms已经变得司空见惯。 不幸的是，大多数来自networking托pipe背景的人都希望CNAMElogging能够在DNS中表示等同 ，这从来就不是意图。 顶点包含loggingtypes，明确地不用于标准主机资源（ NS ， SOA ）的标识，在不破坏基本级别的标准的情况下不能使用别名。 （特别是关于区域切割 ）
不幸的是，最初的DNS标准是在标准pipe理机构认识到需要明确的措辞来定义一致的行为（ RFC 2119 ）之前编写的。 由于含糊不清的措词，创buildRFC 2181来澄清几个angular落案例是必要的，并且更新的措词使得CNAME 不能用来实现顶点别名而不破坏标准。
6.1。 区域权威
一个区域的权威服务器在区域的起源的NSlogging中进行枚举，并与“权限的开始”（SOA）logging一起是每个区域中的强制logging。 这样的服务器对于区域中不在另一个区域中的所有资源logging具有权威性。 指示区域切割的NSlogging是所创build的子区域的属性，以及该子区域的来源的任何其他logging或其任何子域的logging。 一个区域的服务器不应该返回与另一个区域中的名称有关的查询的权威性答案，这个区域包括NS，也许还有A，logging在一个区域中，除非它恰好是另一个区域的服务器。
这确定了SOA和NSlogging是强制性的，但是没有提到A或其他types出现在这里。 那么我引用这个看起来似乎是多余的，但是一会儿就会变得更加相关。
RFC 1034对CNAME与其他loggingtypes并存时可能出现的问题有些模糊。 RFC 2181消除了歧义，并明确指出允许存在的loggingtypes：
10.1。 CNAME资源logging
存在DNS CNAME（“规范名称”）logging以提供与别名相关联的规范名称。 任何一个别名可能只有一个这样的规范名称。 该名称通常应该是DNS中其他位置存在的名称，尽pipe在DNS中未定义相应的规范名称的别名有一些罕见的应用程序。 如果DNSSEC正在使用，别名（CNAMElogging的标签）可能具有SIG，NXT和KEY RR，但可能没有其他数据。 也就是说，对于DNS（任何域名）中的任何标签，下列情况中的一个是正确的：
+ one CNAME record exists, optionally accompanied by SIG, NXT, and KEY RRs, + one or more records exist, none being CNAME records, + the name exists, but has no associated RRs of any type, + the name does not exist at all.
此上下文中的“别名”是指CNAMElogging的左侧。 项目符号列表清楚地表明，在出现CNAME的节点上不能看到SOA ， NS和Alogging。 当我们将它与6.1节结合起来， CNAME不可能存在于顶点，因为它必须与强制的SOA和NSlogging一起生存。
（这似乎是做这个工作，但如果有人有一个较短的pathcertificate，请给它一个裂缝。）
更新：
Cloudflare最近决定允许在域顶定义一个非法的CNAMElogging，为此他们将合成Alogging，这似乎是最近的混乱。 链接文章中描述的“RFC兼容”是指由Cloudflare合成的logging将与DNS良好地协作。 这并不改变这是一个完全自定义的行为。
在我看来，这对于更大的DNS社区是一种损害：它实际上不是CNAMElogging，它误导了人们认为其他软件不允许它。 （如我的问题所示）
如果你redirect整个区域，你应该使用DNAME。 根据RFC 6672 ，
DNAME RR和CNAME RR [RFC1034]引起查询（可能）返回与查询的域名不同的域名对应的数据。 两个资源logging之间的区别在于CNAME RR将其所有者上的数据查找引导到另一个单独的名称，而DNAME RR则将其所有者名称的后代中的数据的查找引导到不同（单个）节点下的对应名称那个树。
例如，查看域名“foo.example.com”的区域（请参阅RFC 1034 [RFC1034]，第4.3.2节，第3步），并在“example.com”处findDNAME资源logging“example.com”下的所有查询都将被定向到“example.net”。 查找过程将返回到步骤1，新的查询名称为“foo.example.net”。 如果查询名称为“www.foo.example.com”，则新的查询名称将是“www.foo.example.net”。