1.DNS概述
域名系統DNS(Domain Name System)是因特網使用的命名系統，用來把便於人們使用的機器名字（如淘寶、百度、騰訊等）轉換爲IP地址。域名系統很明確地指明這種系統是用在因特網中。
用戶與因特網中某個主機通信時，必須要知道對方的IP地址。然而用戶很難記住長達32位二進制主機地址，在應用層爲了便於用戶記憶各種網絡應用，更多使用主機名字。但是，機器在處理IP數據報時，並不是使用域名而是使用IP地址。這是因爲IP地址長度固定，而域名的長度不固定，機器處理起來比較困難。
因爲因特網規模很大，所以整個因特網只使用一個域名服務器是不可行的。因此，早在1983年因特網開始採用層次樹狀結構的命名方法，並使用分佈式的域名系統DNS，採用客戶服務器方式。DNS使大多數名字都在本地解析(resolve)，僅有少量解析需要在因特網上通信，因此DNS系統的效率很高。由於DNS是分佈式系統，即使單個計算機除了故障，也不會妨礙整個DNS系統的正常運行
1.1 域名結構
採用層次樹狀的命名方法，任何一臺連接在因特網上的主機或者路由器，都有一個唯一的層次結構的名字，即域名(domain name)
域名解析是一個從右向左，由大向小的的過程
2.DNS報文分析
2.1 DNS報文格式
數據報文如下：
以下三個在響應報文中出現
- Answers
服務器到客戶端的回答
- Authoritative nameservers
給出權限服務器的相關信息
- Additional recoreds
提供輔助的附加信息
2.1.1 Transcation ID標識
用於識別響應報文與查詢報文的對應
2.1.2 Flags標誌
每個字段的含義解析如下：
- QR
查詢/響應標誌，0爲查詢，1爲響應
- opcode
0表示標準查詢
1表示反向查
2表示服務器狀態請
3-15爲保留值
- AA（1bit）
Authoritative Answer
是否權威應答
權威應答就是權威服務器給出的域名解析。權威服務器就是這個域名的“源解析服務器”也是最權威的解析
- TC（1bit）
（TrunCation） 是否可截斷的
因爲一個UDP報文爲512字節，所以該位指示是否截斷超過的部分
- RD
Recursion Desired 是否請求遞歸
這個比特位被請求設置，應答的時候使用的相同的值返回
- RA（1bit）
Recursion Available 由DNS回覆返回指定，說明DNS服務器是否支持遞歸查詢
這個比特位在應答中設置或取消
- zero
第10-12位，保留位（設置爲0）
- rcode（4bit）
Response Code
0：沒有錯誤
1：格式錯誤
2：服務器錯誤
3：名字錯誤
4：服務器不支持
5：拒絕
6-15：保留值
2.1.3 其他頭部字段
- Questions（2字節）：報文請求段中的問題記錄數；
- AnswerRRs（2字節）： 報文回答段中的回答記錄數；
- AuthorityRRs（2字節）： 報文授權段中的授權記錄數；
- AdditionalRRs(2字節) ：報文附加段中的附加記錄數；
2.1.4 查詢區域
- 查詢類型
常用的查詢類型有以下幾種:
A:由域名獲得IPv4地址，值爲1
NS:查詢域名服務器，值爲2
CNAME:獲得目標主機的別名，值爲5
PTR：把IP地址轉換成域名，值爲12
AAAA:由域名獲得IPv6地址，值爲28
- 查詢類
通常爲1，表明是Internet數據,共2個字節，比如，IN代表Internet
2.1.5 資源記錄區域
- 域名
一般情況下，當響應報文中出現相同的域名時，使用指針偏移法，當然也可以不使用指針偏移法，具體使用哪一種域名錶式法進行響應，與Query查詢端要求有關，如：查詢的時候要求服務器以指針偏移方式響應域名，則響應端則使用指針偏移法進行響應
- 元信息表示法
（即：非壓縮方式lable）以標識符的字節數開頭，以00結尾，如：www.baidu.com,其可以表示（ASCII碼錶中對應的十六進制）成03 77 77 77 05 62 61 69 64 75 03 63 6F 6D 00
- 指針偏移法：
目的是在出現了相同的域名時，使用指針偏移法節省空間
（即：壓縮方式poniter） 響應報文中其資源記區域的域名最高爲11，即C開頭的，如0xC00C(1100000000001100)除去最高爲11，Offset其他14位表示指針偏移量（表示偏移DNS報文頭部的字節數。偏移量爲0表示ID字段的第一個字節），如0xC00C表示其offset偏移12字節，即頭部（2字節Name+2字節Type+2字節class+4字節TTL+2字節的資源數據長度）偏移到12字節，正好到了資源數據部分位置，即域名爲：www.baidu.com
如果爲0xc02b，則偏移43字節(從最開始的位置偏移43個),則03 77 77 77 01 61 06 73 68 69 65 6e c0 16,即別名爲:www.a.shifen.com
3. 混合方式：
以上兩種方式的結合
- TTL
生存時間（TTL）：以秒爲單位，表示的是資源記錄的生命週期，一般用於當地址解析程序取出資源記錄後決定保存及使用緩存數據的時間，它同時也可以表明該資源記錄的穩定程度，極爲穩定的信息會被分配一個很大的值（比如86400，這是一天的秒數）
- 資源數據
該字段是一個可變長字段，表示按照查詢段的要求返回的相關資源記錄的數據。可以是Address（表明查詢報文想要的迴應是一個IP地址）或者CNAME（表明查詢報文想要的迴應是一個規範主機名）等
3.傳輸
RFC文檔中指出，DNS同時支持端口53的TCP[RFC-793]和端口53的UDP [RFC-768]傳輸
- 報文長度考慮
UDP報文的最大長度爲512字節，而TCP則允許報文長度超過512字節。當DNS查詢超過512字節時，協議的TC標誌出現刪除標誌，這時則使用TCP發送。通常傳統的UDP報文一般不會大於512字節
- 區域傳輸的時候使用TCP協議
DNS的規範規定了2種類型的DNS服務器，一個叫主DNS服務器，一個叫輔助DNS服務器。在一個區中主DNS服務器從自己本機的數據文件中讀取該區的DNS數據信息，而輔助DNS服務器則從區的主DNS服務器中讀取該區的DNS數據信息。當一個輔助DNS服務器啓動時，它需要與主DNS服務器通信，並加載數據信息，這就叫做區傳送（zone transfer）
輔助域名服務器會定時（一般是3小時）向主域名服務器進行查詢以便了解數據是否有變動。如有變動，則會執行一次區域傳送，進行數據同步。區域傳送將使用TCP而不是UDP，因爲數據同步傳送的數據量比一個請求和應答的數據量要多得多。 而TCP傳輸數據的可靠性，保證了數據的準確性。
- 域名解析時使用UDP協議
客戶端向DNS服務器查詢域名，一般返回的內容都不超過512字節，用UDP傳輸即可。不用經過TCP三次握手，這樣DNS服務器負載更低，響應更快。雖然從理論上說，客戶端也可以指定向DNS服務器查詢的時候使用TCP，但事實上，很多DNS服務器進行配置的時候，僅支持UDP查詢包
4.實例演示
4.1 模擬域名解析
使用nslookup工具模式模擬域名解析
nslookup -q=A www.baidu.com
使用-q命令可以指定解析的協議類型
具體的WireShark抓包如下
4.2 查詢報文
4.3 響應報文
