我想保留顶点的动态控制，但不破坏其他 RR（NS、MX）的标准处理。
语境
域名（示例A.net）由域名所有者控制（通过域名注册商）。该网站应放置在示例B.net云。
我想使用动态寻址（此时不称之为 CNAME），这样系统就不会停滞等待注册记录中的“A”的手动更新。
完整的“NS”区域委派不适用。
逻辑简单但无效的配置：
@ CNAME exampleB.net.
www CNAME exampleB.net.
@ MX mx
@ NS ns0
; ...setting the SOA, A's
“不能这样做，违反了 RFC”
根据 CNAMERFC 2181由于 SOA 和 NS，简单地禁止您使用多个 RR，禁止您使用 apex-CNAME。
这“DNS 错误”rfc 1912称这种做法“通常由缺乏经验的管理员尝试”。
好吧，我怀疑这在 1996 年是否属实，当时只是需要一个“动态”RR（人们认为 CNAME 是动态的，但正是由于这些原因，它并不是动态的）。
事实上，这是域名系统的一个根本缺陷。除了神圣顶点的诞生之外，它确实搞乱了 www.appendectomy。在这里，我不会接受“规范的否定”作为答案。
它可以通过使用主机文件上的预处理器（例如 m4）来完成。
是啊，对……
现实世界的问题
如果您尝试这样做，使用基于文件的区域的 BIND 将会报错，并导致区域检查失败。但是使用DLZ 将通过并按所述方式工作。其他 DNS 软件可能会接受或不接受此操作，或者它们为此使用一些特殊类型（ANAME、ALIAS）。
尽管如此，如果你成功实现了这一点，你就已经收到警告了。
当任何类型的查询示例A.net将要有时解决为CNAME 例如B.net。而不是配置的记录。
这可能会奏效，但通常会失败，甚至更糟，例如在某些 MTA 中导致更改/重新交付[电子邮件保护]到[电子邮件保护]
不完整的解决方案
建议的解决方法是将 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.
这充其量只是一个修复程序，不能解决动态问题并使该区域暴露于陈旧的配置和移民陷阱之中。
相关问题
https://stackoverflow.com/questions/656009/how-to-overcome-root-domain-cname-restrictions
@ 中的 CNAME（BIND）
将根域记录设置为 CNAME
答案1
我就是评论中链接的问答的作者，所以我可以说我花了一些时间研究“使其发挥作用”的尝试所造成的脑损伤。
这基本上是行不通的。你正在将其带入“未定义行为”的领域，因为没有明确定义名称服务器软件如何与此交互的规范。是的，你可以完全忽略 RFC 2181 规定记录的右侧NS不能是别名，或者CNAME记录不能与NS记录共存的事实，并且互联网的其余部分也可以在你选择这样做时完全忽略你。
一个典型例子是，当名称服务器软件遇到
NS指向CNAME别名的记录时会发生什么。有些软件可能会选择优雅地忍受这种脑损伤，但作为递归程序运行的 BIND 却采取了强硬态度。NS当遇到该记录时，它会被丢弃在地上，尽管由于注册商提供的胶水记录，它最初可能看起来可以正常工作。一旦胶水过期，并且加载了真正权威的记录，就可以与该区域告别，向“SERVFAIL人口：你”问好。考虑到这一点后，剩下的就是自定义合成不会破坏其他名称服务器软件的记录类型。这不是记录
CNAME。这是类似于其他“假”记录类型的自定义功能ALIAS。无论如何，服务器软件的作者可以自由编写便利功能，以实现用户的最终目标，而不会破坏标准。
坦率地说，无论意图多么良好，违反标准都是无知和不负责任的。DNS 是互联网上最普遍的协议之一，易于理解的互操作至关重要。选择涉足这种未定义的行为只会给每个人带来痛苦。
你可以称其为“根本缺陷”，但现实是冷酷无情的。要解决这个问题，需要编写 RFC 更新 2181，并且其他名称服务器软件必须实现新的要求。这就是这个问题的开始和结束。