☰

我们是否应该允许 DNS 区域转移到根服务器和父区域 NS 服务器？

tag-icon • tag-icon domain-name-system transfer
我们是否应该允许 DNS 区域转移到根服务器和父区域 NS 服务器？

我在示例设置中从未发现任何关于此内容的引用，包括来自 Bind ARM 的设置。
尽管如此，我注意到我的权威服务器收到了来自 IP（而不是其名称）的传输请求，这些 IP 实际上是某些根服务器集（DNS 根）的一部分。
我正准备在我的配置中允许此类传输，并考虑再检查一下。

如果我没记错的话，根服务器只会负责 gTLD，然后 TLD 只会负责其各自的下一级域名——授权。但是，如果我理解 DNS 的分层设计，那么每个服务器都应该提供其拥有的所有信息，而不是提供严格的最低限度信息并将客户端引入迭代过程。那么为什么不呢，根服务器可能希望能够回答有关我的区域的问题……这将减轻我自己的服务器的压力。

那么，首先，为什么根服务器（似乎）要求我的区域？
这实际上是一次攻击吗？

或者，如果这样可以的话，仍然存在这样的服务器（根或 TLD）将允许其处理的区域进行传输的风险，而这可能不是我们的政策——不要相信大鱼总能完美地管理其设置。

我想我们可能会有不同的感受，这取决于我们是否已经使用 DNSSEC 对区域进行了身份验证，因为信任 DNSSEC 签名的根并不等同于信任整个区域内容的根。

顺便说一句，如果我们允许转移，我们也应该向他们发送修改通知。

*我觉得这个问题也应该有标签*
AXFR、区域传输和根服务器

编辑（这是线索）：
我从日志行开始

20-Jan-2016 20:33:30.581 security: error: client 192.134.4.83#51264: zone transfer 'MyZone.info/AXFR/IN' denied

所以

dig +noall +answer +authority -x 192.134.4.83 @a.in-addr-servers.arpa.
192.in-addr.arpa.       86400   IN      NS      y.arin.net.
[...]

dig +noall +answer +authority -x 192.134.4.83 @y.arin.net.
134.192.in-addr.arpa.   172800  IN      NS      ns3.nic.fr.
[...]

dig +noall +answer -x 192.134.4.83 @ns3.nic.fr.
83.4.134.192.in-addr.arpa. 172800 IN    PTR     zonemaster.rd.nic.fr.

dig +noall +authority SOA zonemaster.rd.nic.fr. @ns3.nic.fr.
rd.nic.fr.              3600    IN      SOA     ns2.rd.nic.fr. hostmaster.nic.fr. 2015111706 21600 3600 3600000 3600

嗯……
我确实在那些日子里玩过在线 DNS 检查器，包括法国 TLDzonemaster.fr顺便说一句，相当详细。

因此 AXFR 请求只是他们运行的测试的一部分。:-)

我的错。
谢谢你的回答。

答案1

在大多数情况下，我同意不要相信大鱼总是管理他们的设置。因为运行 DNS 确实没有（直接）利润（让我们忽略 OpenDNS/Google 等）。我一直认为根域服务器很可能是由非常非常精通 DNS 的人运行的，他们非常擅长自己的工作。因为如果这些服务器管理不善，对整个互联网来说将是灾难性的。我认为一般来说你可以信任核心网络的东西，因为管理层远离它！

话虽如此，根区域服务器没有理由向域的权威服务器请求 AXFR。这些机器（集群）非常繁忙，想象一下随机请求区域传输会带来的额外压力。根本没有逻辑上的理由发生这种情况。因此我几乎可以肯定这是某种攻击。

唯一需要 AXFR 访问的服务器是辅助区域服务器，其他所有服务器都可以使用标准 DNS 协议，就像它们本来打算的那样！

答案2

实际上...

可以想象可能至少有一个根名称服务器（为了便于讨论，假设它被命名为 L）实际上是一组分布在世界各地的数百台服务器。而且可能某个实体对测试 DNS 区域的设置感兴趣，并且该实体可能有权访问这组机器。然后使用这些机器运行测试会非常方便，因为这将提供有关不同地方的工作原理的信息。而且，其中一项测试可能是发送查询，不是AXFR为了实际获取信息，而是为了查看是否允许或拒绝它。

我可能听说过。

相关内容