公共服务器上的私有IP反向DNS -一个坏主意？

Question

这个问题在某种程度上与另一个问题有关，但恰恰相反。

我们使用一个域，其中包含解析为公共主机名的主机名，以及与私有IP相关的主机名。我同意上述问题的答案，我不认为这是一条安全线索。特别是相对于为这一重要领域配置和运行拆分脑DNS的能力而言。

因此，我们决定不托管内部DNS服务器，因此不会对内部IP进行反向DNS。现在我发现我可以将域名'10.in-addr.arpa‘注册到我们的DNS提供者。所以理论上我可以把我的反向DNS区域放在那里。我可以将所有站点上的本地缓存DNS服务器配置为在该服务器上查找10.in-addr.arpa的请求，并具有反向DNS工作+ API和我们DNS提供程序的接口。

另一方面，它是一个公共DNS服务器。因此，每个人都想要1.0.0.10.in-addr.arpa，就会得到本地主机名作为响应。

除了我们愿意接受的上述信息泄露外，你认为这是个坏主意吗？

Answer 1

这不是问题。

对10.in-addr.arpa.的任何正常搜索都将遵循从根向下的正常链，并最终到达IANA的黑洞名称服务器。因此，对该名称的唯一查询应该到达您的服务器，就是那些专门和有意发送到服务器的查询。如果有人因此而出了问题，他们只能怪自己。

Answer 2

我不会这么做的，我自己。

首先，您要求DNS提供程序为您实际不拥有的区域提供服务。你能做到这一点可能只是他们的疏忽，坦白地说，我会有点担心，要么他们不会正确地避免冲突(也就是说，如果他们的另一个客户有相同的想法，你可能会为了记录而争吵)，否则他们迟早会发现你做了什么，并禁用了这种能力。

其次，扫描所有可公开访问的DNS服务器，看看它们是否对私有区域( 10.in-addr.arpa、12.172.in-addr.arpa等的servers )具有权威性并不难。我不从事威胁情报工作，所以我不知道是否已经有人这么做了，但如果他们是的话，我也不会感到惊讶，因为.

一旦您发现给定的DNS服务器正在为给定的反向区域提供服务，枚举该反向区域要比枚举前向区域(从1.0.0.10.in-addr.arpa开始并按您的方式工作)要容易得多，并且您可以更全面地查看内部网络及其内容，而不是试图枚举前向区域中的常见名称。

当然，这不是一个你可以驾驶卡车通过的安全漏洞(攻击者还必须弄清楚如何才能攻击这些机器)，但我觉得能够枚举一个看似私有的反向区域与区域传输( DNS服务器通常不允许的)非常接近。

您的DNS提供程序可能能够执行访问受限的DNS区域(“只有在来自这些IP地址的请求时才为此区域服务”)，这将是一个有效的折衷方案。不过，考虑到运行DNS服务器并不是一门火箭科学，我会在内部抛出几个服务器，并完成它。无论如何，您必须将内部解析器配置为指向自定义位置。

Answer 3

了解公共权威DNS是如何与委托一起工作的，这一点很重要。

仅仅因为您的ISP允许您创建区域，并不一定意味着您的反向区域是互联网指向的地方。

对于大多数托管DNS服务，它们允许您创建任何您想要的区域。但是，除非存在委托链，否则将无法达到此目的，并将DNS服务器(或ISP)作为这些区域的主要授权。

如果我的地址是十点十分。在我的AWS DNS服务上，如果我直接查找该DNS服务器，它将工作。但是10.10. for addr.arpa的实际授权。在别的地方。因此，当常规用户查找该反向空间时，他们将进行委托更改(arpa NS服务器指向inaddr.arpa名称服务器，该服务器指向10.in-addr.arpa名称服务器，后者指向10.in-addr.arpa名称服务器。

因此，如果您实际上应该具有权威性(就像您拥有公共IP空间一样)，则需要在使用区域之前配置来自父服务器的委托。

另外，是的，把你的内部反向空间放到外部公共网络上是个坏主意，特别是如果它实际上是权威的，并且被适当授权的话。没有什么理由公开这样做。

您最好创建一个单独的云DNS服务器，该服务器承载反向空间，不受委托，并且只将查询限制在属于您的子网上。之后，您可以在递归服务器上设置转发，以手动指向此DNS服务器，查看内部使用的任何反向空间。