緣起
Linux系統下域名解析的配置文件是/etc/resolv.conf，這個大家都知道。估計一般的系統管理員、運維人員都知道在這里面配置上兩個或更多的nameserver，以便一個掛掉后還能正常解析域名。但真的情況是這樣嗎？
我從某次故障說起吧，有一次，線上報大量的dns解析失敗，上去看，發現是一臺nameserver掛掉了，幸好/etc/resolv.conf中的另外一臺沒有掛，所以，還不是百分百的解析失敗。從邏輯上來講，這些失敗的請求應該會去嘗試另外一個（好的）nameserver的，但是重試的場景和策略是什么呢？不得而知。所以我就關注了下/etc/resolv.conf文件的配置問題。
下策
優化方案之一，就是在/etc/resolv.conf中做優化設置。優化前內容如下：
nameserver 10.0.0.1
nameserver 10.0.0.2
nameserver 10.0.0.3
優化之后，文件內容變為：
options timeout:1 attempts:1 rotate
nameserver 10.0.0.1
nameserver 10.0.0.2
nameserver 10.0.0.3
這里大概講下新加的幾個選項的含義：
- nameserver:dns服務器的ip地址。最多能設三個。
- timeout:查詢一個nameserver的超時時間，單位是秒。系統缺省是5，最大可以設為30。這他娘不是坑爹嗎？那個應用的dns請求會允許這么長的超時時間？早tm超時出錯返回了吧。所以我們這里改成最小值：1
- attempts:這個是查詢的整個都嘗試一遍的次數。缺省是2，我覺得在有3臺nameserver的前提下，都查詢一遍就完全夠了（畢竟三臺中有一臺能正常查出結果的概率是相當大的吧，尤其是nameserver都有監控的說）
- rotate:這個參數的含義是隨機選取一個作為首選查詢的dns server。系統缺省是從上到下的，所以你該了解到為什么缺省情況下第一個nameserver的負載比第三個的大多了吧。
之所以這只是下策，是因為這種解決方案如果碰到有一臺nameserver(假如是10.0.0.1)掛掉的情況下，客戶端解析請求如果又恰好分到這臺nameserver的時候，應用會解析超時失敗的概率太高了。
中策
中策就是做nameserver的高可用，用lvs來做，做兩個vip:10.0.0.4和10.0.0.5，后端real server還是指向這三臺真實的nameserver:10.0.0.1、10.0.0.2和10.0.0.3，這樣real server的健康狀況就由lvs來維護了，這樣當客戶端來訪問vip時，只要后端的3臺不都掛掉，就一定能保證返回正確的結果。
具體的配置我就不貼了，直接用keepalived來做即可。
這個解決方案其實也挺完美的，尤其是當有現成的lvs director的時候?？戳俗詈笠徊?，就知道為什么這個只是中策了。
上策
這個方案是我仔細考慮后推薦的方案，尤其適用于沒有現成的lvs director的環境里。這個方案的主要特點是：
- 本機起dnsmasq，監聽本地的udp 53口，用來監聽來自于本地的解析請求。
- 在dnsmasq里，將上層服務器定義為10.0.0.1、10.0.0.2和10.0.0.3。
這個方案的優點在于：
- 本地雖然多起一個dnsmasq服務，但是僅監聽127.0.0.1，所以基本不影響性能
- dnsmasq會自己維護上游服務器的健康狀況，不會把解析請求發到掛掉的上游服務器上
這個方案能夠自動做dns server的故障切換，而且不引入任何外部的依賴（dnsmasq是本機跑的），幾乎不影響性能，甚至于還有可能提升性能，畢竟，dnsmasq也是會做一級緩存的。所以，我認為其為上策！
