一次dns緩存引起的慘案

時間2015年的某個週六凌晨5點，公司官方的QQ羣有用戶反饋官網打不開了，但有的用戶反饋能夠打開，客服爬起來本身用電腦試了一下沒有問題，就給客戶反饋說，多是本身網絡的問題，請過會在試試。早點8點，愈來愈多的用戶反饋官網沒法打開，而且有部分用戶開發反饋app也打不開了，客服打電話叫起了還在夢鄉中的我。

分析定位

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

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

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

10點，開發和運維反覆的檢查後，開始懷疑dns解析有問題，但具體是什麼問題還不清楚，CTO決定：一、你們都打車往公司走，來公司集體解決 二、在各QQ羣、微信羣給用戶羣發解釋xxx問題，安撫客戶。在車上的時候從新梳理了一下用戶的整個訪問流程，以下圖：

{:.center}

到公司後，根據這個思路你們在一塊兒驗證了一下，經過外網IP和內網IP訪問公司全部服務都正常，可是經過域名訪問不行，另外監控服務器、防火牆、網絡設備日誌都正常，所以判定是DNS解析出現問題。

攻堅問題

既然確實是DNS解析問題，那麼問題又來了？爲何DNS解析會出現問題？如何去解決這個問題？一邊給萬網提工單，咱們也本身測試一下電信、移動、聯通在不一樣的網絡運營商下面的訪問狀況，發現只有在聯通網絡的環境下DNS解析不了。根據客服獲得的反饋也驗證了這個狀況，電信和移動用戶反饋不多，聯通用戶反饋最多。因而咱們又開始給聯通打電話，剛開始聯通不受理咱們的這個請求，因而又開始以用戶的身份打電話給聯通公司讓馬上解決不能上網的問題。

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

期間領導也開始動用各類關係，聯通內部的朋友、網絡運維界的大拿幫忙來定位解決，咱們也嘗試了不少的辦法，好比，使用ipconfig/flushdns命令清除本機的DNS緩存、在萬網的官網把DNS解析從新更新一邊、刪除在從新添加等等，也不是徹底沒有收穫。咱們一直想找一個能夠測試各個地方、運營商網絡的辦法，終於在各方推薦和搜索的狀況下找了17ce 和 360奇雲測兩個網站，感受很是實用，在之後的網絡定位中，成了我必備使用的工具，能夠很是方便的監控各個運營商、各個地區網站的訪問是否通不通、訪問的速度快不快等問題，截圖以下：

{:.center}

咱們也發現，公司的其它域名也都訪問正常，就是官網的這個域名和相關的子域名不通。期間不少人都問了一個問題就是大家的域名有沒有忘了繳費，剛開始你們也都問了運維這邊說是沒有這個問題，直到中午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從用戶訪問到響應的整個流程
{:.center}

• 第一步：瀏覽器將會檢查緩存中有沒有這個域名對應的解析過的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服務器再返回給客戶機。

這個事情發生後給了咱們很大的教訓:
第1、流程管理有漏洞，離職交接不到位；
第2、危機處理不成熟，影響公司聲譽；
第3、監控機制不完善，像外網不通的這種問題，應該提早設置監控措施。

有時候很是的嚴重的問題，就是你經常忽略的小不點

---

喜歡個人文章，請關注個人公衆號

做者：純潔的微笑
出處：www.ityouknow.com/
版權歸做者全部，轉載請註明出處