域名解析是終端裝置通路網際網路的第一步,扮演着至關重要的角色。同時,域名解析服務是目前整個網際網路基礎設施中最脆弱的幾個環節之一。移動網際網路時代,由于接入智能終端數量激增,問題愈加嚴重。
2017年2月24日21:20-2月25日1:00之間,某app a在江蘇省某isp通路流量減半,排查後發現為遞歸dns故障導緻。
![](https://img.laitimes.com/img/_0nNw4CM6IyYiwiM6ICdiwiIn5GcuUTNlNDM3cjZ0UWZ3kDOlJzN0EGOhVDZ1AjN5czY4UDOvwVbvNmLj5Wat4Wd5lGbh5iY1BXLn1WauU3bop3ZuFGat42YucWbp1iMhRXYvw1LcpDc0RHaiojIsJye.png)
圖1 遞歸dns故障導緻業務通路受害
如圖1所示,正常通路期間,app業務通路大緻分為四步:
step 1: app發起業務域名解析
step 2: 遞歸dns傳回域名解析結果ip
step 3: app根據傳回的ip向業務伺服器發起請求
step 4: 業務伺服器傳回響應,互動結束。
故障發生時,遞歸dns在第二步無法傳回解析結果或者傳回錯誤的結果,導緻app無法正确擷取業務伺服器的ip,最終業務通路受到巨大影響。
2016年11月中旬,由于某app b通路的節點存在服務品質方面問題,計劃通過修改域名解析記錄将流量切走,但由于域名解析不生效,導緻流量無法調走,最終4個小時後節點服務品質恢複了業務才回歸正常。
圖2 域名解析不生效的惡果
如圖2所示,正常通路期間,app業務通路的細化步驟可以分解成六步:
step 2: 遞歸dns向權威dns發起域名解析結果
step 3: 權威dns傳回域名對應的ip給遞歸dns
step 4: 遞歸dns給app傳回域名解析結果
step 5: app根據傳回的ip向業務伺服器發起請求
step 6: 業務伺服器傳回響應,互動結束。
故障發生時,盡管權威dns的解析記錄已經修改,但遞歸dns的解析結果卻沒有任何變化(常見原因是遞歸dns不遵循傳回結果的ttl,私自設定緩存時間),仍然傳回之前的結果,導緻了故障的發生。
2011年,某公司流量峰值期間,運維人員計劃通過修改cdn的智能dns系統配置将某一地區的部分流量從負載高的cdn節點到相對流量小的cdn節點去。實施過程中,發現某一個dns ip對應的流量到達5g+,無法實作“調部分流量”的目标。
客戶回報的服務品質問題往往是由于排程不準确導緻的。參見以下案例。
圖3 手機dns配置不準導緻跨isp跨地域通路
根據ip位址來判斷,案例中的使用者位于武漢聯通,而遞歸dns卻配置成了上海電信的dns伺服器,導緻最終排程系統會按照上海電信區域來做就近接入,出現了跨營運商、跨地域通路問題。
現網上dns解析一般基于udp來實作,由于udp自身的脆弱性,很容易被劫持。
圖4 域名劫持原理
根據多種管道統計資料,國内現網的周劫持率在3%-5%左右(對于某一個業務,一周之内曾經被劫持過的使用者占比),部分地區部分時段的劫持率超過20%。
域名劫持的危害性在于隐蔽性強、品牌傷害嚴重、解決難度大。
隐蔽性強。 劫持偶發,難以複現,舉證難。
品牌傷害嚴重。 劫持後往往彈出涉黃、涉賭等内容,嚴重傷害應用品牌。
解決難度大。 确認域名劫持後,一般開發者沒有管道去解決問題。
在國内,遞歸dns數量較少且分布不均。據統計,top 200的遞歸dns承擔國内90%+的dns通路流量。這樣少的遞歸dns是無法承載就近接入需求的。
上節的案例4就是典型的遞歸伺服器配置錯誤導緻的就近接入問題。
圖5 httpdns服務原理
如圖5所示,httpdns與傳統的dns對比起來,有以下幾項功能:
使用http協定進行域名解析,極大增強了域名解析的安全性
繞過了遞歸dns伺服器,最大限度防止域名劫持的發生
零劫持
域名解析結果修改秒級生效
<a href="https://help.aliyun.com/document_detail/30144.html">零延遲解析</a>
基于手機ip就近接入
<a href="https://help.aliyun.com/document_detail/30139.html">支援https接口</a>
<a href="https://help.aliyun.com/document_detail/49758.html">批量域名解析接口</a>