这个问题有点涉及到另一个问题但事实恰恰相反。
我们使用一个域名，其主机名解析为公共 IP，主机名解析为私有 IP。我同意上述问题的答案，我不认为这是一个安全问题。特别是相对于为这个重要域名配置和运行 Split-Brain-DNS 的成本而言。
因此，我们决定不托管内部 DNS 服务器，因此不会为内部 IP 设置反向 DNS。现在我发现我可以向我们的 DNS 提供商注册域名“10.in-addr.arpa”。因此理论上我可以在那里托管我的反向 DNS 区域。我可以在所有站点上配置本地缓存 DNS 服务器，以在该服务器上查找对 10.in-addr.arpa 的请求，这样反向 DNS 就可以正常工作 + 我们 DNS 提供商的 API 和接口。
另一边是公共 DNS 服务器。因此，每个向其请求（例如 1.0.0.10.in-addr.arpa）的人都会得到我们的本地主机名作为响应。
除了上述我们愿意接受的信息泄露之外，你认为这是一个坏主意吗？
答案1
这不是一个问题。
任何正常的搜索10.in-addr.arpa.都会沿着正常的链条从根部向下搜索，最终到达 IANA 的黑洞名称服务器。因此，只有那些专门发送到那里的查询才会到达您的服务器。如果有人因此遇到问题，那也只能怪他们自己。
答案2
我自己不会这么做。
首先，你要求 DNS 提供商为你不需要的区域提供服务实际上自己。事实上，你可以这样做可能只是他们的疏忽，坦率地说，我有点担心他们不会正确地避免冲突（也就是说，如果他们的另一个客户有同样的想法，你们可能会最终争夺记录），或者他们迟早会发现你所做的事情并禁用该功能。
其次，扫描所有可公开访问的 DNS 服务器以查看它们是否认为它们对私有区域具有权威性（SOA 请求10.in-addr.arpa、12.172.in-addr.arpa等等）并不难。我不从事威胁情报工作，所以我不知道是否有人已经这样做了，但如果他们这样做了，我也不会感到惊讶，因为...
一旦发现给定的 DNS 服务器正在服务于给定的反向区域，枚举该反向区域就比枚举正向区域 (从那里开始1.0.0.10.in-addr.arpa并逐步向上) 容易得多，并且与尝试枚举正向区域中的通用名称相比，您可以更全面地了解内部网络及其内容。
当然，这不是一个可以驾驶卡车通过的安全漏洞（攻击者仍然必须弄清楚如何接近机器并对其进行攻击），但我觉得能够枚举看似私有的反向区域与区域传输（DNS 服务器通常不允许）非常接近。
您的 DNS 提供商可能能够执行访问受限的 DNS 区域（“仅当请求来自这些 IP 地址时才为该区域提供服务”），这将是一个有效的折衷方案。考虑到运行 DNS 服务器并不是什么难事，我个人建议在内部部署几个，然后就完事了。无论如何，您都必须将内部解析器配置为指向自定义位置。
答案3
了解公共权威 DNS 如何与委派协同工作非常重要。
仅仅因为您的 ISP 允许您创建区域，并不一定意味着您的反向区域就是互联网指向的地方。
对于大多数托管 DNS 服务，它们允许您创建任何您想要的区域。但除非存在委派链，指向您的 DNS 服务器（或您的 ISP）作为这些区域的主要授权机构，否则无法访问。
如果我在我的 AWS DNS 服务上创建 10.10.in-addr.arpa. 区域，那么只要我直接查询该 DNS 服务器，它就会正常工作。但 10.10.in-addr.arpa. 的实际权限在其他地方。因此，当普通用户查询该反向空间时，他们将经历委托更改（arpa NS 服务器指向 in-addr.arpa 名称服务器，后者指向 10.in-addr.arpa 名称服务器，后者指向 10.10.in-addr.arpa 名称服务器。
因此，如果您实际上应该具有权威性（就像您拥有该公共 IP 空间一样），那么您需要在使用区域之前从父服务器配置委派。
另外，将内部反向空间放在外部公共互联网上确实是一个坏主意，特别是如果它实际上是权威的并且被适当授权的话。公开这样做的理由很少。
您最好创建一个单独的云 DNS 服务器来托管该反向空间，并且不委托，并将查询限制在属于您的子网中。之后，您可以在递归服务器上设置转发，以手动将您在内部使用的任何反向空间指向此 DNS 服务器。