詳解DNS遞歸查詢與疊代查詢

關于01月23日全國範圍内DNS污染，域名解析故障的根源，資深的IT人士都知道原因是什麼，并非國家

網際網路應急中心發出的遭受攻擊一說。

是以這裡介紹一下DNS伺服器的查詢原理，也就是遞歸查詢和疊代查詢。

下圖比較簡明的描述了DNS伺服器為用戶端解析主機www.163.com的全過程.

根域名伺服器:是網際網路域名解析系統（DNS）中最進階别的域名伺服器，全球有386台根伺服器,被編号為A到M共13個标号。中國北京有兩台編号為F的根伺服器鏡像，編号為I、J、L的各一，共5台鏡像，在香港有A、F、I、J、L五台根伺服器鏡像，全部借由任播（Anycast）技術，所有編号相同的根伺服器都是同一個IP，386台根伺服器總共隻使用了13個IP，是以可以抵抗針對其所進行的分布式拒絕服務攻擊(DDoS)。

根域名伺服器清單: (a-m.root-servers.net)

用戶端通過域名通路站點時，必須要有DNS伺服器解析到指定的IP位址上，才能進行下一步的

通路。用戶端發起通路請求後，首先檢查本地host檔案，檢查是否存在對應的IP映射關系，如果有則

直接通過映射的IP進行通路；如果沒有則将請求發送給首選的DNS伺服器。

用戶端和DNS伺服器之間使用的是遞歸查詢，而DNS伺服器之間使用的是疊代查詢.

遞歸查詢時要求所請求的DNS伺服器應答給用戶端所請求的域名和IP的映射關系;

疊代查詢時所請求的DNS伺服器應答給用戶端的不一定是域名和IP位址的映射關系，也可以是另一台

DNS伺服器，讓用戶端再将請求發送到另一台DNS伺服器.

下面按上圖根據執行個體介紹DNS解析全過程.

用戶端發起通路請求www.163.com:

1.檢視本地hosts檔案，發現沒有www.163.com IP 映射關系，将請求發送給本地DNS伺服器

----遞歸查詢----

2.本地DNS伺服器不包含163.com的權威域，不存在對應的www記錄，是以将請求轉發到根域名伺服器

(假如 a.root-servers.net.)

3.根域名DNS伺服器會傳回負責.com域解析的伺服器(假如 a.gtld-servers.net.)給本地DNS伺服器，

本地DNS伺服器再将請求發送給 a.gtld-servers.net

4..com域名伺服器隻能傳回負責163.com域的解析伺服器(如 ns1.nease.net.)給本地DNS伺服器,本地

DNS伺服器再将請求發送給ns1.nease.net.

5.由ns1.nease.net.域名伺服器傳回www.163.com 的 IP映射關系給本地DNS伺服器

(2-5過程)----疊代查詢----

6.本地DNS伺服器将結果儲存到本地緩存，并保持TTL時間，同時将結果應答給用戶端.

----遞歸查詢---- ----查詢結束----

7.當其他用戶端再次向本地DNS伺服器查詢www.163.com時，在TTL時間内，本地DNS伺服器不再向根

域名伺服器轉發請求，而是直接從緩存中讀取資料應答給用戶端. 如果已經超過TTL時間，則本地DNS

伺服器會再次經曆一次上訴2-6的過程.

本地DNS伺服器在代替用戶端向其他伺服器查詢時，用戶端完全處于等待狀态。

遞歸查詢時，傳回的結果隻有兩種:查詢成功或查詢失敗.

疊代查詢，又稱作重指引,傳回的是最佳的查詢點或者主機位址.

了解了以上原理,就可以很容易的判斷DNS解析故障了，甚至于前日的全國DNS污染問題。

當然了解原理後，還需要了解相關的工具和指令: dig,nslookup,host等.其中以dig指令的功能最為強大和靈活.

dig指令典型應用形如

dig @server name type

@server: 指定域名伺服器

name:指定查詢請求資源的域名

type:指定查詢類型，如A、CNAME、SRV、MX、SIG等，如果不指定type，預設為A

比如:

預設情況下DNS使用UDP查詢，我們使用查詢選項設定為TCP查詢

<code>[shizhenning@zabbix ~]$ </code><code>dig</code> <code>@8.8.8.8 163.com +tcp</code>

<code>; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> @8.8.8.8 163.com +tcp</code>

<code>; (1 server found)</code>

<code>;; global options: printcmd</code>

<code>;; Got answer:</code>

<code>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, </code><code>id</code><code>: 36041</code>

<code>;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0</code>

<code>;; QUESTION SECTION:</code>

<code>;; ANSWER SECTION:</code>

<code>;; Query </code><code>time</code><code>: 54 msec</code>

<code>;; SERVER: 8.8.8.8</code><code>#53(8.8.8.8)</code>

查詢MX記錄:

<code>[shizhenning@zabbix ~]$ </code><code>dig</code> <code>@8.8.8.8 163.com MX</code>

<code>; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> @8.8.8.8 163.com MX</code>

<code>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, </code><code>id</code><code>: 41000</code>

<code>;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0</code>

<code>163.com. 13741 IN MX 50 163mx00.mxmail.netease.com.</code>

<code>163.com. 13741 IN MX 10 163mx01.mxmail.netease.com.</code>

<code>163.com. 13741 IN MX 10 163mx02.mxmail.netease.com.</code>

<code>163.com. 13741 IN MX 10 163mx03.mxmail.netease.com.</code>

<code>;; Query </code><code>time</code><code>: 41 msec</code>

查詢CNAME記錄:

<code>[shizhenning@zabbix ~]$ </code><code>dig</code> <code>@8.8.8.8 www.163.com CNAME</code>

<code>; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> @8.8.8.8 www.163.com CNAME</code>

<code>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, </code><code>id</code><code>: 27024</code>

<code>;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0</code>

<code>;www.163.com. IN CNAME</code>

<code>www.163.com. 347 IN CNAME www.163.com.lxdns.com.</code>

查詢DRV記錄:

<code>[shizhenning@zabbix ~]$ </code><code>dig</code> <code>@8.8.8.8 163.com SRV</code>

<code>; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> @8.8.8.8 163.com SRV</code>

<code>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, </code><code>id</code><code>: 41227</code>

<code>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0</code>

<code>;; AUTHORITY SECTION:</code>

<code>163.com. 1800 IN SOA ns4.nease.net. admin.nease.net. 20130823 7200 1800 1209600 3600</code>

<code>;; Query </code><code>time</code><code>: 137 msec</code>

我們要查詢某個域名解析的全過程:(此時為疊代查詢)

<code>[shizhenning@zabbix ~]$ </code><code>dig</code> <code>@8.8.8.8 163.com +trace</code>

<code>; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> @8.8.8.8 163.com +trace</code>

<code>. 19586 IN NS a.root-servers.net.</code>

<code>. 19586 IN NS b.root-servers.net.</code>

<code>. 19586 IN NS c.root-servers.net.</code>

<code>. 19586 IN NS d.root-servers.net.</code>

<code>. 19586 IN NS e.root-servers.net.</code>

<code>. 19586 IN NS f.root-servers.net.</code>

<code>. 19586 IN NS g.root-servers.net.</code>

<code>. 19586 IN NS h.root-servers.net.</code>

<code>. 19586 IN NS i.root-servers.net.</code>

<code>. 19586 IN NS j.root-servers.net.</code>

<code>. 19586 IN NS k.root-servers.net.</code>

<code>. 19586 IN NS l.root-servers.net.</code>

<code>. 19586 IN NS m.root-servers.net.</code>

<code>;; Received 228 bytes from 8.8.8.8</code><code>#53(8.8.8.8) in 62 ms</code>

<code>com. 172800 IN NS m.gtld-servers.net.</code>

<code>com. 172800 IN NS l.gtld-servers.net.</code>

<code>com. 172800 IN NS k.gtld-servers.net.</code>

<code>com. 172800 IN NS j.gtld-servers.net.</code>

<code>com. 172800 IN NS i.gtld-servers.net.</code>

<code>com. 172800 IN NS h.gtld-servers.net.</code>

<code>com. 172800 IN NS g.gtld-servers.net.</code>

<code>com. 172800 IN NS f.gtld-servers.net.</code>

<code>com. 172800 IN NS e.gtld-servers.net.</code>

<code>com. 172800 IN NS d.gtld-servers.net.</code>

<code>com. 172800 IN NS c.gtld-servers.net.</code>

<code>com. 172800 IN NS b.gtld-servers.net.</code>

<code>com. 172800 IN NS a.gtld-servers.net.</code>

<code>;; Received 485 bytes from 198.41.0.4</code><code>#53(a.root-servers.net) in 134 ms</code>

<code>163.com. 172800 IN NS ns2.nease.net.</code>

<code>163.com. 172800 IN NS ns3.nease.net.</code>

<code>163.com. 172800 IN NS ns4.nease.net.</code>

<code>163.com. 172800 IN NS ns5.nease.net.</code>

<code>163.com. 172800 IN NS ns6.nease.net.</code>

<code>163.com. 172800 IN NS ns1.nease.net.</code>

<code>;; Received 238 bytes from 192.55.83.30</code><code>#53(m.gtld-servers.net) in 137 ms</code>

<code>;; Received 270 bytes from 114.113.197.12</code><code>#53(ns2.nease.net) in 34 ms</code>

掌握dig指令後,DNS解析故障就很容易排查了.

關于域名伺服器緩存污染隻是一種技術，沒有對錯之分，有時我們企業内部也需要刻意使用這種技術

本文轉自marbury 51CTO部落格，原文連結：http://blog.51cto.com/magic3/1354084，如需轉載請自行聯系原作者

詳解DNS遞歸查詢與疊代查詢

繼續閱讀

Redis單線程模型和IO多路複用

網絡連接配接錯誤代碼大全及解決方法

HTTP 錯誤 403.9 - 禁止通路：連接配接的使用者過多 XP IIS伺服器連接配接數的修改

TCP和UDP傳輸的深入淺析,MSN和QQ檔案傳輸速度解析

UECapabilityInformation中bandEUTRA 64的含義

網絡通信原理OSI參考模型TCP/IP協定簇數值轉換IP位址分類子網路遮罩

QQ for Linux釋出帶來的感想。

vue-loader-v16/package.json報錯

ZooKeeper ： Curator架構之資料緩存與監聽CuratorCache

事務（髒讀，不可重複讀，虛讀）

華為交換機與中興交換機結合配置MSTP執行個體

Socket套接字類 AS3

2.6核心netfilter包截獲

網絡協定之網頁資料包到伺服器的傳輸過程

圖解HTTP八：确認通路使用者身份的認證

在一個非套接字上嘗試了一個操作