题 为什么不能在域的顶点(也称为根)使用CNAME记录?


这是一个 典型问题 关于区域的顶点(或根)的CNAME

这是相对常见的知识 CNAME 域名顶点的记录是一种禁忌做法。

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

在最好的情况下,nameserver软件可能会拒绝加载配置,在最坏的情况下,它可能会接受此配置并使example.com的配置无效。

最近我有一个虚拟主机公司向业务部门发送指令,我们需要将我们域名的顶点命名为新记录。知道这对于BIND来说这将是一个自杀配置,我告诉他们我们无法遵守这一点,而这通常是双层建议。该网站主办公司采取的立场是,标准定义的RFC并不是完全禁止的  软件支持它。如果我们不能CNAME顶点,他们的建议是根本没有顶级记录,他们不会提供重定向的网络服务器。 ...什么?

我们大多数人都知道 RFC1912 坚持认为 A CNAME record is not allowed to coexist with any other data.但是,让我们在这里说实话,RFC只是信息。我所知道的最接近禁止这种做法的措辞来自于 RFC1034

如果节点上存在CNAME RR,则不应存在其他数据   当下;这确保了规范名称及其别名的数据   不可能是不同的。

不幸的是,我已经进入这个行业足够长的时间,知道“不应该”与“绝对不”相同,而且这对于大多数软件设计师来说都足够了。知道任何简短的扣篮都不会浪费我的时间,我最终让公司逃避责任,推荐可能在没有适当披露的情况下破坏常用软件的配置。

这将我们带到问答环节。曾经有一次我想让我们得到  关于顶级CNAME的疯狂的技术问题,而不是像我们通常在有人发表主题时所做的那样绕过这个问题。 RFC1912 是不受限制的,这里适用的任何其他信息RFC都是我没有想到的。让我们关闭这个宝贝。


107
2017-07-19 10:53




RFC 1034在很长一段时间和经验之前确实早于RFC 2119。 - Michael Hampton♦


答案:


CNAME 记录是 本来 创建允许将提供相同资源的多个名称别名为资源的单个“规范名称”。随着基于名称的虚拟主机的出现,将它们用作IP地址别名的通用形式变得司空见惯。不幸的是,大多数来自网络托管背景的人都希望如此 CNAME 记录表明 DNS中的等价物,这从来就不是故意的。顶点包含清楚的记录类型  用于识别规范主机资源(NSSOA),在不破坏基本标准的情况下不能混淆。 (特别是关于 区域削减

遗憾的是,最初的DNS标准是在标准管理机构认识到明确的措辞是定义一致行为所必需的之前编写的(RFC 2119)。有必要创造 RFC 2181 通过含糊的措辞来澄清几个角落案件,并且更新的措辞使得更清楚a CNAME  不能 用于在不违反标准的情况下实现顶点混叠。

6.1。区域权限

区域的权威服务器在NS记录中枚举      该区域的起源,以及一个权威的起源      (SOA)记录是每个区域中的强制记录。  这样的服务器      对于不在的区域中的所有资源记录具有权威性      另一个区域。表示区域切割的NS记录是      创建的子区域的属性,以及该区域的任何其他记录      该子区域的起源,或其任何子域。一个服务器      区域不应返回与相关查询的权威答案      另一个区域中的名称,包括NS,也许是A,记录      在区域切割,除非它恰好是另一个的服务器      区。

这证实了这一点 SOA 和 NS 记录是强制性的,但它没有说明 A 或其他类型出现在这里。我引用它可能看起来多余,但它会在一瞬间变得更加相关。

RFC 1034 关于a时可能出现的问题有些模糊 CNAME 与其他记录类型一起存在。 RFC 2181 消除歧义并明确说明允许与它们一起存在的记录类型:

10.1。 CNAME资源记录

存在DNS CNAME(“规范名称”)记录以提供      与别名关联的规范名称。可能只有一个      任何一个别名的规范名称。这个名字通常应该是      DNS中其他位置存在的名称,但有一些罕见的名称      具有附带规范名称的别名的应用程序      在DNS中未定义。 别名(CNAME记录的标签)可以,      如果正在使用DNSSEC,则具有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.

在这种情况下,“别名”指的是左侧 CNAME 记录。项目符号列表明确表示a SOANS,和 A 在a的节点上看不到记录 CNAME 也出现了。当我们将它与6.1节结合起来时,它是不可能的 CNAME 存在于顶点,因为它必须与强制性一起生活 SOA 和 NS 记录。

(这似乎可以完成这项工作,但是如果某人的证据路径较短,请对其进行修改。)


更新:

似乎最近的混乱来自于此 Cloudflare最近的决定 允许在域的顶点定义非法的CNAME记录,为此他们将合成A记录。链接文章所描述的“RFC兼容”指的是Cloudflare合成的记录将与DNS很好地协作。这并不会改变它是完全自定义行为的事实。

在我看来,这对大型DNS社区是一种损害:它实际上并不是CNAME记录,并且误导人们相信其他软件因不允许而缺乏。 (正如我的问题所示)


85
2017-07-19 10:53



我同意这个证据,我不认为这两步证据特别长或令人费解。 (1.区域顶点保证至少有 SOA + NS 记录,2。 CNAME 记录不允许与其他数据共存) - Håkan Lindqvist
总的来说,我认为这是一个非常好的解释。如果可以添加任何内容,我认为它可能会进一步解释什么是 CNAME 记录实际上意味着,因为这可能是最广泛误解的记录类型。即使这有点超出了我的意思,我认为这是一个常见问题解答是许多(大多数?)没有正确理解的直接结果 CNAME。 - Håkan Lindqvist
@Denis在评论中无法全面回答。最简单的答案是你需要阅读RFC(1034,1035)并且很好地理解推荐是什么,推荐所需的行为是什么(AUTHORITY,SOA记录存在等),以及为什么这种类型的“无引用”别名违反了功能级别对DNS服务器的许多期望。而这只是从一开始。这个问题在这里不是一个好主题,因为它是推测性的,并没有根植于您使用设计合理,符合标准的DNS服务器的问题。 - Andrew B
@DenisHowe简而言之:没有NS和SOA记录就没有“域”这样的东西。那些是非可选记录。 - hakamadare
@Ekevoo可以说HTTP应用程序应该采用 SRV 相反,这也会使这成为一个非问题。问题不仅限于此处讨论的内容; CNAME 与普遍看法相反,并不是所需要的大匹配。最后,作为 CNAME 不像人们期望的那样工作(!),并且不能追溯重新设计,并且HTTP实现不使用 SRV 似乎更有可能“别名”样式功能变得更加普遍以迎合HTTP(在幕后实现的记录类型特定别名而不是可见记录类型) - Håkan Lindqvist


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

DNAME RR和CNAME RR [RFC1034]导致查找      (可能)返回与域名对应的数据不同      来自查询的域名。两者之间的区别      资源记录是CNAME RR指示数据查找      它的所有者为另一个单一名称,而DNAME RR则指示查找      对于其所有者名称的后代数据到相应的名称      在树的不同(单个)节点下。

例如,查看区域(参见RFC 1034 [RFC1034],      第4.3.2节,步骤3)为域名“foo.example.com”,和      DNAME资源记录在“example.com”上找到,表明全部      “example.com”下的查询将被定向到“example.net”。查找      进程将返回步骤1,新查询名称为      “foo.example.net”。如果查询名称为“www.foo.example.com”,      新的查询名称将是“www.foo.example.net”。


0
2018-03-27 15:41



这是一个不正确的解释。请参阅表格的第二行 RFC6672§2.2。顶点DNAME将导致在顶点处除DNAME之外的查询类型不匹配,即不会导致顶点A或AAAA记录的实际混叠。 - Andrew B
apex DNAME将导致no 重定向 查询顶点名称。说它会导致否定在技术上是不正确的 比赛。如果您查询NS,SOA或任何其他实际的RR类型,您仍将获得匹配 当下 为了顶点名称。从 RFC 6672:“如果区域顶点存在DNAME记录,那么仍然需要在那里拥有常规的SOA和NS资源记录。这样的DNAME不能用于 镜子 完全是一个区域,因为它没有 镜子 区域顶点。“ - Quuxplusone