☰

同时具有 A 记录和 NS 记录的子域名有效吗？

tag-icon • tag-icon domain-name-system a-record ns-record
同时具有 A 记录和 NS 记录的子域名有效吗？

假设我拥有example.com。

然后，我在上创建一条A记录。test.example.com1.1.1.1

然后，我在上创建一条NS记录。test.example.comns1.anotherdnshost.com

在另一个 DNS 主机上，我向 添加了A根 ( test.example.com)的记录2.2.2.2。

当客户端查询时test.example.com，A将返回哪条记录？哪条记录会更“占主导地位” A？这样的设置有效吗？

答案1

这不合法，不是。它可能会返回 1.1.1.1，因为它会由第一个解析的服务器返回，但“正确”的值应该是 SOA 记录中注册为主名称服务器的任何名称服务器。但是，返回的内容可能取决于运行的名称服务器软件的版本。见下文，它只会将其转发到下一个名称服务器，并且永远不会显示 1.1.1.1。

现在列出区域中的其他 NS 记录是正确的，但其他 NS 应该是具有相同区域的名称服务器。不过，您可以将子域名指向备用名称服务器。

因此，您的注册商的 example.com 指向来自注册商名称服务器（粘合）的 ns1.example.com 和 ns2.example.com，其 IP 分别为 1.2.3.4 和 2.3.4.5。

然后，您将拥有一个区域，其中 SOA 选择 ns1 或 ns2 作为主要区域，然后您将拥有两个指向 ns1.example.com 和 ns2.example.com 的 NS 记录，其中包含该域的 A 记录（以及 mx、txt、cname 等）。

NS1 和 NS2.example.com 都应该具有相同的区域，并且它们应该自动相互复制。

现在，将 test.example.com 指向 ns1.somethingelse.com 和 ns2.somethingelse.com 是有效的，但 ns1 和 ns2.example.com 的名称服务器上没有 test.example.com 的 A 记录，除非 ns1 和 ns2.example.com 有 glue，否则应自动发送 ns1 和 ns2.somethingelse.com 的 IP。（如果 TLD 不同，即 .com 和 .org，则不会发送）

我希望一切都有意义，如果有任何令人困惑的地方我可以进一步澄清。

以下是对发生的情况的测试：

在 shadowrpg.net 的名称服务器上：

$ttl 38400
@   IN  SOA shell2.reganw.com. root.shell2.reganw.com. (
            1298345653
            10800
            3600
            604800
            38400 )
@   IN  NS  shell2.reganw.com.
test.shadowrpg.net.     IN  A   127.0.0.1
test.shadowrpg.net. IN  NS  saber.reganw.com.

在 test.shadowrpg.net 的名称服务器 (saber) 上：

$ttl 38400
@   IN  SOA saber.reganw.com. root.shell2.reganw.com. (
            1298345653
            10800
            3600
            604800
            38400 )
@   IN  NS  saber.reganw.com.
test.shadowrpg.net.     IN  A   127.0.0.2
test.shadowrpg.net. IN  NS  saber.reganw.com.

第一个结果是未配置 saber，显示推荐。

[regan@gamma ~]$ dig +trace test.shadowrpg.net

; <<>> DiG 9.7.3-P1-RedHat-9.7.3-2.P1.fc13 <<>> +trace test.shadowrpg.net
;; global options: +cmd
.           518400  IN  NS  G.ROOT-SERVERS.NET.
.           518400  IN  NS  C.ROOT-SERVERS.NET. (snip)
;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 2 ms

net.            172800  IN  NS  a.gtld-servers.net.
net.            172800  IN  NS  m.gtld-servers.net. (snip)
;; Received 493 bytes from 199.7.83.42#53(199.7.83.42) in 55 ms

shadowrpg.net.      172800  IN  NS  ns1.reganw.com.
shadowrpg.net.      172800  IN  NS  ns2.reganw.com.
shadowrpg.net.      172800  IN  NS  ns3.reganw.com.
;; Received 232 bytes from 192.35.51.30#53(192.35.51.30) in 54 ms

test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; Received 110 bytes from 209.161.6.3#53(209.161.6.3) in 2123 ms

test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 110 bytes from 173.45.238.245#53(173.45.238.245) in 81 ms

test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 110 bytes from 173.45.238.245#53(173.45.238.245) in 82 ms

test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 110 bytes from 173.45.238.245#53(173.45.238.245) in 112 ms

并配置了 Saber：

^C[regan@gamma ~]$ dig +trace test.shadowrpg.net

; <<>> DiG 9.7.3-P1-RedHat-9.7.3-2.P1.fc13 <<>> +trace test.shadowrpg.net
;; global options: +cmd
.           518400  IN  NS  L.ROOT-SERVERS.NET.
.           518400  IN  NS  J.ROOT-SERVERS.NET. (snip)
;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 2 ms

net.            172800  IN  NS  m.gtld-servers.net.
net.            172800  IN  NS  a.gtld-servers.net. (snip)
;; Received 493 bytes from 198.41.0.4#53(198.41.0.4) in 129 ms

shadowrpg.net.      172800  IN  NS  ns1.reganw.com.
shadowrpg.net.      172800  IN  NS  ns2.reganw.com.
shadowrpg.net.      172800  IN  NS  ns3.reganw.com.
;; Received 232 bytes from 192.12.94.30#53(192.12.94.30) in 165 ms

test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; Received 110 bytes from 209.161.6.3#53(209.161.6.3) in 38 ms

test.shadowrpg.net. 38400   IN  A   127.0.0.2
test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; Received 126 bytes from 173.45.238.245#53(173.45.238.245) in 80 ms

[regan@gamma ~]$

因此，一旦您添加了 NS 记录，它就会引用它，并忽略对它自己的任何查询。现在，如果您为名称服务器添加 A 记录，它将与 NS 记录一起传递（因此解析器不必查找新名称服务器的 IP）。

答案2

这个问题比较微妙，我来一步一步解释一下。

这正确的配置当然只能是两者之一——NS或者任何其他记录。

当您为 添加 NS 记录时test.example.com，您代表所有内容均来自test.example.com和 下方，并发送到另一个名称服务器。 的 A 记录的正常位置test.net-me.net应位于 上ns1.anotherdnshost.com。

A test.example.com ...现在您的问题可以重新表述为 —在“父”example.com 区域中可以吗？无论另一台主机上的“委派”区域中是否存在任何记录，都可能提出相同的问题。

我的回答是辩证的。:) 1. 是的，在“父”区域中有这样的记录是可以的。但是 2. 由于test.example.com 委派至ns1.anotherdnshost.com，记录test.example.com及以下，恰好存在（无论什么原因）除ns1.anotherdnshost.com以下服务器之外的任何服务器不权威不再。

父区域服务器在回复查询时test.example.com，a)必须发送指向 NS 记录ns1.anotherdnshost.com并 b)可以不可以发送任何它恰好有的 A 记录test.example.com，c）即使它确实发送了记录，它一定不将其标记为“权威性”答案，并且 d）即使它撒谎并将该答案标记为权威答案，解析器也会收到这样的答复，因为它知道这test.example.com是委派，应该考虑仅有的来自其权威服务器的答案—— ns1.anotherdnshost.com。

我使用 bind9 测试了这样的配置：

  • 命名，named-checkzone 也没有对这样的区域提出投诉 - 显然这个区域被认为是正确的。
  • 当我在父服务器中查询 test.example.com 时，它返回仅有的NS 记录，就好像根本test.example.com A 1.1.1.1不存在一样。

其他 DNS 服务器软件可能表现不同，但无论如何都必须遵守上述一般规则。

这Verisign 的相关文章帮助我理解了这个问题。

我很抱歉，所有的废话

答案3

test.example.com A 2.2.2.2应该被归还，因为它是权威的（“主导”）。

此设置不违反 RFC。

推理请参见我在此处的较长回答。

答案4

这是完全有效的，但不是您所想的那样。

一旦您将子域名委托给另一组名称服务器，它们就具有权威性。 他们可以合法地为该域名宣传 A 记录；事实上，这样做是正常的做法，例如参见dig google.com。

我不知道如果你在委派名称服务器 - 我怀疑没有什么好处，因为其他人都正确地建议你。但宣传这样的记录在委派服务器，这可能就是为什么你在 RFC 中找不到禁止的原因。

因此，问题不在于域名同时存在 A 记录和 NS 记录；而在于试图宣传这两个记录来自同一个域名服务器。

相关内容