《一次DNS緩存引發的慘案》要點：
本文介紹了一次DNS緩存引發的慘案，希望對您有用。如果有疑問，可以聯系我們。

時間2015年的某個周六凌晨5點,公司官方的QQ群有用戶反饋官網打不開了,但有的用戶反饋可以打開,客服爬起來自己用電腦試了一下沒有問題,就給客戶反饋說,可能是自己網絡的問題,請過會在試試.早點8點,越來越多的用戶反饋官網無法打開,并且有部分用戶開發反饋app也打不開了,客服打電話叫起了還在夢鄉中的我.

分析定位

被客服叫起來之后,一臉懵逼,不知道什么情況,給客服回復,知道了,立刻排查,待會有消息及時溝通.用涼水洗了一把臉清醒了一下,立刻根據經驗回憶這兩天生產投產的情況：上線了XX模塊,不影響、修復了XXbug,應該也不影響、剛給服務器配置了https,看起來好像有點關系,但是app暫時沒有投產https,怎么也出現問題,排除之.打開電腦核查了最近的投產記錄應該都不至于發生這么嚴重的問題,隨懷疑是不是網絡方面有問題,立刻打電話叫起來運維經理以及相關人等一起排查.

一邊讓網絡和運維排除問題,一邊再次核查了web服務器、數據庫服務器、業務日志、數據庫日志,以及其它的一些監控數據,各項皆正常.試著在本機ping了一下域名確實不通,更加懷疑是網絡問題,嘗試這直接使用外網訪問官,可以打開沒有問題,可以基本確認服務沒有問題,但運維部反饋網絡設備什么都正常,肯定是你們投產代碼出問題了,各方硬著頭皮繼續在排查.

9點,群里開始有大規模的用戶反饋官網和app都打不開了,更有部分用戶煽動,XXX公司跑出了(15年很多p2p公司跑路,導致用戶都成了驚弓之鳥,稍微有問題便害怕公司跑路,個個都鍛煉成了監控高手,天天看,實時刷,凌晨起來尿尿也都順便看一下app上的今日收益),客服400熱線基本被打爆了.一邊繼續排查問題,一邊上報此問題給總監、公司各高管,給客服建議,給用戶解釋,IDC機房網絡抖動,技術正在緊急解決,資金和數據都沒有任何影響,稍安勿躁.

10點,開發和運維反復的檢查后,開始懷疑dns解析有問題,但具體是什么問題還不清楚,CTO決定：1、大家都打車往公司走,來公司集體解決 2、在各QQ群、微信群給用戶群發解釋xxx問題,安撫客戶.在車上的時候重新梳理了一下用戶的整個訪問流程,如下圖：

 

到公司后,根據這個思路大家在一起驗證了一下,通過外網IP和內網IP訪問公司所有服務都正常,但是通過域名訪問不行,另外監控服務器、防火墻、網絡設備日志都正常,因此斷定是DNS解析出現問題.

攻堅問題

既然確實是DNS解析問題,那么問題又來了?為什么DNS解析會出現問題?如何去解決這個問題?一邊給萬網提工單,我們也自己測試一下電信、移動、聯通在不同的網絡運營商下面的訪問情況,發現只有在聯通網絡的環境下DNS解析不了.根據客服得到的反饋也驗證了這個情況,電信和移動用戶反饋很少,聯通用戶反饋最多.于是我們又開始給聯通打電話,剛開始聯通不受理我們的這個請求,于是又開始以用戶的身份打電話給聯通公司讓立刻解決不能上網的問題.

于是就開始了萬網和聯通的扯皮大戰,萬網說從他們那邊查看DNS解析都正常,一起指標都正常,我們又給聯通打電話聯通說我們已經知道了,待會由專業的人給我們回復,過了一會聯通的網絡工程師回復說,像這種情況一般都是域名解析的問題.早上10:30到公司開始短短的6各小時內,我們幾個輪流給聯通公司合計供打了近50、60通電話,給萬網提了N個工單,接了N個電話.

期間領導也開始動用各種關系,聯通內部的朋友、網絡運維界的大拿幫忙來定位解決,我們也嘗試了很多的辦法,比如,使用ipconfig/flushdns命令清除本機的DNS緩存、在萬網的官網把DNS解析重新更新一邊、刪除在重新添加等等,也不是完全沒有收獲.我們一直想找一個可以測試各個地方、運營商網絡的辦法,終于在各方推薦和搜索的情況下找了17ce 和 360奇云測兩個網站,感覺非常實用,在以后的網絡定位中,成了我必備使用的工具,可以非常方便的監控各個運營商、各個地區網站的訪問是否通不通、訪問的速度快不快等問題,截圖如下：

 

我們也發現,公司的其它域名也都訪問正常,就是官網的這個域名和相關的子域名不通.期間很多人都問了一個問題就是你們的域名有沒有忘了繳費,剛開始大家也都問了運維這邊說是沒有這個問題,直到中午12:30的時候在我們再三的追問下才說8點多的時候登錄上萬網的時候顯示這個域名是欠費狀態,但是他已經立刻把費用補了上去了.哎呀差點把我們氣死,問了不是域名到期有提示的嗎?才知道因為上一個運維經理走后,他們沒有及時的更新萬網的電話和郵箱導致提示郵件和短信也沒有收到.

通過和萬網、聯通公司、領導的相關朋友溝通以及我們的測試觀察,初步明白了這個事情的原因：域名忘記繳費導致萬網的DNS解析被停止,用戶本機或者DNS服務器有緩存,所以部分用戶可以訪問部分用戶不能訪問；繳費過后萬網的DNS已經進行了更新和推送,但是DNS解析有很多的層級需要一級一級的往下面發送更新,有的層級并沒有更新到,導致部分沒有更新到的DNS服務商下面的用戶不能訪問官網.

和萬網進行了溝通,問最延遲的情況所有的DNS更新到最新的時間,回答是48小時內肯定都會好的,但是我們等不起呀,隨著時間的推移越來越多的用戶發現問題,QQ群、微信群已經沸騰,董事長也開始關注次問題,有的客戶直接在群里面說,你們的技術太不給力了(像這種還是委婉的,有的直接打電話罵人)…

臨時解決方案

不斷的通過17ce測試發現,大部分地區的網絡都已經恢復,就剩北京聯通和部分地區聯通網絡環境下不通,也說明了這幾個地區下的DNS解析記錄沒有被更新.那么既然我們在上面已經定位出了問題,又了解是什么原因,就想著試著換個DNS解析服務器會不會好一點呢,于是我們把本地的DNS地址換成8.8.8.8(谷歌的DNS服務解析)發現好了!于是趕緊先寫解決手冊發給著急的客戶來使用.

官網的用戶可以通過更改DNS來解決訪問的問題,APP怎么辦呢?沒有辦法我們也不能等,直接找開發人員把服務端調用的地址由域名暫時先改為外網的IP地址打一個版本供用戶臨時使用.安卓還比較好辦,直接讓用戶下載安裝使用還好,但是IOS那時候的審核最少都需要一周黃花菜都涼了.其實iPhone手機可以單獨設置DNS的,我們進行了設置和測試后發現也可以實現,于是馬上更新到手冊中發送給客服發送到群里面給用戶使用.

點擊下載當時寫的DNS更新手冊

有人說直接讓用戶使用外網就行了嗎,使用外網首頁打開到是沒有問題,但是各系統之間調用,相關配置文件里面寫的也都是域名的地址,如果硬改的話可能會引發另外的問題.第一天搞完就10點多了,中間就4點吃了一頓飯,打了N個電話大家都非常累,于是當天就先這樣了,第二天大家一早到公司繼續跟進.

第二天到公司經過17ce測試發現所有的節點都已經通了就剩北京聯通的兩個接點沒響應,但是北京是我們的大本營,絕大部分的用戶都是北京的,繼續和萬網、聯通溝通看怎么能徹底的解決這個問題,另一方面做好最壞的打算,如果一直不通怎么辦.在生產環境中梳理所有使用域名的配置文件,做好隨時可以直接更新為外網地址而不能影響服務,app完整的重新做一個版本,做好隨時可以投產讓用戶強制升級到外網直連的版本.

到第二天晚上10點的時候,北京聯通的這兩個節點還是不通,和領導進行了商議如果到周一早上8點來的時候這兩個網絡還是不能通的話,就上線改造好的系統和APP強制升級(因為當時周末還沒有標的,周內才有發標計劃).第三天早上起來的第一件事情就是拿起手機,查看自己的聯通網絡是不是可以登錄上官網,結果通了!皆大歡喜.

俗話說真理是愈辯愈明,經過了這次事故,也徹底的讓我了解了DNS解析的整個過程.

DNS 解析流程

DNS( Domain Name System)是“域名系統”的英文縮寫,是一種組織成域層次結構的計算機和網絡服務命名系統,它用于TCP/IP網絡,它所提供的服務是用來將主機名和域名轉換為IP地址的工作.俗話說,DNS就是將網址轉化為對外的IP地址.

dns從用戶訪問到響應的整個流程

 

• 第一步：瀏覽器將會檢查緩存中有沒有這個域名對應的解析過的IP地址,如果有該解析過程將會結束.瀏覽器緩存域名也是有限制的,包括緩存的時間、大小,可以通過TTL屬性來設置.
• 第二步：如果用戶的瀏覽器中緩存中沒有,操作系統會先檢查自己本地的hosts文件是否有這個網址映射關系,如果有,就先調用這個IP地址映射,完成域名解析.
• 第三步：如果hosts里沒有這個域名的映射,則查找本地DNS解析器緩存,是否有這個網址映射關系,如果有,直接返回,完成域名解析.
• 第四步：如果hosts與本地DNS解析器緩存都沒有相應的網址映射關系,首先會找TCP/ip參數中設置的首選DNS服務器,在此我們叫它本地DNS服務器,此服務器收到查詢時,如果要查詢的域名,包含在本地配置區域資源中,則返回解析結果給客戶機,完成域名解析,此解析具有權威性.
• 第五步：如果要查詢的域名,不由本地DNS服務器區域解析,但該服務器已緩存了此網址映射關系,則調用這個IP地址映射,完成域名解析,此解析不具有權威性.
• 第六步：如果本地DNS服務器本地區域文件與緩存解析都失效,則根據本地DNS服務器的設置(是否設置轉發器)進行查詢,如果未用轉發模式,本地DNS就把請求發至13臺根DNS,根DNS服務器收到請求后會判斷這個域名(.com)是誰來授權管理,并會返回一個負責該頂級域名服務器的一個IP.本地DNS服務器收到IP信息后,將會聯系負責.com域的這臺服務器.這臺負責.com域的服務器收到請求后,如果自己無法解析,它就會找一個管理.com域的下一級DNS服務器地址給本地DNS服務器.當本地DNS服務器收到這個地址后,就會找域名域服務器,重復上面的動作,進行查詢,直至找到域名對應的主機.
• 第七步：如果用的是轉發模式,此DNS服務器就會把請求轉發至上一級DNS服務器,由上一級服務器進行解析,上一級服務器如果不能解析,或找根DNS或把轉請求轉至上上級,以此循環.不管是本地DNS服務器用是是轉發,還是根提示,最后都是把結果返回給本地DNS服務器,由此DNS服務器再返回給客戶機.

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4368.html