最近在CB上看到多篇存在關于DNS故障的文章，其中大多存在謬誤，讓人產生問題在于DNSPod，而暴風影音是無辜的受害者的錯覺。這里我覺得有必要出來說說DNSPod才是無辜受害者，錯全在暴風(還有黑客)。首先說說DNS是怎么注冊的：

    一個域名注冊成功以后上級域名的擁有者把這個域名的解析授權(Delegate)給用戶指定的域名服務器，此時該服務器成為該域的權威(Authoritative)服務器，一切到該域名的查詢以此服務器提供的結果為準。(也存在不授權只設置NS記錄的情況。)

    比如新浪注冊了sina.com，向VeriSign交了錢以后，VeriSign在他們的根域名服務器里面添加如下的記錄：

sina.com. 60 IN NS ns3.sina.com.cn.
sina.com. 60 IN NS ns1.sina.com.cn.
sina.com. 60 IN NS ns2.sina.com.cn.
ns1.sina.com.cn. 37305 IN A 202.106.184.166
ns2.sina.com.cn. 37305 IN A 61.172.201.254
ns3.sina.com.cn. 37305 IN A 202.108.44.55

    然后我們看如何解析：

    因為DNS是非常基礎的服務直接關系到網絡訪問的效率，所以DNS是采用多級緩存的方式運作的。通常一個程序發出DNS請求以后，系統會先搜索自己的DNS 緩存，沒有找到則會向網絡設置中的DNS服務器發出請求。對一個電信用戶來說這個服務器被DHCP協議自動配制成電信指定的服務器。

    電信的DNS服務器在收到請求后還是檢查自己的緩存，與個人電腦的緩存機制不同的是，一般公共DNS服務器為了加快解析減少流量，都將一個成功的解析緩存域名記錄中指定的最長時間(即TTL值，常見的是3600秒)。但如果緩存里沒有這個域名的記錄，此時根據配置不同有兩種選擇：一是向自己的上級DNS服務器請求(Forwarder)，二是從root-hints開始逐級向下解析。比如當收到www.sina.com的請求的時候，DNS發現緩存里有.com的域名的NS(域名服務器指向)記錄，隨即向該服務器請求sina.com，獲得一個新浪的域名的NS記錄以后轉而向該服務器請求 www.sina.com。新浪的服務器返回結果，解析成功并將結果返回用戶，同時將中間所有的結果都緩存下來以備下次使用。

    從上面的過程可以看出，絕大多數的用戶頻繁訪問的域名都已經在比較低級的DNS緩存了，一般幾小時才會向該域名 的權威服務器發送請求。

    再來看看此次斷網事件：

    首先DNSPod被攻擊了，其實在斷網前幾天DNSPod的Web服務器(和NS1)也被攻擊過。因為流量巨大，當地電信在骨干網上封掉了他們電信主域名服務器的IP。

    3600 秒以后，緩存在各地DNS服務器上的暴風的記錄過期，但此時暴風指向DNSPod的NS記錄還沒有過期(一般是24小時)，于是各地的DNS繼續向已經被封掉IP的服務器發送查詢。由于域名查詢使用UDP協議，服務器不會馬上意識到對方主機已經下線(也可能與電信封IP的方式也有關，沒有返回ICMP 包)，在超時以后才放棄查詢。但由于DNS服務器一般被配置為不緩存失敗的查詢，所以下一個DNS請求來的時候它還是得去向那個封掉的IP發送查詢。

    (注意此時DNSPod的IP被電信封了，后續所有的內容都和DNSPod無關。)

    然后我們看看暴風客戶端在干什么，首先它很”無辜“地向自己的服務器請求一個廣告或者升級，于是需要解析服務器的域名。電信的DNS服務器收到請求以后，等待兩秒沒收到結果，只好對客戶端說sorry?？墒潜╋L客戶端馬上開始重試重試再重試，于是全國上億的暴風用戶都向DNS服務器發出的請求。由于這些服務器始終無法解析出域名，這些請求逐漸被堆積在內存里。最悲哀的是每個請求需要有一個請求ID以對應每一個客戶端，而這個ID數量是有限的，當并發請求數達到一定數量的時候內存或者ID耗盡，服務器拒絕服務了。

    從以上可以看出，此次的元兇除了最早攻擊DNSPod的黑客以外，大概就是暴風流氓式的程序設計了。

相關連接：斷網事故誰負責，暴風影音逃不脫