運維老鳥闡述：滬江從DNS到httpdns的演進

DNS的全稱是Domain Name System,它的目的就是將一個域名解析到一個IP。基礎的DNS會用到TCP/UDP協議的53號埠，預設的是UDP協議，如果對服務質量要求比較高的話建議使用TCP。

在TCP的IP協議中約定，主機之間通訊必須通過IP。但是IP地址難以記憶，所以一般都是通過域名來訪問網站。且由於程式在對域名進行呼叫的時候不能去寫死IP，所以要使用FQDN的方式。

以mail.cctv.com為例，它的頂級域名是.com，二級域名是cctv，三級域名是mail同時也是cctv的子域。最後根域名就是“ . ”了，但是一般不會寫出來。

權威DNS也就是通常來說的“說了算”伺服器，是用來告訴使用者域名具體解析到哪個IP地址；快取DNS主要是把使用者請求解析的域名結果快取在自己這邊，以減輕權威DNS的工作負載；遞迴DNS-LocalDNS一般在運營商側使用的較多，用來接收使用者的遞迴查詢然後自己進行迭代查詢；轉發DNS類似於遞迴DNS，它會先檢視自己DNS內有沒有權威記錄，如果查詢到的話直接返回給使用者，否則就遞迴出去拋給其他DNS；公共DNS也是httpdns的一個基礎，一些常見的公共DNS：百度：180.76.76.76，阿里：223.5.5.5/233.6.6.6，騰訊：119.29.29.29。

遞迴查詢示意圖（給我答案）：A->B，B->C，C->D，D->C->B->A；迭代查詢示意圖（給我答案，或者提示）：A->B，A->C，A->D，D->A。

使用者在訪問http://mail.cctv.com/時，DNS的工作流程：

使用者發起域名解析請求，該請求會直接拋給遞迴DNS，接著遞迴DNS向根域NS發起迭代查詢，然後根域會返回com域的NS，遞迴DNS接收後又會向com域NS發起迭代查詢，com域NS查詢後返回了cctv.com的NS，最後遞迴DNS向cctv.com域NS發起迭代查詢獲得最後的結果，也就是mail.cctv.com。

在使用者端有快取DNS的情況下，上面的過程會被省略直接返回結果。

HTTPDNS是通過DNS之上建立的一個服務，同樣是將域名解析為IP。不同的是HTTPDNS使用的是HTTP/HTTPS協議的80/443埠。

HTTPDNS可以填補運營商LocalDNS的坑，比如域名劫持、訪問緩慢、解析轉發等。

減少公司運營的複雜度，提高資源利用率。Kubernetes在IT領域內最為常用，人才儲備越來越多。社群響應使用者需求度快。

當HTTPDNS無法使用的時候，會切換到備用線路，採用正常的LocalDNS去獲取。

HTTPDNS通過遞迴DNS獲取到的是使用者IP地址，而ISP運營商獲取到的是LocalDNS地址，定位易出現偏差。

對於HTTPDNS叢集介面服務有條件的話建議使用BGP Anycast，它可以幫助使用者獲取到最近的HTTPDNS伺服器。 也可以自定義公共介面IP地址。

採用主/備/備呼叫方式，當一個HTTPDNS無法使用了就呼叫下一個，當所有HTTPDNS都無法使用後切換到正常的LocalDNS方式。另外還有一種IP列表方式，在程式的SDK內對多個HTTPDNS進行ping的請求，延遲最低的節點優先請求。

查詢方式有HTTP和HTTPS兩種，HTTPS可以防止內容劫持。

使用IP地址對HTTPDNS發起請求的話，hostname是查詢不到的。這就需要在Requst Header中新增host，指定需要的hostname。

最早是使用HOSTS方式進行域名解析，HOSTS檔案在Windows上被儲存在C:\Windows\System32\dirvers\etc\hosts,而Linux上則是在/etc/hosts。HOSTS的優點在於簡單、粗暴、隱蔽，缺點則更明顯，存在檔案大、傳輸慢、耗貸款、一致性等問題。

Microsoft DNS的優點是簡單易用，但也有著黑盒、擴充套件性、併發數、安全性、集中配管能力較差、主從同步不穩定等問題。

在拋棄了Microsoft DNS後，我們使用了BIND這款開源DNS軟體，它算是迄今為止普及最廣的DNS實現。滬江使用BIND分為兩個階段：階段一為部署BIND服務，階段二為BIND分散式叢集優化改造。

在部署階段我們有三條線路，使用者發起DNS請求時會對這三個DNS發起DNS輪詢的請求。這樣基本滿足了使用者需要，但是也存在很多問題。首先就是權威DNS開啟了遞迴和轉發，這會使得DNS伺服器的壓力增大。然後修改記錄全靠手工、沒有區域解析功能且權威DNS均是單點。最後內外網未分離，權威DNS充當快取DNS。

在叢集式優化改造階段我們在每個機房配備了兩臺權威DNS做HA高可用，然後快取DNS另外進行部署，各個內網的伺服器對快取DNS進行查詢，減輕權威DNS負載壓力，還進行了權威DNS的讀寫分離。

權威DNS起到了開啟日誌輪轉、智慧解析作用。

權威DNS master端優化點：權威DNS關閉了遞迴及轉發，使用key+nsupdate的方式做記錄的變更，動態更新解析記錄。

權威DNS slave端優化點：加入了interface-interval1，用於pacemaker叢集的vip漂移探測，主從同步不一致時，單獨修改各slave記錄。

快取DNS分離：限定允許請求範圍--內網，開啟遞迴。後臺邏輯管理層

滬江向HTTPDNS發展主要進行了兩項工作，第一項是對HTTPDNS介面服務的選型，在自制的HTTPDNS服務和第三方的服務之間進行選擇。在選擇了介面服務後就必須對移動端SDK進行改造，這就是第二項工作。

主要原因在於DNS開啟了遞迴、轉發服務，未做分散式以及讀寫分離，單ISP線路部署。

常見的DNS攻擊手段有DNS query flood、udp flood、折射攻擊、放大攻擊。

對此應對策略分別是針對大流量攻擊購買三方服務進行抵抗，增加DNS公網頻寬，權威DNS設定白名單策略，DNS限速策略，提高DNS併發效能。

一些依賴於java/.net/python等框架的客戶端應用程式，如salt-minion，在DNS解析調整後，無法立即重新整理生效。

其原因就在於程式未觸發客戶端DNS解析器glibc的res_init()模組工作，其使用的python scoket.getaddrinfo只在程式第一次啟動時呼叫res_init()，讀取/etc/resolv.conf內容。

解決方法就是重啟客戶端程式，強制觸發客服端DNS解析器工作。或者客戶端程式直接使用底層的域名解析函式，而非第三方框架提供。

這個可能是由於LocalDNS解析轉發或者權威DNS IP地址庫出現問題。

這時候就需要立即將域名註冊商處的glue records值改為正確的值，或者請求域名註冊商單獨重新整理影響域名的glue records記錄。

這個問題無需多說，請使用HTTPDNS！