主页 / server / 问题 / 613829
Accepted
Andrew B
Asked: 2014-07-20 02:53:34 +0800 CST

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

  • 772

这是关于区域顶点（或根）的 CNAME的规范问题

CNAME域顶端的记录是一种禁忌做法，这是相对普遍的知识。

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

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

最近，我有一家网络托管公司向业务部门传递指令，我们需要将我们域的顶点 CNAME 到新记录。知道这在提供给 BIND 时将是一个自杀配置，我建议他们我们将无法遵守，这通常是愚蠢的建议。这家虚拟主机公司的立场是，标准定义的 RFC 并没有完全禁止它，并且他们的软件支持它。如果我们不能 CNAME 顶点，他们的建议是根本没有顶点记录，并且他们不会提供重定向网络服务器。...什么？

我们大多数人都知道RFC1912坚持这一点A CNAME record is not allowed to coexist with any other data.，但让我们在这里对自己诚实，RFC 只是信息性的。我所知道的最接近禁止这种做法的措辞来自RFC1034：

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

不幸的是，我在这个行业已经足够长的时间知道“不应该”与“不能”是不一样的，这对大多数软件设计师来说已经足够了。知道任何缺少与灌篮的简洁链接都会浪费我的时间，我最终让公司逃脱了责骂，因为推荐的配置可能会在没有适当披露的情况下破坏常用软件。

这将我们带到问答环节。这一次，我希望我们能够真正了解顶级 CNAME 的疯狂，而不是像我们通常在有人就该主题发帖时那样回避这个问题。RFC1912是不受限制的，我没有想到的任何其他适用于此处的信息 RFC 也是如此。让我们关闭这个婴儿。

domain-name-system

3 个回答

  1. Best Answer

    CNAME最初创建记录是为了允许将提供相同资源的多个名称别名为资源的单个“规范名称”。随着基于名称的虚拟主机的出现，将它们用作 IP 地址别名的通用形式已变得司空见惯。不幸的是，大多数来自网络托管背景的人都希望CNAME记录能够在 DNS 中表明等价，这从来都不是本意。顶点包含明显不用于识别规范主机资源 ( NS, SOA) 的记录类型，如果不从根本上破坏标准，就不能对其进行别名。（特别是关于区域削减）

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

    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 记录，它误导人们认为其他软件因不允许它而存在缺陷。（正如我的问题所示）

    • 120

  2. 2022 年 6 月更新

    新记录SVCB和HTTPS资源记录支持顶点域的别名，并有助于查找连接到 HTTP 源等服务。许多 DNS 提供商和浏览器已经支持它们，因此这似乎将成为规范最终确定的事实上的标准。

    资源

    Internet Systems Consortium 最近在zone 的顶点发布了一篇关于 CNAME 的文章，介绍了为什么存在这种限制，以及一些替代方案。可悲的是，这不太可能很快改变：

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

    但有希望：

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

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

    • 8

  3. 如果要重定向整个区域，则应使用 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”。查找过程将使用新的查询名称“foo.example.net”返回到步骤 1。如果查询名称为“www.foo.example.com”，则新查询名称将为“www.foo.example.net”。

    • 1

相关问题