主要參考內容為RFC 1034、1035（簡略參考，需要時再去閱讀）還有以下博客參考
本文只是簡略總結學習DNS協議的要點。
DNS協議思想
總結下來就是核心是分層式的思想。有以下幾個點：
-
分層式結構自然引出樹結構，樹的每一個父節點只負責管理子節點的信息。
-
節點的表示引出域名概念，按照RFC文檔的規定，域名是0-63個字節的在指定字符范圍內的標簽，其中最特殊的0個字節缺省為根節點專屬的域名。
-
最終的主機名，是一個從根節點到達葉節點的自頂向下路徑，並且路徑上相鄰父子節點之間通過.分隔，形成對人類友好的字符串形式。
-
在DNS報文中，主機名將其中的點號分割替換為，通過表明域名長度的數字分割。顯然結尾是0，以表示到達根節點，在此也可以看出，利用NULL作為根節點表示，是為了方便DNS報文中表示主機名結尾。
-
域名服務器，是域名父節點管理其子節點信息的實際執行者。一般分為根服務器，頂級域名服務器，權威服務器
而DNS協議解析，根據RFC 1034的說法，是通過resolver完成的，實際上過程是這樣的。
- 對於迭代查詢：
- 客戶端選擇代理服務器，讓他完成所有查詢任務。
- DNS代理服務器完成如下操作，以下為比喻。
- DNS代理服務器中預先有根服務器主機名以及其IP地址，因此去到根節點上，在已知需要解析的主機名，因此，我可以推斷出下一級的域名，也就是下一個要去子節點的標簽，而當前根節點具有的恰好就是所有他管理的子節點信息。
- 子節點信息主要是，子節點的主機名是什么？子節點的IP地址是什么？這解決了是誰，在哪里的問題。
- 之后代理服務器就跑去這個查出來的子節點，這時候，根據樹是遞歸定義出來的，當前的節點到達我想到達的最終主機之間又可以看作一棵樹，那么我就還讓代理服務器按照先前的方式不斷地問，知道遇到了葉子節點IP地址。
- 此時，代理服務器完成任務，就把查出來的IP地址返回給客戶端。
- 對於遞歸查詢：
- 客戶端選擇代理服務器，讓他完成所有查詢任務。
- DNS代理服務器完成如下操作，以下為比喻。
- 此時，查詢就像一個甩鍋的過程，先前除了代理服務器，所有服務器都是詢問-回答的狀態，而遞歸查詢則是，代理服務器把查詢任務丟給了根服務器，根服務器認出這是遞歸查詢，就跑到有這個需要解析的路徑分析出的子節點所在處（事實上，他只知道他的子節點，他查詢時候能管的也只有他的子節點），把任務丟給子節點，然后，就靜靜等待子節點完成交差，等到子節點完成后，就把這個最終的結果還給代理服務器。
- 每一級都是如此，把任務甩給下一節點，靜靜等待下一節點完成后，在還給之前給自己指派任務的服務器，也可以理解為，每一個下一節點的DNS服務器，都被當作了一個代理服務器。
每次這么來一遍，效率很低，考慮到現實中一個地址可能要問好幾次，比如，學生選課，期間，選課官網在一段時間內，肯定是高頻訪問，那么如果代理服務器有存儲先前的結果，那就不必大費周章的從頭推導，直接背書完了。當然了，每次都要有新知識的流入，比如過一段時間，LOL S賽直播，整個大學就開始需要直播間的地址，所以，就得忘掉舊知識，不然屯的都是舊知識，沒有把新知識背住，新知識用起來就很麻煩。這就是DNS服務器緩存服務器的概念，以及TTL的由來。
DNS報文格式
因特網的協議，重要特色就是報文格式，格式化的交流方式，才可以使得因特網夠高效穩定。
頭部
- 會話標識（2 bytes）：請求報文與對應的應答報文整個是相同的，區分應答是針對哪一個詢問。
- 標志（2 bytes）：是一個標准的bit-wise的標識方法，每一位的意義如下
- QR (1 BIT): 查詢對應0，響應為1
- opcode(4 bits): 0-標准查詢，1-反向查詢，2-服務器狀態請求
- AA(1 BIT): 授權回答
- TC(1 BIT): 可截斷
- RD（1bit）：表示期望遞歸。
- RA（1bit）：表示可用遞歸。
- Z(3 bits): 全0
- rcode(4 bits): 應答，類似http的404，200之類的。
- 0 沒有錯誤。
- 1 報文格式錯誤(Format error) - 服務器不能理解請求的報文。
- 2 服務器失敗(Server failure) - 因為服務器的原因導致沒辦法處理這個請求。
- 3 名字錯誤(Name Error) - 只有對授權域名解析服務器有意義，指出解析的域名不存在。
- 4 沒有實現(Not Implemented) - 域名服務器不支持查詢類型。
- 5 拒絕(Refused) - 服務器由於設置的策略拒絕給出應答。比如，服務器不希望對某些請求者給出應答，或者服務器不希望進行某些操作（比如區域傳送zone transfer）。
- 6：本來應該沒有的域名，但是有
- 7：有一個資源記錄集存在，本來不應該有
- 8：有一個資源記錄集應該有，但它沒有
- 9：查詢的服務器並不權威
- 10：相關的信息並不是當前域存在的
- 數量字段，協議報文經常出現的部分。Questions、Answer RRs、Authority RRs、Additional RRs 各自表示后面的四個區域的數目。Questions表示查詢問題區域節的數量，Answers表示回答區域的數量，Authoritative namesversers表示授權區域的數量，Additional recoreds表示附加區域的數量。
正文
分為Queries 和 RR部分
Queries
-
查詢名NAME: 長度不固定，一般是需要查詢的主機名(uestc.edu.cn諸如此類)，如果是反向查詢，就是IP地址。格式如前所述，一個字節的數字標識域名的長度，並將整個主機名分割。
-
查詢類型，這是由RFC定義的RR 類型，起初只定義了一部分，隨着IPV6等問題，在之后的RFC文檔又定義了新的類型
| 類型 | 助記符 | 說明 |
|---|---|---|
| 1 | A | 由域名獲得IPv4地址 |
| 2 | NS | 查詢域名服務器 |
| 5 | CNAME | 查詢規范名稱 |
| 6 | SOA | 開始授權 |
| 11 | WKS | 熟知服務 |
| 12 | PTR | 把IP地址轉換成域名 |
| 13 | HINFO | 主機信息 |
| 15 | MX | 郵件交換 |
| 28 | AAAA | 由域名獲得IPv6地址 |
| 252 | AXFR | 傳送整個區的請求 |
| 255 | ANY | 對所有記錄的請求 |
- 查詢類：有chaos,internet，通常選internet，用1表示
資源記錄
包含回答，授權，附加三個區域，格式一致。其中回答是對詢問的響應，授權是權威服務器端信息，附加是可能有用的信息。
格式如下
- 既然是對於回答的應答，那也該有對應，所以按照此思路設計
- 域名：一種方式就是同Queries所陳述的一樣，但是，出現重復的情況，我們可以設置一個指針指向那個域名，節省空間。這種偏移指針的方式，長度為兩字節，最高兩位指定為11后，就能識別這是一個偏移指針，剩下14位就用於指出偏移地址，以DNS報文開頭為0
- 對應Queries的有查詢類型，查詢類
- 生存時間（TTL)：這就是之前提到的為了緩存服務器而設置的。
- 資源數據：前面鋪墊這么多，就需要干貨了。如果查詢要的是A型RR，那就返回IPV4地址，是一個CNAME的RR，那就返回一個規范主機名。