1 問題引入：
a) 域名劫持： dns過程中某個環節被攻擊/篡改，導致dns結果爲劫持者的服務器。例如競爭對手將你方的app下載地址篡改爲他方的app下載地址。
b) 對現網用戶進行監控時，發現個別用戶請求時間爲幾十秒，而客戶端設置的connectTimeout時間爲二十秒。
原因：初步判斷爲dns解析時間耗時過長導致整個接口請求時間遠遠超過了10s。
解決辦法： 自定義dns，設置超時時間。 （使用的的是OkHttp，支持自定義dns）
c) 測試環境dns幾十秒，現網正常
原因： 舊的代碼裏面對url解析爲host有bug，當傳入一個測試環境地址，例如 10.10.10.10:6026/path,最終解析出來的host爲10.10.10.10:6026，
當調用系統的InetAddress.getAllByName("10.10.10.10:6026")，耗時非常長（幾十秒）
分析： 首先10.10.10.10:6026不是一個host地址也不是一個ip地址，所以dns是無法解析的。 方法內部會把它當成一個host在到不同的dns服務器上去查找它的ip，最後返回失敗。
解決辦法： 使用InetAddress中提供的方法來獲取host，拒絕自己實現一套
d) no route to host
2 dns過程介紹
2.1 什麼是dns
DNS （Domain Name System 的縮寫）的作用非常簡單，就是根據域名查出IP地址。你可以把它想象成一本巨大的電話本。
舉例來說，如果你要訪問域名math.stackexchange.com，首先要通過DNS查出它的IP地址是151.101.129.69。
DNS是應用層協議，事實上他是爲其他應用層協議工作的，包括不限於HTTP和SMTP以及FTP，用於將用戶提供的主機名解析爲ip地址。
2.2 主機名結構
舉例來說，www.example.com真正的域名是www.example.com.root，簡寫爲www.example.com.。因爲，根域名.root對於所有域名都是一樣的，所以平時是省略的。
域名的層次結構如下：
主機名.次級域名.頂級域名.根域名
2.3 DNS服務及域名解析過程
1. 假設運行在用戶主機上的某些應用程序（如Webl瀏覽器或者郵件閱讀器）需要將主機名轉換爲IP地址。這些應用程序將調用DNS的客戶機端，並指明需要被轉換的主機名。（在很多基於UNIX的機器上，應用程序爲了執行這種轉換需要調用函數gethostbyname（））。
2. 用戶主機的DNS客戶端接收到後，向網絡中發送一個DNS查詢報文。所有DNS請求和回答報文使用的UDP數據報經過端口53發送.
3. 經過若干ms到若干s的延時後，用戶主機上的DNS客戶端接收到一個提供所希望映射的DNS回答報文,這個查詢結果則被傳遞到調用DNS的應用程序。
從用戶主機上調用應用程序的角度看，DNS是一個提供簡單、直接的轉換服務的黑盒子。但事實上，實現這個服務的黑盒子非常複雜，**它由分佈於全球的大量DNS服務器以及定義了DNS服務器與查詢主機通信方式的應用層協議組成。**
DNS查詢採用分級查詢的方式，所謂"分級查詢"，就是從根域名開始，依次查詢每一級域名的NS記錄，直到查到最終的IP地址，過程大致如下。
- 從"根域名服務器"查到"頂級域名服務器"的NS記錄和A記錄（IP地址）
- 從"頂級域名服務器"查到"次級域名服務器"的NS記錄和A記錄（IP地址）
- 從"次級域名服務器"查出"主機名"的IP地址、
仔細看上面的過程，你可能發現了，沒有提到DNS服務器怎麼知道"根域名服務器"的IP地址。回答是"根域名服務器"的NS記錄和IP地址一般是不會變化的，所以內置在DNS服務器裏面。
下面一張圖以www.qq.com爲例，介紹了dns的過程：
解析順序
1） 瀏覽器緩存
當用戶通過瀏覽器訪問某域名時，瀏覽器首先會在自己的緩存中查找是否有該域名對應的IP地址（若曾經訪問過該域名且沒有清空緩存便存在）；
2） 系統緩存
當瀏覽器緩存中無域名對應IP則會自動檢查用戶計算機系統Hosts(linux中是/etc/hosts)文件DNS緩存是否有該域名對應IP；
3） 路由器緩存
當瀏覽器及系統緩存中均無域名對應IP則進入路由器緩存中檢查，以上三步均爲客服端的DNS緩存；
4） ISP（互聯網服務提供商）DNS緩存
當在用戶客服端查找不到域名對應IP地址，則將進入ISP DNS緩存中進行查詢。比如你用的是電信的網絡，則會進入電信的DNS緩存服務器中進行查找；
5） 根域名服務器
當以上均未完成，則進入根服務器進行查詢。全球僅有13臺根域名服務器，1個主根域名服務器，其餘12爲輔根域名服務器。根域名收到請求後會查看區域文件記錄，若無則將其管轄範圍內頂級域名（如.com）服務器IP告訴本地DNS服務器；
6） 頂級域名服務器
頂級域名服務器收到請求後查看區域文件記錄，若無則將其管轄範圍內主域名服務器的IP地址告訴本地DNS服務器；
7） 主域名服務器
主域名服務器接受到請求後查詢自己的緩存，如果沒有則進入下一級域名服務器進行查找，並重復該步驟直至找到正確紀錄；
8）保存結果至緩存
本地域名服務器把返回的結果保存到緩存，以備下一次使用，同時將該結果反饋給客戶端，客戶端通過這個IP地址與web服務器建立鏈接。
瞭解了上面的過程就不難理解dns解析一個錯誤的host爲什麼需要幾十秒的時間了。
DNS的記錄類型
域名與IP之間的對應關係，稱爲"記錄"（record）。根據使用場景，"記錄"可以分成不同的類型（type），前面已經看到了有A記錄和NS記錄。
常見的DNS記錄類型如下。
（1） A：地址記錄（Address），返回域名指向的IP地址。
（2） NS：域名服務器記錄（Name Server），返回保存下一級域名信息的服務器地址。該記錄只能設置爲域名，不能設置爲IP地址。
（3）MX：郵件記錄（Mail eXchange），返回接收電子郵件的服務器地址。
（4）CNAME：規範名稱記錄（Canonical Name），返回另一個域名，即當前查詢的域名是另一個域名的跳轉，詳見下文。
（5）PTR：逆向查詢記錄（Pointer Record），只用於從IP地址查詢域名，詳見下文。
一般來說，爲了服務的安全可靠，至少應該有兩條NS記錄，而A記錄和MX記錄也可以有多條，這樣就提供了服務的冗餘性，防止出現單點失敗。
3 dns問題定位工具：dig
a） dig命令的+trace參數可以顯示DNS的整個分級查詢過程，例如：
dig +trace www.baidu.com
b） 查詢每一級域名的NS記錄
dig ns com （可以查看包含com域名記錄的十三臺root服務器信息）
dig ns stackexchange.com （stackexchange.com 次級域名記錄的服務器信息）