目錄
2.1 DNS信息收集 1
2.1.1 whois查詢 3
2.1.2 域名基本信息查詢 4
Dns服務器查詢 4
a記錄查詢 4
mx記錄查詢 5
2.1.3 域名枚舉 5
fierse 5
dnsdict6 6
2.1.4 反向地址解析 7
2.1.5 關於DNS區域傳送漏洞 8
小結 11
2.1 DNS信息收集
從本節開始，我們從頭開始，系統的學習基於Kali Linux的web應用滲透測試。
本章主要目標是從各個角度搜集測試目標的基本信息，包括蒐集信息的途徑、各種工具的使用方法，以及簡單的示例。
按照循序漸進的原則，第一節講解如何蒐集DNS信息。對於工具的使用，我這裏不打算把使用說明再搬到這裏，意義不大。讀者希望google就可以了。
如果您對DNS的工作原理不是很瞭解，我建議您先在網上或者書籍上查閱相關資料。本節也對相關概念做了簡單詮釋，作爲學習的輔助。
關於DNS（參考：http://zh.wikipedia.org/zh-cn/%E5%9F%9F%E5%90%8D%E7%B3%BB%E7%BB%9F；
http://man.ddvip.com/linux/debian/bin9/bind9-conf-2.html）：
域名系統（英文：Domain Name System，DNS）是因特網的一項服務，它作爲將域名和IP地址相互映射的一個分佈式數據庫，能夠使人更方便的訪問互聯網。DNS 使用TCP和UDP端口53。當前，對於每一級域名長度的限制是63個字符，域名總長度則不能超過253個字符。
DNS 命名用於 Internet 等 TCP/IP 網絡中，通過用戶友好的名稱查找計算機和服務。當用戶在應用程序中輸入 DNS 名稱時，DNS 服務可以將此名稱解析爲與之相關的其他信息，如 IP 地址。
例如，多數用戶喜歡使用友好的名稱（如 debian.linuxsir.org）來查找計算機，如網絡上的郵件服務器或 Web 服務器。友好名稱更容易瞭解和記住。但是，計算機使用數字地址在網絡上進行通訊。爲更容易地使用網絡資源，DNS 等命名系統提供了一種方法，將計算機或服務的用戶友好名稱映射爲數字地址。
下圖顯示了 DNS 的基本用途，即根據計算機名稱查找其 IP 地址。
本例中，客戶端計算機查詢 DNS 服務器，要求獲得某臺計算機（Debian.linuxsir.org）的 IP 地址。由於 DNS 服務器能夠根據其本地數據庫應答此查詢，因此，它將以包含所請求信息的應答來回復客戶端，即一條主機 (A) 資源記錄，其中含有 Debian.linuxsir.org 的 IP 地址信息(211.93.98.20)。
此例顯示了單個客戶端與 DNS 服務器之間的簡單 DNS 查詢。實際上，DNS 查詢要複雜得多，包含此處未顯示的許多其他步驟。
當 DNS 客戶端需要查詢程序中使用的名稱時，它會查詢 DNS 服務器來解析該名稱。客戶端發送的每條查詢消息都包括三條信息，指定服務器回答的問題：
* 指定的 DNS 域名，規定爲完全合格的域名 (FQDN)
* 指定的查詢類型，可根據類型指定資源記錄，或者指定查詢操作的專用類型。
* DNS 域名的指定類別。
例如，指定的名稱可爲計算機的 FQDN，如 Debian.linuxsir.org ，並且指定的查詢類型用於通過該名稱搜索地址 (A) 資源記錄。將 DNS 查詢看作客戶端向服務器詢問由兩部分組成的問題，如“您是否擁有名爲‘Debian.linuxsir.org’的計算機的 A 資源記錄？”當客戶端收到來自服務器的應答時，它將讀取並解釋應答的 A 資源記錄，獲取根據名稱詢問的計算機的 IP 地址。
DNS 查詢以各種不同的方式進行解析。有時，客戶端也可使用從先前的查詢獲得的緩存信息在本地應答查詢。DNS 服務器可使用其自身的資源記錄信息緩存來應答查詢。DNS 服務器也可代表請求客戶端查詢或聯繫其他 DNS 服務器，以便完全解析該名稱，並隨後將應答返回至客戶端。這個過程稱爲遞歸。
另外，客戶端自己也可嘗試聯繫其他的 DNS 服務器來解析名稱。當客戶端執行此操作時，它會根據來自服務器的參考答案，使用其他的獨立查詢。這個過程稱爲迭代。
總之，DNS 查詢進程分兩部分進行：
* 名稱查詢從客戶端計算機開始，並傳輸至解析程序即 DNS 客戶端服務程序進行解析。
* 不能在本地解析查詢時，可根據需要查詢 DNS 服務器來解析名稱。
記錄類型
主條目：域名服務器記錄類型列表
DNS系統中，常見的資源記錄類型有：
主機記錄(A記錄)：RFC 1035定義，A記錄是用於名稱解析的重要記錄，它將特定的主機名映射到對應主機的IP地址上。
別名記錄(CNAME記錄): RFC 1035定義，CNAME記錄用於將某個別名指向到某個A記錄上，這樣就不需要再爲某個新名字另外創建一條新的A記錄。
IPv6主機語錄(AAAA記錄): RFC 3596定義，與A記錄對應，用於將特定的主機名映射到一個主機的IPv6地址。
服務位置記錄(SRV記錄): RFC 2782定義，用於定義提供特定服務的服務器的位置，如主機(hostname)，端口(port number)等。
NAPTR記錄: RFC 3403定義，它提供了正則表達式方式去映射一個域名。NAPTR記錄非常著名的一個應用是用於ENUM查詢。
完整的記錄類型列表參考：http://zh.wikipedia.org/wiki/%E5%9F%9F%E5%90%8D%E6%9C%8D%E5%8B%99%E5%99%A8%E8%A8%98%E9%8C%84%E9%A1%9E%E5%9E%8B%E5%88%97%E8%A1%A8
2.1.1 whois查詢
WHOIS（域名數據庫查詢）
一個域名的所有者可以通過查詢WHOIS數據庫而被找到；對於大多數根域名服務器， 基本的WHOIS由ICANN維護，而WHOIS的細節則由控制那個域的域註冊機構維護。
對於240多個國家代碼頂級域名(ccTLDs)，通常由該域名權威註冊機構負責維護WHOIS。例如中國互聯網絡信息中心(China Internet Network Information Center)負責 .CN 域名的WHOIS維護，香港互聯網註冊管理有限公司(Hong Kong Internet Registration Corporation Limited) 負責 .HK 域名的WHOIS維護，臺灣網絡信息中心 (Taiwan Network Information Center) 負責.TW 域名的WHOIS維護。
提供whois查詢的站點很多 google“whois”，你可以得到這些站點。
另外所有的域名提供商都提供whois信息查詢。比如在萬網查詢“iprezi.cn”，會得到如下信息：
在whois查詢中，註冊人姓名和郵箱信息，通常對於測試個人站點非常有用，因爲我們可以通過搜索引擎，社交網絡，挖掘出很多域名所有人的信息。而對於小站點而言，域名所有人往往就是管理員。
對於大型站點，我們更關心DNS服務器，很多公司都會有自己的域名服務器，這些服務器可以成爲滲透測試過程中的一個突破點。
2.1.2 域名基本信息查詢
Dns服務器查詢
除了whois查詢之外，我們還可以通過host命令來查詢dns服務器，命令格式爲：
host -t ns domainName
如下圖：
通過“host –t ns mbdongbo.com”得到該域名的兩個服務器爲ns12.xincache.com，ns11.xincache.com。
a記錄查詢
A (Address) 記錄是用來指定主機名（或域名）對應的IP地址記錄。用戶可以將該域名下的網站服務器指向到自己的web server上。同時也可以設置您域名的子域名。通俗來說A記錄就是服務器的IP,域名綁定A記錄就是告訴DNS,當你輸入域名的時候給你引導向設置在DNS的A記錄所對應的服務器。
通過
host -t a domainName
可以查詢a記錄
mx記錄查詢
MX記錄也叫做郵件路由記錄，用戶可以將該域名下的郵件服務器指向到自己的mail server上，然後即可自行操控所有的郵箱設置。您只需在線填寫您服務器的IP地址，即可將您域名下的郵件全部轉到您自己設定相應的郵件服務器上。
簡單的說，通過操作MX記錄，您纔可以得到以您域名結尾的郵局。
通過
host -t mx domainName
可以查詢該域名下的mx記錄，從而可以得到郵件服務器信息。
2.1.3 域名枚舉
在得到主域名信息之後，如果能通過主域名得到所有子域名信息，在通過子域名查詢其對應的主機IP，這樣我們能得到一個較爲完整的信息。
fierse
使用fierse工具，可以進行域名列表查詢：
fierce -dns domainName
如上圖，通過fierse，成功枚舉出某域名下的子域名列表。
關於fierse的工作原理，可以查看：http://ha.ckers.org/fierce/。
除fierse之外，dnsdict6、dnsenum、dnsmap都可以進行域名枚舉，需要說明的是，每個工具返回的結果並不相同，而且有的工具還有錯誤，讀者進行dns信息蒐集的時候，要儘量使用不同的工具，儘可能得到完整的信息。dnsdict6、dnsenum、dnsmap進行枚舉的時候都是使用字典，進行掃描，這裏以dnsdict6爲例。
dnsdict6
dnsdict6使用你提供的一個字典或者內置的列表來枚舉，基於dnsmap。
使用語法：
dnsdict6 [-d46] [-s|-m|-l|-x] [-t 線程] [-D] 域名 [字典路徑]
參數說明:
-4 顯示ipv4
-t 指定要使用的線程 默認：8 最大:32
-D ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝［只顯示字典不掃描］＝＝＝＝
-d 顯示在DNS服務器上的NS（一種服務記錄類型）MX（郵件服務器） ipv6 的域名信息
－[smlx] 選擇字典大小［內置的] -s 小型是50條 －m 中等是796條[默認] -l 大型1416條 －x 最大3211條
示例：
2.1.4 反向地址解析
（參考：http://blog.csdn.net/jackxinxu2100/article/details/8145318）
我們經常使用到得DNS服務器裏面有兩個區域，即“正向查找區域”和“反向查找區域”，正向查找區域就是我們通常所說的域名解析，反向查找區域即是這裏所說的IP反向解析，它的作用就是通過查詢IP地址的PTR記錄來得到該IP地址指向的域名，當然，要成功得到域名就必需要有該IP地址的PTR記錄。PTR記錄是郵件交換記錄的一種，郵件交換記錄中有A記錄和PTR記錄，A記錄解析名字到地址，而PTR記錄解析地址到名字。地址是指一個客戶端的IP地址，名字是指一個客戶的完全合格域名。通過對PTR記錄的查詢，達到反查的目的。
反向域名解析系統(Reverse DNS)的功能確保適當的郵件交換記錄是生效的。反向域名解析與通常的正向域名解析相反，提供IP地址到域名的對應。IP反向解析主要應用到郵件服務器中來阻攔垃圾郵件，特別是在國外。多數垃圾郵件發送者使用動態分配或者沒有註冊域名的IP地址來發送垃圾郵件，以逃避追蹤，使用了域名反向解析後，就可以大大降低垃圾郵件的數量。
比如你用 [email protected] 這個郵箱給我的郵箱 [email protected] 發了一封信。163郵件服務器接到這封信會查看這封信的信頭文件，這封信的信頭文件會顯示這封信是由哪個IP地址發出來的。然後根據這個IP地址進行反向解析，如果反向解析到這個IP所對應的域名是name.com 那麼就接受這封郵件，如果反向解析發現這個IP沒有對應到name.com，那麼就拒絕這封郵件。
由於在域名系統中，一個IP地址可以對應多個域名，因此從IP出發去找域名，理論上應該遍歷整個域名樹，但這在Internet上是不現實的。爲了完成逆向域名解析，系統提供一個特別域，該特別域稱爲逆向解析域in-addr.arpa。這樣欲解析的IP地址就會被表達成一種像域名一樣的可顯示串形式，後綴以逆向解析域域
名"in-addr.arpa"結尾。
例如一個IP地址：222.211.233.244，其逆向域名錶達方式爲：244.233.221.222.in-addr.arpa
兩種表達方式中IP地址部分順序恰好相反，因爲域名結構是自底向上(從子域到域)，而IP地址結構是自頂向下(從網絡到主機)的。實質上逆向域名解析是將IP地址表達成一個域名,以地址做爲索引的域名空間,這樣逆向解析的很大部分可以納入正向解析中。
linux中常用的反向解析工具爲nslookup和dig。
使用dig進行反向解析的命令格式爲：
dig -x ip @dnsserver #用 dig 查看反向解析
其中dnsserver可以不用指定，默認會使用本機配置的域名服務器進行反向查詢。指定dsn服務器示例如下圖：
不指定dns服務：
但是實際情況並不是盡如人意，查找的服務器不同，得到的結果的完整度也不同，比如上圖的兩個測試，都沒有得到想要的結果。很多時候，我們到提供反向查詢的網站進行查找，可能效果會更好一點。
下面是我在http://dns.aizhan.com/的查詢結果：
而在www.lbase.net的查詢結果爲：
所以想要獲得完整的信息，可以多嘗試不同的工具，整合結果。很多工具無法做反向查詢的原因，在於域名所有者沒有添加反向解析記錄。
2.1.5 關於DNS區域傳送漏洞
很多dns探測工具，都會首先嚐試dns區域傳送，然後纔是暴力枚舉，那麼什麼是DNS區域傳送漏洞呢？
區域傳送操作指的是一臺後備服務器使用來自主服務器的數據刷新自己的zone數據庫。這爲運行中的DNS服務提供了一定的冗餘度，其目的是爲了防止主域名服務器因意外故障變得不可用時影響到全局。一般來說，DNS區域傳送操作只在網絡裏真的有後備域名DNS服務器時纔有必要執行，但許多DNS服務器卻被錯誤地配置成只要有人發出請求，就會向對方提供一個zone數據庫的拷貝。如果所提供的信息只是與連到因特網上且具備有效主機名的系統相關，那麼這種錯誤配置不一定是壞事，儘管這使得攻擊者發現潛在目標要容易得多。真正的問題發生在一個單位沒有使用公用/私用DNS機制來分割外部公用DNS信息和內部私用DNS信息的時候，此時內部主機名和IP地址都暴露給了攻擊者。把內部IP地址信息提供給因特網上不受信任的用戶，就像是把一個單位的內部網絡完整藍圖或導航圖奉送給了別人。
使用dig工具可以檢測dns 區域傳送漏洞，語法如下：
dig axfr @域名服務器 被檢測域名
示例：
root@kali-xuanhun:~# dig @wormhole.movie.edu movie.edu axfr
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @wormhole.movie.edu movie.edu axfr
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
root@kali-xuanhun:~# dig axfr @ns12.zoneedit.com zonetransfer.me
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> axfr @ns12.zoneedit.com zonetransfer.me
; (1 server found)
;; global options: +cmd
zonetransfer.me. 7200 IN SOA ns16.zoneedit.com. soacontact.zoneedit.com. 2013064418 2400 360 1209600 300
zonetransfer.me. 7200 IN NS ns16.zoneedit.com.
zonetransfer.me. 7200 IN NS ns12.zoneedit.com.
zonetransfer.me. 7200 IN A 217.147.180.162
zonetransfer.me. 7200 IN MX 0 ASPMX.L.GOOGLE.COM.
zonetransfer.me. 7200 IN MX 10 ALT1.ASPMX.L.GOOGLE.COM.
zonetransfer.me. 7200 IN MX 10 ALT2.ASPMX.L.GOOGLE.COM.
zonetransfer.me. 7200 IN MX 20 ASPMX2.GOOGLEMAIL.COM.
zonetransfer.me. 7200 IN MX 20 ASPMX3.GOOGLEMAIL.COM.
zonetransfer.me. 7200 IN MX 20 ASPMX4.GOOGLEMAIL.COM.
zonetransfer.me. 7200 IN MX 20 ASPMX5.GOOGLEMAIL.COM.
zonetransfer.me. 301 IN TXT "Remember to call or email Pippa on +44 123 4567890 or [email protected] when making DNS changes"
zonetransfer.me. 301 IN TXT "google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA"
testing.zonetransfer.me. 301 IN CNAME www.zonetransfer.me.
164.180.147.217.in-addr.arpa.zonetransfer.me. 7200 IN PTR www.zonetransfer.me.
ipv6actnow.org.zonetransfer.me. 7200 IN AAAA 2001:67c:2e8:11::c100:1332
asfdbauthdns.zonetransfer.me. 7900 IN AFSDB 1 asfdbbox.zonetransfer.me.
office.zonetransfer.me. 7200 IN A 4.23.39.254
owa.zonetransfer.me. 7200 IN A 207.46.197.32
info.zonetransfer.me. 7200 IN TXT "ZoneTransfer.me service provided by Robin Wood - [email protected]. See www.digininja.org/projects/zonetransferme.php for more information."
asfdbbox.zonetransfer.me. 7200 IN A 127.0.0.1
canberra_office.zonetransfer.me. 7200 IN A 202.14.81.230
asfdbvolume.zonetransfer.me. 7800 IN AFSDB 1 asfdbbox.zonetransfer.me.
email.zonetransfer.me. 2222 IN NAPTR 1 1 "" "E2U+email" "" email.zoneedit.com.zonetransfer.me.
dzc.zonetransfer.me. 7200 IN TXT "AbCdEfG"
dr.zonetransfer.me. 300 IN LOC 53 20 56.558 N 1 38 33.526 W 0.00m 1m 10000m 10m
rp.zonetransfer.me. 321 IN RP robin.zonetransfer.me.zonetransfer.me. robinwood.zonetransfer.me.
sip.zonetransfer.me. 3333 IN NAPTR 2 3 "au" "E2U+sip" "!^.*$!sip:[email protected]!" .
alltcpportsopen.firewall.test.zonetransfer.me. 301 IN A 127.0.0.1
www.zonetransfer.me. 7200 IN A 217.147.180.162
staging.zonetransfer.me. 7200 IN CNAME www.sydneyoperahouse.com.
deadbeef.zonetransfer.me. 7201 IN AAAA dead:beaf::
robinwood.zonetransfer.me. 302 IN TXT "Robin Wood"
vpn.zonetransfer.me. 4000 IN A 174.36.59.154
_sip._tcp.zonetransfer.me. 14000 IN SRV 0 0 5060 www.zonetransfer.me.
dc_office.zonetransfer.me. 7200 IN A 143.228.181.132
zonetransfer.me. 7200 IN SOA ns16.zoneedit.com. soacontact.zoneedit.com. 2013064418 2400 360 1209600 300
;; Query time: 425 msec
;; SERVER: 209.62.64.46#53(209.62.64.46)
;; WHEN: Tue Dec 24 14:12:21 2013
;; XFR size: 37 records (messages 37, bytes 2673)
小結
運用DNS信息探測，結合社會工程方法，我們可以得到關於網站擁有者、服務器基本組織結構等方面的信息。
我故意淡化了各種工具的詳細使用方法，因爲如果把每種工具都詳細的羅列出來篇幅過長，同時也沒這個必要，讀者可以很方便的在網絡上找到每種工具的使用手冊。
DNS記錄類型有幾十種，我這裏只是列出我認爲重要的信息，希望讀者能查看我給出的鏈接。