nslookup,dig,host等工具命令实例
nslookup,dig,host等工具命令实例
演示环境：BackTrack 5 Release 3 x86 32bits
假设这里我们要查询的域名是 evil.com
google 的公众 dns 服务器为 8.8.8.8
baidu 的公众 dns 服务器为 202.108.22.220
hinet 的公众 dns 服务器为 168.95.1.1
并且本地的 /etc/resolv.conf 文件默认指向 8.8.8.8
《 dig 实战篇 》
查询 evil.com 域的所有类型资源记录：
root@bt:~# dig -t ANY evil.com.
使用 baidu 的公众 dns 服务器查询 evil.com 域的所有类型资源记录：
root@bt:~# dig @202.108.22.220 +qr evil.com. any
使用 hinet 的公众 dns 服务器查询 evil.com 域的所有 A 记录：
root@bt:~# dig @168.95.1.1 -t A evil.com +qr
注意，
一， -t 参数后接的资源记录类型，可以是大写或者小写；也可以不加 -t 参
数，但必须指定资源记录类型；
二，查询的可以是普通的主机名或域名，或者 FQDN；
三，如果查询的是普通主机名或者 FQDN 主机名，必须是 A 记录；
四，如果查询的是普通域名或者 FQDN 域名，可以是
A，MX，NS，SOA，CNAME，TXT 等记录；
五， +qr 参数指示 dig 先输出它发送的 DNS 请求部分信息，然后再输出从服务
器那里收到的 DNS 应答部分信息；
六，在 dig 输出的 DNS 应答部分，其 flags 字段中如果存在 aa 标识，意味着：
这是由该域的权威名字服务器返回的应答，即权威记录；如果没有 aa 标识，
表示由第三方名字服务器在本地缓存的记录；
为了说明这一点，考虑下面截图：
七， -x [IP address] 等同于 -t PTR [reversed IP address.in-addr.arpa.]
都是查询一个 IP 地址的反向解析记录
这种将 IP 地址从右边写到左边，并且跟上固定的 .in-addr.arpa. 后缀的名称，叫做一个域名的“反向域”，我们只需要查询这个反向域的 PTR 记录，就能得到该 IP 地址的域名
例如，
202.108.22.220 用于 PTR 记录的反向域写法，应该是
220.22.108.202.in-addr.arpa.
那么，下面2种查询格式，都能获取 202.108.22.220 的域名：
需要强调的是，有 A 记录的域名，不一定会有对应的反向域和 PTR 记录，DNS 标准没有规定一个 A 记录必须要有对应的 PTR 记录，因为正向解析和反向解析是两套独立运作的系统，并且，反向解析的结果不一定要对应原来的域名，就像我们在下面这个例子看到的一样：
向 google 的公众 dns 服务器查询 dns.baidu.com 的 A 记录：
root@bt:~# dig @8.8.8.8 +nocmd +noall +answer dns.baidu.com. a dns.baidu.com. 503 IN A 202.108.22.220
可以看到其 IP 和前面给出的匹配，那么，我们通过反向解析查询，验证一下
202.108.22.220 能否对应回 dns.baidu.com
root@bt:~# dig @8.8.8.8 +nocmd +noall +answer -x 202.108.22.220 220.22.108.202.in-addr.arpa. 4189 IN PTR xd-22-220-a8.bta.net.cn. root@bt:~# dig @8.8.8.8 +nocmd +noall +answer xd-22-220-a8.bta.net.cn. xd-22-220-a8.bta.net.cn. 3599 IN A 202.108.22.220
结合上面2条查询结果可以分析出：
dns.baidu.com 与 xd-22-220-a8.bta.net.cn 都对应到 202.108.22.220
前者应该是后者的别名（ CNAME ）
使用 google 的公众 dns 服务器查询 evil.com 域的所有 SOA 记录：
root@bt:~# dig @8.8.8.8 +qr evil.com SOA
假设从上一条命令的输出中，得到 evil.com 域的权威名字服务器为
ns1.evil.com
查询该名字服务器的 IP:
root@bt:~# dig ns1.evil.com.
假设上面命令输出的 IP 为 192.168.0.1
向该权威名字服务器执行完全区域传送，尝试获取 evil.com 域的所有类型资源记录，包括未公开注册的，只能在其内网使用的主机名：
root@bt:~# dig @192.168.0.1 evil.com. axfr
向该权威名字服务器执行增量区域传送，尝试获取 evil.com 域已更新的所有类型资源记录，包括未公开注册的，只能在其内网使用的主机名：
root@bt:~# dig @192.168.0.1 evil.com. ixfr
使用 google 的公众 dns 服务器查询 evil.com. 域的所有 MX 记录（邮件交换服务器），并且过滤掉输出的命令版本，查询时间统计，仅显示回答部分：
root@bt:~# dig @8.8.8.8 +nocmd +noall +answer evil.com. mx
尝试对 evil.com 中的权威名字服务器上运行的 BIND 进行版本探测，旗标获取：
root@bt:~# dig @192.168.0.1 +nocmd txt chaos VERSION.BIND +noall +answer
注意，管理员可能设置不显示 BIND 的版本信息，或者修改成有误导性的信息，甚至禁止显示版本信息，例如对 baidu 的公众 dns 服务器进行版本探测结果如下：
root@bt:~# dig @202.108.22.220 +nocmd txt chaos VERSION.BIND +noall +answer VERSION.BIND. 0 CH TXT "baidu dns"
上面最右侧字段双引号中的字符串就是自定义的版本信息
向 google 的公众 dns 服务器查询 www.evil.com 并显示整个解析过程：
root@bt:~# dig @8.8.8.8 +trace www.evil.com
假设 evil.com 域禁止了区域传送，那么我们可以使用 fierce 对该域中隐藏的主机名和 IP 地址记录，进行暴力破解：
root@bt:~# cd /pentest/enumeration/dns/fierce/ root@bt:/pentest/enumeration/dns/fierce# ./fierce.pl -dns evil.com
以上命令将使用 fierce 目录内建的字典文件，使用 -wordlist 选项，可以加载你自定义的字典：
root@bt:/pentest/enumeration/dns/fierce# ./fierce.pl -dns evil.com -wordlist MyWordList.txt
*****通过阅读 dig 的 man 文档了解到，dig 默认使用递归查询，当我们使用 @ 操作符向指定的 dns 服务器发起请求解析它负责的域中的所有记录时，如果对方配置成不允许递归请求，那么很有可能拒绝本次查询，解决方法很简单：既然对方不准我们递归，那么我们就不要递归，这通过使用 +norecurse 参数来实现，对于安全策略不够严谨的一些 dns 服务器而言，这等同于成功的进行了一次完全区域传送，
以 baidu 的 dns 服务器为例，在使用 +norecurse 参数前，它拒绝递归解析所有查询 baidu.com 域中记录的请求：
root@bt:~# dig @dns.baidu.com baidu.com any ;; WARNING: recursion requested but not available
添加 +norecurse 参数，再次发起请求，我们伪装成迭代查询，注意下面返回的资源记录数量，这基本和一个被允许区域传送的客户端得到的结果一样详尽：
root@bt:~# dig @dns.baidu.com +nocmd +noall +answer +norecurse baidu.com. any baidu.com. 7200 IN SOA dns.baidu.com. sa.baidu.com. 2012121261 300 300 2592000 7200 baidu.com. 7200 IN TXT "v=spf1 include:spf1.baidu.com include:spf2.baidu.com include:spf3.baidu.com a mx ptr ~all" baidu.com. 7200 IN MX 20 jpmx.baidu.com. baidu.com. 7200 IN MX 20 mx50.baidu.com. baidu.com. 7200 IN MX 10 mx.n.shifen.com. baidu.com. 7200 IN MX 20 mx1.baidu.com. baidu.com. 600 IN A 220.181.111.86 baidu.com. 600 IN A 123.125.114.144 baidu.com. 600 IN A 220.181.111.85 baidu.com. 86400 IN NS dns.baidu.com. baidu.com. 86400 IN NS ns7.baidu.com. baidu.com. 86400 IN NS ns2.baidu.com. baidu.com. 86400 IN NS ns3.baidu.com. baidu.com. 86400 IN NS ns4.baidu.com.
可以看到，SOA，MX，NS，A 记录甚至连 TXT 记录都一览无遗
当然，这并不是说， +norecurse 是万能丹，只是碰巧 dns.baidu.com 的安全策略有逻辑上的缺陷，而这里通过 dig 挖掘到的仅是其中之一；但这个思路值得借鉴：对于那些看似固若金汤的名字服务器，应该采用多种不同的手段来测试，尝试将提交的查询请求“复杂化”，观察并根据服务器的响应修改参数再次提交，或许就能曝露出那些不为人知的错误配置和安全漏洞，这也是渗透测试的重要思想之一
*****免责声明，这里披露的数据仅作为学习交流技术，以及引起相关组织机构重视，改善，加固其安全性为目的；
严禁利用这里给出的信息向目标进行任何未经授权的渗透，攻击和入侵，本文作者对由此造成的相关数据泄漏，财产损失不负任何法律上的责任
《 基于shell 命令行的 whois 实战篇 》
查询 evil.com 域的注册者信息，受理注册的机构，该域的名字服务器等信息：
root@bt:~# whois evil.com