在 DNS 中,IN NS 可以指向 CNAME 吗?

Mar*_*ner 20 domain-name-system cname-record ns-record

是否允许将 NS 记录设为 CNAME?例如:

subdomain.example.com.       IN NS  ns1.example.com.
ns1.example.com.             CNAME  foo.example.com.
foo.example.com.             IN A   10.1.1.1
Run Code Online (Sandbox Code Playgroud)

尽管这(当然)确实如此,但这似乎在绑定中不起作用:

subdomain.example.com.       IN NS  foo.example.com.
foo.example.com.             IN A   10.1.1.1
Run Code Online (Sandbox Code Playgroud)

任何指向禁止此设置的 RFC 的指针将不胜感激。

jj3*_*j33 23

定义 NS RR ( RFC1035 )的实际 RFC只是说它是一个域名,而没有指定目标的 RR 类型(尽管它确实明确表示它不能是 IP)。它确实在RFC1912中得到了具体提及,第 2.4 节:

让 NS 记录指向 CNAME 是不好的,并且可能与当前的 BIND 服务器发生严重冲突。事实上,当前的 BIND 实现会忽略这些记录,可能会导致一个蹩脚的委托。BIND 中进行了一定数量的安全检查,以防止欺骗 DNS NS 记录。此外,据报道,较旧的 BIND 服务器将陷入无限查询循环中,试图找出别名名称服务器的地址,从而导致发送连续的 DNS 请求流。

不是绝对不能,但它肯定符合您所看到的行为

  • 我发现 RFC 2181 10.3 清楚地表明它是无效的,但你的回答已经足够好了。 (11认同)
  • [RFC1034](http://tools.ietf.org/html/rfc1034) 说,“RR 中指向另一个名称的域名应该始终指向主名称而不是别名。这避免了访问信息时的额外间接....当然,根据健壮性原则,域软件在出现 CNAME 链或循环时不应失败;应该遵循 CNAME 链,并将 CNAME 循环作为错误发出信号。” (5认同)
  • 为了更加清晰:此处的“不得”措辞无关紧要,因为 RFC 1912 是信息性的,没有定义标准。马克是正确的 [RFC 2181](https://tools.ietf.org/html/rfc2181#section-10.1) 是正确的参考。(RFC 1034 是在语言标准固化之前编写的,因此含糊不清) (2认同)