注：本篇博客大部分內容截選自阮一峯老師的DNS 原理入門一文。其中少部分內容是博主自己的理解。
什麼是DNS
我們知道，網絡本身只能理解數字形式的地址，也就是IP地址。但是直觀的IP地址毫無規律，很難讓人記住，並且如果使用IP地址瀏覽一個公司的主頁，意味着這家公司一旦將主頁移動到了另一臺機器上，且該機器具有不同的IP地址，那麼必須將該機器的IP地址通知給每一個人。因此人們引入了類似於www.baidu.com這樣的域名。而要將域名轉換爲對應的IP地址，就需要DNS服務器（Domain Name System）。
在早期的ARPANET時代，只有一個簡單的hosts.txt文件，它列出了所有的計算機名字和其對應的IP地址。每天晚上，所有的主機都從一個維護此文件的站點將該文件取回，然後在本地進行更新。對於一個擁有幾百臺大型分時機器的網絡而言，這種方法工作的相當好。
然而當幾百萬臺PC連接到互聯網以後，問題就出現了。首先這個文件會變的非常大，並且主機名衝突的現象將會頻繁發生。爲了解決這些問題，DNS服務器應運而生。
注：DNS服務器和域名服務器同義。
查詢過程
雖然只需要返回一個IP地址，但是DNS的查詢過程非常複雜，分成多個步驟。
工具軟件dig可以顯示整個查詢過程。
dig math.stackexchange.com上面的命令會輸出六段信息：
;;開頭的表示這一行是註釋。
1. 第一段是查詢參數和統計。可以看到dig命令的一些基本信息，如版本和參數說明。還有一些對查詢結果的簡單統計：
2. 第二段是查詢內容：
上面結果表示，查詢域名math.stackexchange.com的A記錄，A是address的縮寫，也就是查詢域名的IP地址。
3. 第三段是DNS服務器的答覆：
我們將上述圖片中的每一行記錄稱爲域名資源記錄，DNS數據庫就是由這些記錄所構成。最常見的資源記錄就是它的IP地址，但除此之外還有許多其他種類的資源記錄。當解析器把一個域名傳給DNS時，它能獲得的DNS返回結果就是與該域名相關聯的資源記錄。
因此，DNS的基本功能是將域名映射至資源記錄。
我們來看一下資源記錄的格式：五元組。
Domain_name Time_to_live Class Type Value
- Domain_name（域名）：這條資源記錄屬於哪一個域
- Time_to_live（生存期）：TTL值，表示緩存時間，在上圖中就是600秒之內不用重新查詢
- Class（類別）：對於Internet信息，它總是IN。對於非Internet信息，則可以使用其他的代碼，但實際很少見
- Type（類型）：指出了本條資源記錄是什麼樣的類型。DNS有許多類型，我們在DNS的記錄類型進行詳細討論
- Value：可以是數字、域名、ASCII字符串，其取決於資源記錄的類型
那麼上面結果就顯示，math.stackexchange.com有四個A記錄，即四個IP地址。600是TTL值，表示緩存時間，即600秒之內不用重新查詢。
4. 第四段顯示stackexchange.com的NS記錄（Name Server的縮寫），即哪些服務器負責管理stackexchange.com的DNS記錄：
上面結果顯示stackexchange.com共有四條NS記錄，即四個域名服務器，向其中任一臺查詢就能知道math.stackexchange.com的IP地址是什麼。
這裏有一些分級查詢的內容，我們稍後在講。我們此時應該注意爲什麼stackexchange.com有四臺域名服務器？
在理論上，一臺域名服務器就足以。但實際上，這臺服務器有可能會因負載過重而變得毫無用處。而且，一旦它停機，則域名必然會解析失敗。這就是單個信息源所帶來的問題。
5. 第五段是上面四個域名服務器的IP地址，這是隨着前一段一起返回的：
6. 第六段是DNS服務器的一些傳輸信息：
上面結果顯示，本機的DNS服務器是192.168.1.253，查詢端口是53（DNS服務器的默認端口），以及迴應長度是305字節。
如果不想看到這麼多內容，可以使用+short參數：
dig +short math.stackexchange.com
151.101.129.69
151.101.65.69
151.101.193.69
151.101.1.69上面命令只返回math.stackexchange.com對應的4個IP地址（即A記錄）。
DNS服務器
下面我們根據前面這個例子，一步步還原，本機到底怎麼得到域名math.stackexchange.com的IP地址。
首先，本機一定要知道DNS服務器的IP地址，否則上不了網。通過DNS服務器，才能知道某個域名的IP地址到底是什麼。
除了本地DNS服務器。有一些公網的DNS服務器，也可以使用，其中最有名的就是Google的8.8.8.8和Level 3的4.2.2.2。
本機只向自己的DNS服務器查詢，dig命令有一個@參數，顯示向其他DNS服務器查詢的結果。
dig @4.2.2.2 math.stackexchange.com上面命令指定向DNS服務器4.2.2.2查詢。
域名層級
DNS服務器怎麼會知道每個域名的IP地址呢？答案是分級查詢。
請仔細看前面的例子，每個域名的尾部都多了一個點。
比如，域名math.stackexchange.com顯示爲math.stackexchange.com.。這不是疏忽，而是所有域名的尾部，實際上都有一個根域名。
舉例來說，www.example.com真正的域名是www.example.com.root，簡寫爲www.example.com.。因爲，根域名.root對於所有域名都是一樣的，所以平時是省略的。
根域名的下一級，叫做”頂級域名”（top-level domain，縮寫爲TLD），比如.com、.net；再下一級叫做”次級域名”（second-level domain，縮寫爲SLD），比如www.example.com裏面的.example，這一級域名是用戶可以註冊的（可以瞭解一下域名搶注問題）；再下一級是主機名（host），比如www.example.com裏面的www，又稱爲”三級域名”，這是用戶在自己的域裏面爲服務器分配的名稱，是用戶可以任意分配的。
總結一下，域名的層級結構如下：
主機名.次級域名.頂級域名.根域名
# 即
host.sld.tld.root根域名服務器
DNS服務器根據域名的層級，進行分級查詢。
需要明確的是，每一級域名都有自己的NS記錄，NS記錄指向該級域名的域名服務器。這些服務器知道下一級域名的各種記錄。
所謂“分級查詢”，就是從根域名開始，依次查詢每一級域名的NS記錄，直到查到最終的IP地址，過程大致如下：
- 從根域名服務器查到頂級域名服務器的NS記錄和A記錄（IP地址）
- 從頂級域名服務器查到次級域名服務器的NS記錄和A記錄（IP地址）
- 從次級域名服務器查出主機名的IP地址
仔細看上面的過程，你可能發現了，沒有提到DNS服務器怎麼知道根域名服務器的IP地址。回答是根域名服務器的NS記錄和IP地址一般是不會變化的，所以內置在本地DNS服務器裏面。
下面是內置的根域名服務器IP地址的一個例子：
上面列表中，列出了根域名（.root）的三條NS記錄A.ROOT-SERVERS.NET、B.ROOT-SERVERS.NET和C.ROOT-SERVERS.NET，以及它們的IP地址（即A記錄）198.41.0.4、192.228.79.201、192.33.4.12。
另外，可以看到所有記錄的TTL值是3600000秒，相當於1000小時。也就是說，每1000小時才查詢一次根域名服務器的列表。
目前，世界上一共有十三組根域名服務器，從A.ROOT-SERVERS.NET一直到M.ROOT-SERVERS.NET。
分級查詢實例
dig命令的+trace參數可以顯示DNS的整個分級查詢過程。
dig +trace math.stackexchange.com上面命令的第一段列出根域名.的所有NS記錄，即所有根域名服務器：
根據內置的根域名服務器IP地址，DNS服務器向所有這些IP地址發出查詢請求，詢問math.stackexchange.com的頂級域名服務器com.的NS記錄。最先回復的根域名服務器將被緩存（緩存到本地DNS服務器上），以後只向這臺服務器發請求。
接着是第二段：
上面結果顯示.com域名的13條NS記錄，同時返回的還有每一條記錄對應的IP地址。
然後，DNS服務器向這些頂級域名服務器發出查詢請求，詢問math.stackexchange.com的次級域名stackexchange.com的NS記錄：
上面結果顯示stackexchange.com有四條NS記錄，同時返回的還有每一條NS記錄對應的IP地址。
然後，DNS服務器向上面這四臺NS服務器查詢math.stackexchange.com的主機名：
上面結果顯示，math.stackexchange.com有4條A記錄，即這四個IP地址都可以訪問到網站。並且還顯示，最先返回結果的NS服務器是ns-463.awsdns-57.com，IP地址爲205.251.193.207。
在分級查詢的過程中，還有2個技術要點值得討論。
遞歸查詢與迭代查詢
我們再來補充一些概念：
- 域名解析：查詢一個域名和找出其對應地址的過程
- 本地DNS服務器：參考知乎—本地DNS服務器的作用
先拋開分級查詢不說，DNS的使用方法大致如下：爲了將一個域名映射成IP地址，應用程序調用一個名爲解析器的庫程序，並將域名作爲參數傳遞給此程序。然後解析器向本地DNS服務器發送一個包含該名字的請求報文；本地DNS服務器查詢該名字，並且返回一個包含該名字對應IP地址的響應報文給解析器，然後解析器再將IP地址返回給調用方。
但是如果我們要查詢的域名在遠端，即本地DNS服務器沒有相關域名的緩存信息，那麼域名服務器就會進行一次遠程查詢，而遠程查詢的過程，則對應我們上面所說的分級查詢。圖表形式如下：
- 遞歸查詢
- 主機向本地域名服務器的查詢一般都是採用遞歸查詢。
- 所謂遞歸查詢就是：如果主機所詢問的本地域名服務器不知道被查詢的域名的IP地址，那麼本地域名服務器就以DNS客戶的身份，向其它域名服務器繼續發出查詢請求報文(即替主機繼續查詢)，而不是讓主機自己進行下一步查詢。因此，遞歸查詢返回的查詢結果或者是所要查詢的IP地址，或者是報錯，表示無法查詢到所需的IP地址。
- 迭代查詢
- 當根域名服務器收到本地域名服務器發出的迭代查詢請求報文時，要麼給出所要查詢的IP地址，要麼告訴本地服務器：“你下一步應當向哪一個域名服務器進行查詢”。然後讓本地服務器進行後續的查詢。根域名服務器通常是把自己知道的頂級域名服務器的IP地址告訴本地域名服務器，讓本地域名服務器再向頂級域名服務器查詢。頂級域名服務器在收到本地域名服務器的查詢請求後，要麼給出所要查詢的IP地址，要麼告訴本地服務器下一步應當向哪一個次級域名服務器進行查詢… …最後，知道了所要解析的IP地址或報錯，然後把這個結果返回給發起查詢的主機。
由上圖可知，DNS域名系統同時涉及了兩種機制。如果採用單一的迭代查詢方式，則查詢過程如下：
可以看到，如果使用單一的迭代查詢，DNS客戶端將變的異常繁忙，CPU資源被搶佔，用戶體驗將會下降。
通過結合使用遞歸查詢與迭代查詢，將DNS查詢的重擔交給本地DNS服務器，客戶端就可以在DNS查詢的過程中幹自己想幹的事情。
總結：
- 遞歸：客戶端只發一次請求，要求對方給出最終結果。
- 迭代：客戶端發出一次請求，對方如果沒有授權回答，它就會返回一個能解答這個查詢的其它名稱服務器列表，客戶端會再向返回的列表中發出請求，直到找到最終負責所查域名的名稱服務器，從它得到最終結果。
從遞歸和迭代查詢可以看出：
- 客戶端—本地DNS服務端：這部分屬於遞歸查詢。
- 本地dns服務端—外網：這部分屬於迭代查詢。
DNS的記錄類型
域名與IP之間的對應關係，稱爲”記錄”（record）。根據使用場景，“記錄”可以分成不同的類型（type），前面已經看到了有A記錄和NS記錄。
常見的DNS記錄類型如下：
- A：地址記錄（Address），返回域名指向的IPv4地址。
- AAAA：地址記錄（Address），返回域名指向的IPv6地址。
- NS：域名服務器記錄（Name Server），返回保存下一級域名信息的服務器地址。該記錄只能設置爲域名，不能設置爲IP地址。
- MX：郵件記錄（Mail eXchange），返回接收電子郵件的服務器地址。
- CNAME：規範名稱記錄（Canonical Name），返回另一個域名，即當前查詢的域名是另一個域名的跳轉，詳見下文。
- PTR：逆向查詢記錄（Pointer Record），只用於從IP地址查詢域名，詳見下文。
一般來說，爲了服務的安全可靠，至少應該有兩條NS記錄，而A記錄和MX記錄也可以有多條，這樣就提供了服務的冗餘性，防止出現單點失敗。
CNAME記錄主要用於域名的內部跳轉，爲服務器配置提供靈活性，用戶感知不到。舉例來說，facebook.github.io這個域名就是一個CNAME記錄：
dig facebook.github.io
...
;; ANSWER SECTION:
facebook.github.io. 3370 IN CNAME github.map.fastly.net.
github.map.fastly.net. 600 IN A 103.245.222.133上面結果顯示，facebook.github.io的CNAME記錄指向github.map.fastly.net。也就是說，用戶查詢facebook.github.io的時候，實際上返回的是github.map.fastly.net的IP地址。這樣的好處是，變更服務器IP地址的時候，只要修改github.map.fastly.net這個域名就可以了，用戶的facebook.github.io域名不用修改。
由於CNAME記錄就是一個替換，所以域名一旦設置CNAME記錄以後，就不能再設置其他記錄了（比如A記錄和MX記錄），這是爲了防止產生衝突。舉例來說，foo.com指向bar.com，而兩個域名各有自己的MX記錄，如果兩者不一致，就會產生問題。由於頂級域名通常要設置MX記錄，所以一般不允許用戶對頂級域名設置CNAME記錄。
PTR記錄用於從IP地址反查域名。dig命令的-x參數用於查詢PTR記錄：
dig -x 192.30.252.153
...
;; ANSWER SECTION:
153.252.30.192.in-addr.arpa. 3600 IN PTR pages.github.com.逆向查詢的一個應用，是可以防止垃圾郵件，即驗證發送郵件的IP地址，是否真的有它所聲稱的域名。
dig命令可以查看指定的記錄類型：
dig a github.com
dig ns github.com
dig mx github.com總結
- 熟悉DNS的查詢過程：分級查詢；
- 熟悉分級查詢中，遞歸查詢與迭代查詢的概念及使用場景；
- 熟悉本地DNS服務器的作用，瞭解DNS緩存機制；
- 掌握資源記錄的格式：五元組；
- 掌握域名層級的概念：根域名、頂級域名、次級域名、主機名；
- 瞭解DNS的記錄類型。
參考閱讀
計算機網絡（第五版）— Andrew S.Tanenbaum、David J.Wetherall