这个问题有些涉及另一个问题，但另一个问题 。
我们使用一个域名，主机名称parsing为public，主机名称parsing为私有IP。 我同意上述问题的答案，我不认为这是一个安全线程。 尤其是相对于为这个重要的域configuration和运行一个Split-Brain-DNS而言。
因此，我们决定，我们不会主持内部DNS服务器，因此不会有内部IP的反向DNS。 现在我发现我可以注册域名'10 .in-addr.arpa'与我们的DNS提供商。 所以我可以在理论上在我的反向DNS区域。 我可以在所有站点上configuration本地cachingDNS服务器，以在该服务器上查找对10.in-addr.arpa的请求，并且可以反向DNS工作+我们的DNS提供者的API和接口。
另一方面是公共DNS服务器。 所以每个人都要求1.0.0.10.in-addr.arpa会得到我们的本地主机名作为回应。
除了我们愿意接受的上述信息泄露之外，您认为这是一个坏主意吗？
这不是一个问题。
任何正常的search10.in-addr.arpa. 将从根本上遵循正常的链条，最终落到IANA的黑洞名称服务器上。 因此，只有那些专门和有意发送给那些应该到达你的服务器的名字的查询。 如果有人因此而出现问题，他们只能责怪自己。
我自己也不会这样做。
首先，您要求您的DNS提供商为您实际上不拥有的区域提供服务。 事实上，你可以做到这一点可能只是他们的一个疏忽，坦率地说，我会有点担心，他们不会妥善做避免冲突（也就是说，如果他们的另一个客户有相同的想法，你可能最终会战胜唱片），否则他们迟早会发现你已经做了什么，并且停止了这个能力。
其次，扫描所有可公开访问的DNS服务器并不难，看看他们是否对私有区域具有权威性（SOA请求10.in-addr.arpa ， 12.172.in-addr.arpa等）。 我不用威胁英特尔，所以我不知道有没有人已经这样做了，但是我不会感到惊讶，因为…
一旦你发现给定的DNS服务器正在服务给定的反向区域，枚举反向区域比列举向前区域要容易得多（从1.0.0.10.in-addr.arpa开始，然后继续前进）您可以更全面地了解内部networking及其内容，而不是试图列举前向区域中的常见名称。
当然，这不是一个可以驾驶卡车的安全漏洞（攻击者还必须弄清楚如何让机器打他们），但是我觉得能够列举一个看起来私密的反向区是不舒服的接近区域传输（DNS服务器通常不允许）。
您的DNS提供商有可能做访问受限的DNS区域（当请求来自这些IP地址时，“只服务于这个区域”），这将是一个有效的妥协。 鉴于运行DNS服务器不是火箭科学，但个人而言，我只是在内部抛出一些，并做好了。 你必须configuration你的内部parsing器指向一个自定义的位置。