And*_*w B 138 domain-name-system cname-record
这是一个关于区域顶点（或根部）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 一样。让我们关闭这个婴儿。
And*_*w B 110
CNAME最初创建记录是为了允许将提供相同资源的多个名称别名为资源的单个“规范名称”。随着基于名称的虚拟主机的出现，将它们用作 IP 地址别名的通用形式已变得司空见惯。不幸的是，大多数具有 Web 托管背景的人都希望CNAME记录表明DNS 中的等效性，这从来不是本意。顶点包含显然未用于识别规范主机资源 ( NS, SOA) 的记录类型，如果不破坏基本级别的标准，就不能对其进行别名处理。（特别是在区域切割方面）
不幸的是，最初的 DNS 标准是在标准管理机构意识到需要明确的措辞来定义一致的行为 ( RFC 2119 )之前编写的。由于措辞含糊，有必要创建RFC 2181来澄清几个极端情况，更新后的措辞更清楚地表明 aCNAME 不能在不违反标准的情况下实现顶点混叠。
6.1. 区域权限
区域的权威服务器在区域起源的 NS 记录中被枚举，与授权开始 (SOA) 记录一起是每个区域中的强制性记录。 这样的服务器对一个区域中但不在另一个区域中的所有资源记录具有权威性。指示区域切割的 NS 记录是创建的子区域的属性，该子区域或其任何子域的来源的任何其他记录也是如此。一个区域的服务器不应为与另一个区域中的名称相关的查询返回权威答案，其中包括 NS，可能还有 A，区域切割处的记录，除非它恰好也是另一个区域的服务器。
这确立了这一点，SOA并且NS记录是强制性的，但它没有说明A此处出现的或其他类型。我当时引用这句话似乎是多余的，但稍后它会变得更加相关。
RFC 1034对当 aCNAME与其他记录类型一起存在时可能出现的问题有些含糊。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 Systems Consortium 最近在区域的顶点发布了关于CNAME 的文章，为什么存在这种限制，以及一些替代方案。遗憾的是，这不太可能很快改变：
如果不同时更改世界上所有的 >DNS 服务器实现，我们就无法更改特殊 CNAME 记录的使用方式。这是因为它的含义和解释在 DNS 协议中有严格的定义；所有当前的 DNS 客户端和服务器实现都遵循此规范。试图“放宽”权威服务器中 CNAME 的使用方式，而不同时更改当前运行的所有 DNS 解析器，将导致名称解析中断（对于那些实施“放宽”权威服务器解决方案的组织而言，Web 和电子邮件服务会间歇性地不可用。
但还有希望：
目前正在讨论的另一个潜在解决方案是添加浏览器会查找的新 dns 资源记录类型，它可能存在于顶点。这将是用于 http 请求的特定于应用程序的主机名（类似于 MX 的工作方式）。
优点：这与 DNS 设计完全一致。
缺点：这尚不可用，并且需要浏览器客户端更新。
| 归档时间： |
|
| 查看次数： |
79054 次 |
| 最近记录： |