如何在 DNS/BIND 中正确执行“动态顶点”？

Question

我想保留对顶点的动态控制，但不破坏其他 RR（NS、MX）的标准处理。

语境

域名 ( exampleA.net ) 由域名所有者（通过域名注册商）控制。该网站应放在exampleB.net云中。

我想使用动态寻址（此时不称其为 CNAME），因此系统不会等待手动更新注册商记录中的“A”。

完整的“NS”区域委派不适用。

逻辑，简单的配置，这是无效的：

@   CNAME exampleB.net.
www CNAME exampleB.net.
@   MX    mx
@   NS    ns0
; ...setting the SOA, A's

“做不到，违反 RFC”

根据RFC 2181 的CNAME由于 SOA 和 NS，只是禁止您使用多个 RR，禁止您使用 apex-CNAME。

在“DNS错误” RFC 1912年称这种做法“往往没有经验的管理员尝试”。

好吧，我怀疑即使在 1996 年也是如此，这只是需要一个“动态”RR（CNAME 被认为是，但事实并非如此，正是出于这些原因）。

事实上，这是域名系统的一个根本缺陷。除了圣尖的诞生，它真的把 www.appendectomy 搞得一团糟。我不是在这里回答“规范否”。

可以在主机文件上使用诸如 m4 之类的预处理器来完成。

对，对...

现实世界的问题

如果您尝试此操作，使用基于文件的区域进行 BIND 将抱怨并无法通过区域检查。但是使用DLZ 将通过并工作，如所述。其他 DNS 软件可能接受也可能不接受，或者他们为此使用一些特殊类型（ANAME、ALIAS）。

尽管如此，如果你设法做到这一点，你就会被警告。

头痛开始时的任何类型的查询exampleA.net将有时得到解决的CNAME exampleB.net。而不是配置的记录。

这可能有效，通常会失败，或者更糟，例如在某些 MTA 中导致将 mail@exampleA.net 更改/重新发送到 mail@exampleB.net

不完整的解决方案

推荐的解决方法是将 RR 设置（委托）到 CNAME 记录本身，而不是合规失败。

如果您还管理特定的子系统，则可以“管道”它：

exampleB.net. MX mx.exampleB.net.

或者你可以“反弹”：

; pointing the apex CNAME to a more specific exampleA.exampleB.net.

exampleA.exampleB.net. MX mx.exampleA.net.

这充其量只是一个修补程序，不能解决动态问题，并使该区域暴露于陈旧的配置和迁移诱杀陷阱。

相关问题
/sf/ask/45920661/
CNAME in @ (BIND)
Set root domain record to be a CNAME

Answer 1

我是编写与评论相关的问答的人，所以可以说我花了一些时间研究围绕“使这项工作”尝试的脑损伤。

这基本上是一个非启动器。您将其带入“未定义行为”领域，因为没有明确定义的名称服务器软件将如何与之交互的规范。是的，您可以完全忽略 RFC 2181 指定NS记录的右侧不能是别名，或者CNAME记录不能与NS记录共存的事实，并且互联网的其余部分也可以自由地完全忽略您你选择这样做。

• 这种情况的一个例子是当名称服务器软件遇到NS指向CNAME别名的记录时会发生什么。一些软件可能会选择优雅地忍受脑损伤，但 BIND 作为递归操作会采取强硬态度。NS遇到该记录时，它会掉在地板上，即使由于注册商提供的胶水记录，它可能看起来像最初一样有效。一旦胶水过期并加载了真正权威的记录，就亲吻那个区域再见，并向SERVFAIL人口：你问好。

• 一旦考虑到这一点，剩下的就是记录类型的自定义合成，不会破坏其他名称服务器软件。那不是CNAME记录。这是一个类似于其他“假”记录类型的自定义功能，例如ALIAS. 无论如何，服务器软件的作者可以自由地编写方便的功能来实现用户的最终目标，而不会违反标准。

打破标准，说白了就是无知、不负责任，不管用心多好。DNS 是互联网上最普遍的协议之一，易于理解的互操作性至关重要。选择涉足这种事情的未定义行为只会给每个人带来痛苦。

如果您愿意，可以称其为“根本缺陷”，但现实是冷酷无情的。解决此问题需要编写 RFC 更新 2181，并且其他名称服务器软件实现新要求。这是这个问题的开始和结束。