[[203414]]

在 GitHub，我們最近從頭改進了 DNS。這包括了我們?nèi)绾闻c外部 DNS 提供商交互以及我們?nèi)绾卧趦?nèi)部向我們的主機提供記錄。為此，我們必須設計和構(gòu)建一個新的 DNS 基礎設施，它可以隨著 GitHub 的增長擴展并跨越多個數(shù)據(jù)中心。

以前，GitHub 的 DNS 基礎設施相當簡單直接。它包括每臺服務器上本地的、只具備轉(zhuǎn)發(fā)功能的 DNS 緩存服務器，以及一對被所有這些主機使用的緩存服務器和權(quán)威服務器主機。這些主機在內(nèi)部網(wǎng)絡以及公共互聯(lián)網(wǎng)上都可用。我們在緩存守護程序中配置了區(qū)域zone存根stub，以在本地進行查詢，而不是在互聯(lián)網(wǎng)上進行遞歸。我們還在我們的 DNS 提供商處設置了 NS 記錄，它們將特定的內(nèi)部域domain指向這對主機的公共 IP，以便我們網(wǎng)絡外部的查詢。

這個配置使用了很多年，但它并非沒有缺點。許多程序?qū)τ诮馕?DNS 查詢非常敏感，我們遇到的任何性能或可用性問題在***的情況下也會導致服務排隊和性能降級，而最壞情況下客戶會遭遇服務中斷。配置和代碼的更改可能會導致查詢率發(fā)生大幅度的意外變化。因此超出這兩臺主機的擴展成為了一個問題。由于這些主機的網(wǎng)絡配置，如果我們只是繼續(xù)添加 IP 和主機的話存在一些本身的問題。在試圖解決和補救這些問題的同時，由于缺乏測量指標和可見性，老舊的系統(tǒng)難以識別問題的原因。在許多情況下，我們使用 tcpdump 來識別有問題的流量和查詢。另一個問題是在公共 DNS 服務器上運行，我們處于泄露內(nèi)部網(wǎng)絡信息的風險之下。因此，我們決定建立更好的東西，并開始確定我們對新系統(tǒng)的要求。

我們著手設計一個新的 DNS 基礎設施，以改善上述包括擴展和可見性在內(nèi)的運維問題，并引入了一些額外的需求。我們希望通過外部 DNS 提供商繼續(xù)運行我們的公共 DNS 域，因此我們構(gòu)建的系統(tǒng)需要與供應商無關。此外，我們希望該系統(tǒng)能夠服務于我們的內(nèi)部和外部域，這意味著內(nèi)部域僅在我們的內(nèi)部網(wǎng)絡上可用，除非另有特別配置，而外部域也不用離開我們的內(nèi)部網(wǎng)絡就可解析。我們希望新的 DNS 架構(gòu)不但可以基于部署的工作流進行更改，并可以通過我們的倉庫和配置系統(tǒng)使用 API 自動更改 DNS 記錄。新系統(tǒng)不能有任何外部依賴，太依賴于 DNS 功能將會陷入級聯(lián)故障，這包括連接到其他數(shù)據(jù)中心和其中可能有的 DNS 服務。我們的舊系統(tǒng)將緩存服務器和權(quán)威服務器在同一臺主機上混合使用。我們想轉(zhuǎn)到具有獨立角色的分層設計。***，我們希望系統(tǒng)能夠支持多數(shù)據(jù)中心環(huán)境，無論是 EC2 還是裸機。

實現(xiàn)

為了構(gòu)建這個系統(tǒng)，我們確定了三類主機：緩存主機cache、邊緣主機edge和權(quán)威主機authority。緩存主機作為遞歸解析器recursive resolver和 DNS “路由器” 緩存來自邊緣層的響應。邊緣層運行 DNS 權(quán)威守護程序，用于響應緩存層對 DNS 區(qū)域zone的請求，其被配置為來自權(quán)威層的區(qū)域傳輸zone transfer。權(quán)威層作為隱藏的 DNS 主服務器master，作為 DNS 數(shù)據(jù)的規(guī)范來源，為來自邊緣主機的區(qū)域傳輸zone transfer提供服務，并提供用于創(chuàng)建、修改或刪除記錄的 HTTP API。

在我們的新配置中，緩存主機存在于每個數(shù)據(jù)中心中，這意味著應用主機不需要穿過數(shù)據(jù)中心邊界來檢索記錄。緩存主機被配置為將區(qū)域zone映射到其地域region內(nèi)的邊緣主機，以便將我們的內(nèi)部區(qū)域zone路由到我們自己的主機。未明確配置的任何區(qū)域zone將通過互聯(lián)網(wǎng)遞歸解析。

邊緣主機是地域性的主機，存在我們的網(wǎng)絡邊緣 PoP(存在點Point of Presence)內(nèi)。我們的 PoP 有一個或多個依賴于它們進行外部連接的數(shù)據(jù)中心，沒有 PoP 數(shù)據(jù)中心將無法訪問互聯(lián)網(wǎng)，互聯(lián)網(wǎng)也無法訪問它們。邊緣主機對所有的權(quán)威主機執(zhí)行區(qū)域傳輸zone transfer，無論它們存在什么地域region或位置location，并將這些區(qū)域存在本地的磁盤上。

我們的權(quán)威主機也是地域性的主機，只包含適用于其所在地域region的區(qū)域zone。我們的倉庫和配置系統(tǒng)決定一個區(qū)域zone存放在哪個地域性權(quán)威主機regional authority，并通過 HTTP API 服務來創(chuàng)建和刪除記錄。 OctoDNS 將區(qū)域映射到地域性權(quán)威主機，并使用相同的 API 創(chuàng)建靜態(tài)記錄，以及確保動態(tài)源處于同步狀態(tài)。對于外部域 (如 github.com)，我們有另外一個單獨的權(quán)威主機，以允許我們可以在連接中斷期間查詢我們的外部域。所有記錄都存儲在 MySQL 中。

可運維性

遷移到更現(xiàn)代的 DNS 基礎設施的巨大好處是可觀察性。我們的舊 DNS 系統(tǒng)幾乎沒有指標，只有有限的日志。決定使用哪些 DNS 服務器的一個重要因素是它們所產(chǎn)生的指標的廣度和深度。我們最終用 Unbound 作為緩存主機，NSD 作為邊緣主機，PowerDNS 作為權(quán)威主機，所有這些都已在比 GitHub 大得多的 DNS 基礎架構(gòu)中得到了證實。

當在我們的裸機數(shù)據(jù)中心運行時，緩存通過私有的任播anycast IP 訪問，從而使之可以到達最近的可用緩存主機。緩存主機已經(jīng)以機架感知的方式部署，在它們之間提供了一定程度的平衡負載，并且與一些電源和網(wǎng)絡故障模式相隔離。當緩存主機出現(xiàn)故障時，通常將用其進行 DNS 查詢的服務器現(xiàn)在將自動路由到下一個最接近的緩存主機，以保持低延遲并提供對某些故障模式的容錯。任播允許我們擴展單個 IP 地址后面的緩存數(shù)量，這與先前的配置不同，使得我們能夠按 DNS 需求量運行盡可能多的緩存主機。

無論地域或位置如何，邊緣主機使用權(quán)威層進行區(qū)域傳輸。我們的區(qū)域zone并沒有大到在每個地域region保留所有區(qū)域zone的副本成為問題。(LCTT 譯注：此處原文“Our zones are not large enough that keeping a copy of all of them in every region is a problem.”，根據(jù)上下文理解而翻譯。)這意味著對于每個區(qū)域，即使某個地域處于脫機狀態(tài)，或者上游服務提供商存在連接問題，所有緩存服務器都可以訪問具備所有區(qū)域的本地副本的本地邊緣服務器。這種變化在面對連接問題方面已被證明是相當有彈性的，并且在不久前本來會導致客戶面臨停止服務的故障期間幫助保持 GitHub 可用。

那些區(qū)域傳輸包括了內(nèi)部和外部域從它們相應的權(quán)威服務器進行的傳輸。正如你可能會猜想像 github.com 這樣的區(qū)域是外部的，像 github.net 這樣的區(qū)域通常是內(nèi)部的。它們之間的區(qū)別僅在于我們使用的類型和存儲在其中的數(shù)據(jù)。了解哪些區(qū)域是內(nèi)部和外部的，為我們在配置中提供了一些靈活性。

$ dig +short github.com 
192.30.253.112 
192.30.253.113 

公共區(qū)域zone被同步到外部 DNS 提供商，并且是 GitHub 用戶每天使用的 DNS 記錄。另外，公共區(qū)域在我們的網(wǎng)絡中是完全可解析的，而不需要與我們的外部提供商進行通信。這意味著需要查詢 api.github.com 的任何服務都可以這樣做，而無需依賴外部網(wǎng)絡連接。我們還使用了 Unbound 的 stub-first 配置選項，它給了我們第二次查詢的機會，如果我們的內(nèi)部 DNS 服務由于某些原因在外部查詢失敗，則可以進行第二次查找。

$ dig +short time.github.net 
10.127.6.10 

大部分的 github.net 區(qū)域是完全私有的，無法從互聯(lián)網(wǎng)訪問，它只包含 RFC 1918 中規(guī)定的 IP 地址。每個地域和站點都劃分了私有區(qū)域。每個地域和/或站點都具有適用于該位置的一組子區(qū)域，子區(qū)域用于管理網(wǎng)絡、服務發(fā)現(xiàn)、特定的服務記錄，并且還包括在我們倉庫中的配置主機。私有區(qū)域還包括 PTR 反向查找區(qū)域。

總結(jié)

用一個新系統(tǒng)替換可以為數(shù)百萬客戶提供服務的舊系統(tǒng)并不容易。使用實用的、基于需求的方法來設計和實施我們的新 DNS 系統(tǒng)，才能打造出一個能夠迅速有效地運行、并有望與 GitHub 一起成長的 DNS 基礎設施。

想幫助 GitHub SRE 團隊解決有趣的問題嗎?我們很樂意你加入我們。在這申請。