这是一个关于区域顶点（或根部）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 一样。让我们关闭这个婴儿。
我需要为一个 CNAME 域创建一个 NS 记录，目的是让两个域指向一个 IP，而不必在两个不同的地方维护当前的 IP 地址。
此域的 DNS 提供商是 DynDNS，但它们阻止了此操作：
不能使用与区域名称相同的标签创建 CNAME
我可以使用 1and1 提供 DNS 的另一个域来执行此操作：
root@srv-ubuntu:~# dig myseconddomain.co.uk
; <<>> DiG 9.4.2-P1 <<>> myseconddomain.co.uk
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61795
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;myseconddomain.co.uk. IN A
;; ANSWER SECTION:
myseconddomain.co.uk. 71605 IN CNAME myfirstdomain.co.uk.
myfirstdomain.co.uk. 59 IN A www.xxx.yyy.zzz
;; Query time: 298 msec …我可以在我的 .zone 文件中放入这样的内容吗？
@ IN CNAME srvr-01.foo.bar.
或者那是无效的？如果无效，如何将访问者重定向mydomain.com到服务器srvr-01.foo.bar？（请注意，我没有得到服务器 IP，只有域，这让我认为它可能会随机更改）
编辑：对不起，我的错。我替换NS为CNAME，这正是我真正想写的。