我目前在RCNTEC公司工作，每天都会与分布式环境打交道。每当我不得不使用ISC BIND来实现DNS服务时，我就会问自己——是否只有用于域名的NS服务器同时也被当做该域名的DNS服务器？“yandex.ru”域名的DNS区域是否只有两个名称服务器，同样，“google.com”这个域名是否也只有四个名称服务器呢？
很显然，事实并非这样。我认为很多拥有互联网服务的公司已经通过负载均衡，防火墙或者某种反向代理服务分散了它们的DNS基础设施。
但是，我们该如何解决这个谜题，并得到有关后端DNS服务器的一些信息呢？现在是时候跟随我的思路，深入了解一下DNS。
Chaosnet
你可以点击这里阅读更多关于Chaosnet的信息。换句话说，这是另一种处于ISO OSI第三层的网络协议。关于DNS，Chaosnet被认为是类似于IN（互联网）和HS（Hesiod）这样的网络类之一（代码为CH ）。
Chaosnet很有趣，因为CH类经常被用于服务区域的“bind.”，它包含了一些关于DNS服务器的有用信息。我想你应该知道'version.bind'的记录，通过该记录你可以确定DNS服务器的版本。
有很多常用的基于这个记录的DNS指纹技术。
来看看一个例子：
正如你在上图所看到的，我通过我自己的DNS服务器请求了Chaosnet 的TXT记录——'version.bind'，并得到了包含我的DNS服务器版本信息的响应。
我们可以获得DNS服务器版本信息，但是我们仍然无法枚举中继器后面的DNS服务器。另外，很多系统管理员都知道这个“特性”，并且他们也知道如何修复这个问题并隐藏DNS服务器版本。
即使我们的目标系统管理员没有修补DNS域的“bind.”记录，我们也无法枚举DNS ——这只是版本信息，而不是IP或任何类似的东西。
另一个CH TXT记录
TXT记录“hostname.bind”是CH区域“bind”中可用的另一条记录。我们来看看，如果我们从DNS服务器上请求这个记录会发生什么：
不错！我们得到了服务器的主机名。在我所演示的这种情况中，主机名只是内部服务器的名称，但是在分布式环境中会是什么呢？
我的经验表明，为了部署的方便，服务器主机名与他们的外部DNS名称相等的情况非常普遍。那么在这种情况下，获得了主机的内部主机名称，也就获得了该主机的外部DNS名称。我们可以简单地解析一下主机的外部DNS名称来获得服务器的IP地址。
Unhidens脚本
我写了一个小工具 ，通过运行“dig”来确定DNS服务器的版本和主机名，并解析收到的主机名。
让我们来看看unhidens脚本针对俄罗斯域名注册商的域名服务器发起请求后的输出：
如何扩大分布式环境中DNS服务攻击面
从上图中你可以看到，在31.177.85.186后面只有一个DNS服务器。事实上，我们只是通过IP 31.177.85.194和名称“ns9-1.nic.ru”扩大了我们的测试范围。
那么Yandex呢？（译者注：Yandex是俄罗斯及中亚国家使用的最大最多的一个搜索引擎）
我用我的脚本对他们的系统执行了请求:)
如何扩大分布式环境中DNS服务攻击面
哈哈！我们完全列举出了放在公共机器后面的Yandex后端的DNS服务器。我们可以请求主机名并解析出它们的IP地址。
在请求Yandex的DNS服务器所发现的主机都被防火墙所保护，所以我无法直接与这些服务器直接通信。但我试图对其他几家公司执行unhidens脚本后，有时我会看到一些存在漏洞的DNS软件版本的机器，甚至有开放TCP 53端口的机器。
结论
本文中所描述的信息披露并不是一个重要的bug，但是可以被攻击者用来扩大攻击面。
尝试对不同的域名运行unhidens脚本，我相信你会喜欢上这个脚本！
另外，请记住“bind.”域并不仅仅是ISC BIND的功能，我看到很多不同的DNS服务器均受到这种信息泄露的影响。
如果你想在你的DNS服务器上修复此安全问题，我建议你手动处理CH域的“bind.”。
如果你使用了ISC BIND，那么你只需在'named.conf'中添加如下内容即可：
并创建“bind.dns”区域文件：
这不是一种隐藏DNS服务器版本信息和主机名的最简单的方法，但是使用此配置，你可以将记录所有的 “bind.” 请求行为， 这样你可以跟踪所有试图请求有关你的机器的敏感信息的客户端来进行攻击分析和攻击溯源。
