網絡原來如此之G行數據中心分布式域名解析系統設計
當金融機構逐步向多數據中心架構演進時,敏捷的災難切換恢復能力變得至關重要,如何在保證生產數據或存儲一致性的基礎上在各數據中心間調度流量,確保業務的持續運行和快速恢復,已成為行業的關鍵需求。域名解析系統(DNS)作為這一需求的核心支撐,已經從簡單的域名到IP地址的映射,轉變為數據中心流量管理和調度的關鍵樞紐。近些年陸續發生數據中心內網域名解析系統故障,引發大面積網絡癱瘓及業務中斷,如何防范和應對域名解析系統故障,做好域名解析系統高可用架構、容災機制和應急預案的設計已成為數據中心技術團隊關注的焦點,今天我們就講講G行數據中心域名解析系統設計思路及思考。
本篇文章會從系統架構到策略配置逐步展開,帶領大家一步一步了解G行域名解析系統架構是怎么形成的,其中涉及一些DNS技術專業術語,可以參考另外兩篇基礎文章《淺談DNS域名解析系統》和《淺談DNS域名解析系統之Local DNS》,本文不再贅述。
一、架構設計
“凡事預則立,不預則廢”,對于構建足以影響整個數據中心運轉的全局類網絡域名解析系統時,第一步需要考慮的就是整體可用性,要保證系統部分故障不影響整體對外的服務能力,這就要求設計的系統架構具備低耦合、高冗余特性,同時建議支持產品異構部署。
DNS的協議標準非常靈活,根、權威、遞歸服務器等角色,可以獨立部署,也可以部署在同一臺服務器上。對于大型數據中心,從健壯性和容量的角度思考,還是需要對各層角色進行解耦并獨立異構部署,充分利用域名解析系統各個角色的特性。從同業的調研中,也證實了這一點,大型企業級數據中心多是根、權威、遞歸服務器分角色部署的方式。整個分層解耦架構設計示例如下:
圖片
根、權威、遞歸分層,每個角色服務器都在多中心分布式部署。
01 根服務器(Root Server)
根服務器采取高冗余分布式部署,每個數據中心至少部署兩臺根服務器,從而應對本地數據中心單臺設備故障,同時提供數據中心級冗余能力。
02 權威服務器(Name Server)
權威采用多級授權的方式,根授權一級域名的權威服務器,一級域名的權威服務器授權二級域名的權威服務器,以此類推。各級權威服務器可以通過增加授權進行橫向擴容。二級域名權威服務器可以授權給需要域名自主權的系統自行管理。如全棧云平臺、域控、內網CDN平臺、子機構等等。
03 遞歸服務器(Local DNS server)
考慮辦公和生產屬性的不同,遞歸服務器采用辦公和生產的獨立的方式進行部署,分別為辦公終端和生產服務器提供域名解析服務,辦公遞歸服務器引入不同信創產品和非信創產品進行異構部署。
G行遞歸服務器每個節點采用負載均衡集群部署,這樣設計有許多優點:
- 負載分擔:遞歸服務器直接面對客戶,訪問壓力較大,通過負載均衡可以實現高性能解析能力;
- 橫向擴展:用戶側需要直接配置遞歸服務器IP,如果遞歸服務器需要進行擴容、升級或者替換等變更操作,短時間中斷可能產生全局性影響,通過負載均衡虛地址發布,可以屏蔽后端服務器集群的變化,方便后續運維;
- 健康檢查:負載均衡具備DNS方式的健康檢查,實時發現遞歸服務器的解析異常,實現自動隔離;
- 安全防護:部分負載均衡產品具備DNS防護能力,可以防護DDOS攻擊和攔截異常解析請求;
- 異構部署:資源池可以采用不同品牌的產品進行異構部署,以規避產品級故障。
二、域名規劃
域名規劃可能是域名解析系統可持續的關鍵,一個好的域名架構規劃可以實現清晰的上下級域名關系、區分管理職責、靈活的擴容和拆分等等,這里我們主要考慮動靜區份、內外區分和風險隔離租戶區分三個關鍵因素,以支持多數據中心的業務需求:
01動靜區分
“動靜”指動態域名和靜態域名。在高可用架構中,通常通過域名解析系統來實現應用系統的高可用,域名服務器根據客戶端請求所在的位置來動態解析出不同的IP地址,或者通過輪詢方式解析多個IP地址實現多活系統服務IP的負載均衡,又或者需要通過域名切換地址來實現應用系統的主備切換能力等等。借助域名解析系統健康檢查監控和智能解析算法來實現單個域名和多個IP地址綁定關系的域名,叫做動態域名。相對的,域名和IP地址做簡單綁定的域名叫做靜態域名。
動態域名需要域名解析系統消耗更多的資源,包括實時的健康檢查策略、負載均衡、拓撲算法等智能解析算法等等。在架構設計的考量中,動態域名將來可能成為系統性能的瓶頸,為了便于獨立部署,明確的動態域名應該使用獨立的子域,如內網CDN系統、多AZ的全棧云系統等等。
02內外區分
“內外”指內網域名和互聯網域名,互聯網DMZ區的服務器通常存在既訪問內網又訪問互聯網的需求,為避免內外網域名混淆,應避免內網和互聯網使用同一個一級域名。而純內網環境應該與互聯網完全隔離,不具備解析互聯網域名的能力。
03風險隔離租戶區分
獨立的機構域名建議使用獨立的子域,比如分行、信用卡或者子公司,后續如果出現單機構業務發展過快或者管理架構調整的情況,可以方便進行獨立拆分。
綜上,整體域名規劃如下:域名由根域名(“.”)進行授權,數據中心內部使用統一的一級域名,名字應該與互聯網域名有所區分,二級域名按照機構區分,三級域名根據動靜態使用區分,可以根據功能再劃分子域。
圖片
三、策略設計
01智能解析機制
域名解析系統的智能解析能力是數據中心實現業務多活的基礎能力,通俗的說,智能解析是域名解析系統依據用戶屬性,結合對系統服務狀態的監測,返回相應的服務IP地址的能力。典型的使用場景如“近源訪問”:
應用系統在兩個數據中心都提供相同的服務,不同的數據中心發布不同的服務地址,需求是發布同一個域名,用戶訪問這個域名的時候能夠訪問到離自己物理位置最近的數據中心的服務節點,如果這個服務節點故障,則自動訪問到另一個數據中心的服務節點,用戶對訪問到哪個數據中心服務節點無感知。
“近源訪問”的典型HTTP/HTTPS應用如“CDN內容分發網絡”。“近源訪問”可以大大減少數據中心間通信的帶寬資源,降低成本,同時由于訪問距離近,也能提高用戶訪問的速度,增強用戶體驗。在這個場景里,域名解析系統會根據用戶請求的源地址來判斷返回哪個數據中心的服務地址,同時域名解析系統會通過健康檢查機制持續探測應用系統的服務端口可用性,如果探測失敗,則自動隔離該地址,按照解析順序,會解析下一個可用地址,實現自動切換能力。
可以看出智能解析的關鍵點有兩個:1、通過源地址判斷返回哪個服務地址,2、健康檢查機制。健康檢查機制比較簡單,在這里不做詳述,主要講一下怎么獲取用戶地址。熟悉DNS原理的同學可能會發現一個問題,當域名解析系統分角色部署的時候,權威服務器能獲取到的是遞歸服務器的地址,而獲取不到用戶的真實地址。
技術上可以通過兩種方式解決:第一種方式是使用EDNS (Extension Mechanisms for DNS) 技術,EDNS是對于原有DNS協議的一種擴展,旨在增強其功能性和靈活性。它的主要特性是將DNS消息的大小由512字節提高到4096字節,并引入了額外的選項字段,使得DNS報文可以攜帶更多類型的信息,在這里我們主要是用到ECS(Client Subnet,客戶端子網)擴展字段,ECS擴展不是EDNS的一個直接字段,而是作為EDNS的一個選項(OPT Resource Record)中的一個部分來傳送的。當DNS解析請求通過遞歸解析器轉發到權威服務器時,ECS選項會包含發起請求的客戶端地址的信息,權威服務器可以因此獲得用戶的真實地址。第二種解決方案是目前互聯網常用的方式,在每個數據中心都建設獨立的遞歸服務器,由遞歸服務器的地址來代表用戶的地理位置,權威服務器根據遞歸服務器地址就可以知道請求來自哪里。
圖片
從架構設計角度結合部署產品情況,G行目前采用第二種解決方案。第一種解決方案有一些優勢,比如成本比較低,不需要太多的權威服務器,而且配置也不算復雜,同時權威服務器可以直接獲得用戶的IP,在通過解析日志分析用戶行為方面可以獲得很有效的數據;但是這個方案有個致命的問題,開啟源地址插入功能后,需要放棄遞歸服務器的緩存能力,因為每個請求都是要帶不同的源地址的,意味著每次請求都要在權威上做獨立的判斷,不然就無法做到就近解析,而放棄緩存能力,可能成百上千倍增加權威服務器的系統壓力,在同時啟用智能解析的情況下可能直接導致權威服務器性能不足而故障的情況,第二種方案成熟、簡單易行,并且互聯網有大規模部署的案例,不過需要提醒的是每臺遞歸服務器都需要開通到所有根和權威服務器的訪問關系。成本控制方面,需要在多個位置部署遞歸服務器,在用戶較少的位置,可以考慮低端服務器或者虛擬機方式,對于不需要智能解析的位置則不用部署。
02緩存機制
在智能解析中我們提到了遞歸服務器的緩存機制,在域名解析系統架構的設計中,緩存策略的設計直接影響域名解析系統的整體性能。遞歸服務器啟用緩存后,緩存時間內,遞歸服務器不再將請求轉發給權威服務器解析,而是將緩存的結果直接返回給用戶,不僅大大緩解了權威服務器的訪問壓力,也提高了域名解析的速度。
開啟緩存非常有必要,但是緩存時間是不得不考慮的因素,緩存時間太短,無法有效降低權威服務器的壓力,緩存時間太長,可能導致域名地址變更無法快速更新,域名解析系統的智能解析機制無法快速生效等等。緩存時間建議通過權威服務器上域名配置的TTL時間來設置,不同類型的域名可以有不同的TTL時間策略,對于需要地址快速切換的重要業務域名,建議降低TTL時間值,特別應用甚至可以設置為0,對于有一定業務影響承受能力的業務域名,可以參考通用時間來設置。
圖片
綜合考慮域名解析系統的整體性能和大部分應用系統的需求,設計通用TTL時間可以提高應用需求的溝通成本,以健康檢查失敗超時30秒,TTL時間60秒為例,可以計算出可能的業務影響時間為60~90秒,如果小于業務的RTO時間,那就是可以接受的TTL時間。
圖片
另外,客戶側還存在其他域名緩存可能導致域名切換失效,包括操作系統、中間件、java組件、瀏覽器等,建議應用部署時管理員應該充分評估可能域名緩存的組件,如果有,應該調整設置為不緩存或遵循域名TTL值。
03域名解析時延
域名解析作為網絡訪問的第一步,必然會消耗一定的時延,如果是服務器間的互訪,那么增加時延可能對時延敏感的應用系統產生影響,這也是應用系統在考慮使用域名訪問前的一些顧慮。解析時延主要可能有兩種情況,(1)遞歸服務器有緩存,那么由遞歸服務器直接返回結果,由于遞歸服務器就近部署的原則,解析時延通常在1-2ms左右;(2)遞歸服務器沒有緩存或者緩存時間超過TTL設置,那么遞歸服務器將重新發起迭代查詢,根據域名迭代查詢的次數不同,時延可能在幾毫秒到幾十毫秒不等,如果TTL值為60秒,那么每60秒可能會發生一次較緩慢的域名解析。
對于長連接應用,域名解析時延的影響僅體現在第一次的解析過程,建立TCP連接后,連接中斷前不再請求DNS(不再增加訪問延時),解析時延影響較低;對于短連接高頻訪問的應用,由于遞歸服務器近客戶端部署,各地客戶端均訪問本地的遞歸服務器,僅在緩存超時后會出現短暫的延時增加,平均時延沒有明顯增長。
針對延時要求敏感的業務,遞歸服務器建議開啟“緩存刷新”功能,在緩存到期時遞歸服務器主動向權威域名更新解析記錄,保證客戶端都從緩存里獲得解析結果。如果DNS產品不支持緩存刷新,可以在前端負載均衡上增加對應域名的健康檢查,利用負載均衡來快速更新緩存。
對于CS訪問方式,如果域名解析延時或者解析失敗對應用影響較大,可以考慮通過使用HTTPDNS方式通過HTTP方式直接從權威服務器獲取域名解析結果,但是需要對C端進行一定的改造。
04容災策略
整體域名解析系統的容災策略主要從架構和性能兩方面考慮。
架構方面,由于域名解析系統根和權威服務器都采用分布式部署,任意單個節點故障對系統整體無影響,遞歸服務器采用負載均衡集群方式部署,遞歸服務器采用資源池方式部署,負載均衡使用域名解析探測作為健康檢查方式,單臺設備不可用可以自動隔離。負載均衡組采用多臺集群部署,保證負載均衡自身的可用性。根、權威、遞歸服務器都考慮異構部署,避免產品級故障。對于目前比較流行的“雙平面”部署(使用兩套異構產品部署完全對等的兩套環境,一套主用一套備用,主用環境出現問題時直接切換到備用環境上),在分布式架構下意義不大,如果存在異構的兩套環境,完全可以同時提供服務,無需采用熱備方式造成資源的浪費。另外如果是性能容量相等的兩套環境,那么主用環境出現性能問題時,備用環境同樣是無能為力的,不如同時使用將整體性能提升一倍。
圖片
圖片
性能方面,系統設計整體性能容量應滿足未來五年的發展需求,通過開啟遞歸服務器緩存可以極大降低權威服務器的性能壓力,保證域名解析系統性能有足夠的冗余。當出現權威服務器性能壓力過大時,首先確定造成壓力突增的域名,增加該域名的TTL時間以增加域名在LDNS上的緩存時間來緩解權威服務器壓力,緊急情況下,考慮直接關閉智能解析,降低智能解析占用的服務器性能,采用靜態解析方式提供域名服務。
四、域名安全設計
01安全威脅防御
面對DNS flood攻擊、DNS污染和DNS隱蔽隧道等安全威脅,我們采取了一系列監控和防護措施,確保系統的安全性。
- DNS flood攻擊,主要通過短時間發起大量的DNS請求,耗盡域名解析系統的性能的一種DDOS攻擊,在內網比較少見,更多可能因為應用配置不當,導致上線時發起大量訪問。針對這種情況,可以按照性能達到上限的方式進行處理。域名解析系統應該進行兩方面的監控:解析日志數據和解析流量數據,建立域名解析監控機制,對于短時間域名查詢量爆發,可以及時定位到查詢發起客戶端地址和被查詢的域名,后續可采取關停客戶端或者調整域名TTL時間的方式進行處置。
圖片
- DNS污染,又稱為DNS緩存中毒或者DNS投毒,其主要目的是通過搶先應答偽造的權威DNS應答報文,篡改解析的IP地址,使得用戶請求的域名被錯誤的解析到攻擊者指定的IP地址。此類攻擊可以通過在遞歸服務器上開啟防DNS投毒功能,開啟后遞歸服務器進行迭代查詢時將使用隨機大小寫的域名字符串,使得攻擊者難以偽造DNS請求響應報文進行投毒。
- DNS隱蔽隧道,并不是針對域名解析系統的一種攻擊,而是利用DNS查詢原理,實現將內網數據傳到互聯網的攻擊技手段。內網與互聯網完全隔離,無法解析互聯網域名,故不存在DNS隧道風險,此類攻擊主要發生在互聯網邊界,防護此類攻擊主要靠部署全流量安全設備或者專用DNS防護設備,對DNS請求流量進行監控,DNS解析日志的分析也可以輔助進行風險客戶端定位。
02其他管控措施分析
是否需要關閉DNS的TCP53端口?
建議區域間的防火墻關閉TCP53訪問。DNS協議實際規定了TCP 53和UDP 53都是DNS服務端口,正常情況下DNS使用UDP協議進行通信,當DNS數據報文過大時,如zone transfer操作,DNS將通過TCP端口進行報文傳輸。但是日常DNS使用僅僅請求域名和應答解析地址,對于大報文傳輸是沒有要求的。反而是異常行為,如DNS隱蔽隧道、惡意域名解析、通過zone transfer竊取域名信息等會需要用到更大的報文。因此如果只是正常使用域名,建議防火墻關閉TCP 53端口訪問。
是否需要啟用DNSSEC?
不建議啟用。DNSSEC將DNS的通信變成了加密通信,可以提高DNS的安全性,有效防止DNS劫持和DNS污染,但是DNSSEC涉及加密通信會大大降低DNS的整體性能,使其發更容易性能耗盡,同時加密通信會增加額外的帶寬開銷,可能需要開通TCP53端口來允許大報文的傳輸,引入其他安全風險,另外流量分析類產品也會因為無法分析加密流量而失效,對于隱蔽隧道的監控會徹底失效,同樣的,DNS問題定位所需要的抓包分析手段也會失效。簡單來說啟用DNSSEC引入的風險和管理難度增加,不建議開啟。
五、總結
G行數據中心的域名解析系統通過低耦合、高冗余等原則,支撐了多數據中心間的高效流量調度和業務雙活。隨著全棧云、大數據、人工智能技術的推廣,域名解析系統將面臨更大規模的域名請求和流量調度的需求。G行的域名解析系統也將與時俱進,通過不斷的技術更新和架構升級來滿足這些新興技術帶來的挑戰,實現持續安全運營。
圖片
作者 | 張林
專注于網絡四到七層技術及相關安全技術的研究和應用,網絡領域中最懂應用,應用領域中最懂網絡,爭取再發光20年。