TLD DNS 伺服器如何處理如此多的區域檔案更新?

TLD DNS 伺服器如何處理如此多的區域檔案更新?

我一直想知道 TLD(例如 .com)的 DNS 基礎架構是如何設計的。它不僅要能夠保持高水準的可靠性,還要支援大量記錄的即時更新。

我假設 ISC 的 BIND 是在該層級使用的。對於如何使用 BIND 建立可擴展的基礎設施,我有一個相當清晰的了解。我不清楚的是,有人會如何設計一個系統,可以每隔幾秒鐘處理數百個 DNS 區域的新增、刪除和變更。世界上有無數的網域註冊商,光是 .com 就可能看到大量的活動。基於 BIND 區域文件建構的系統如何適應如此大的變化?

我是否有理由懷疑 TLD 運營商正在使用文字檔案並在每次註冊新 .com 時不斷讓 BIND 重新加載更改?如果是這樣,他們會做什麼?它是支援 SQL 或 LDAP 資料庫嗎?這甚至可以擴展嗎?

答案1

首先,你真的認為世界上每秒的信用卡交易量比我們所說的更新還要多,而最終僅由 2 或 3 個公司管理嗎?這些工作,所以這是一個可以解決的問題:-)

其次,您可能對更新是如何發生的感到困惑,因為這是兩個平面相交的不常理解的部分:註冊平面和發布平面。您可能也會對註冊名稱伺服器上到底發生了什麼事感到困惑(僅維護NS網域委託的記錄,而不是這些區域的完整內容)。

但在討論之前,您似乎也假設更新應該是即時的,而它們既不需要而且通常也不需要。由於 TTL,DNS 中無論如何都不是即時的。

回到你的兩架飛機:

  • 當名稱伺服器發生變更以及其他具有 DNS 副作用的操作(例如:設定 EPPclientHold狀態)時,註冊商會向註冊管理機構發送更新;這是註冊平面,它與 DNS 發布完全無關,並且通常使用稱為 EPP 的協定;當註冊機構回覆“更新已接受”時,這絕對並不意味著它已經在其 DNS 基礎設施上發布,這只是一個保證“它將在某個時候發布”
  • 註冊管理機構維護 DNS 發布平面,確保其名稱伺服器確實NS為所有授權(即在其管理的 TLD 下註冊的所有網域)發布正確的記錄。

因此,更改的數量可能比您想像的要少得多:如果所有者.com使用新記錄更改了其區域的內容,在大多數情況下,註冊商無需執行任何操作,並且註冊管理機構也不會進行任何更改名稱伺服器。

並且這些變更不會透過 DNS 更新機制發生。註冊商使用特定協定 EPP 推送更改,更改以某種方式儲存在某些註冊資料庫中,之後註冊管理機構在其權威名稱伺服器上發布新資料。

您似乎也認為“實時”是強制性的。至少在技術上不是這樣,甚至可能是無效的設計(考慮一下您是否想要進行新更改是否有意義的測試,正如某些註冊管理機構正在通過檢查名稱名稱伺服器是否已正確配置以解析名稱所做的那樣)它們很快就會被列為權威測試,例如 DNSSEC 測試...)。

許多註冊管理機構都使用典型的設定方式,提供諸如「更新延遲10 分鐘」或「1 小時」之類的內容,即在某個內部緩衝區中儲存給定時間段內請求的所有更改,然後一勞永逸。

我假設 ISC 的 BIND 是在該層級使用的。

一點也不。 Verisign 運行自己的專有名稱伺服器軟體,稱為 Atlas。請參閱範例https://www.enterpriseappstoday.com/news/verisign-accelerates-dns.html 請注意,在這篇 2004 年的文章中已經說過:

VeriSign 命名和目錄服務 (VNDS) 承諾在五分鐘內更新 13 個核心 .com 和 .net 權威名稱伺服器。目前的價格約為每天兩次。

當然,從那時起情況有所改善。但我相信,即使每 5 分鐘一次對於 DNS 的實際使用來說也已經足夠好了。

也可能存在合約義務,特別是對於與 ICANN 簽訂合約的 gTLD 註冊管理機構和註冊服務商。目前威瑞信與 ICANN 的合約位於https://www.icann.org/en/registry-agreements/details/com 您可以在附錄第 6.6 節中找到https://www.icann.org/en/registry-agreements/com/com-registry-agreement-appendix-7-1-12-2012-en有關更新約束的詳細資訊:

6.6 更新頻率。註冊管理運行機構及時更新 DNS 名稱伺服器和 Whois 上的資料。 ICANN 認可的註冊商透過 SRS 記錄這些更新。然後,SRS 更新 DNS 名稱伺服器和 Whois。註冊管理運作機構近乎即時地處理此更新。

關於 DNS 名稱伺服器和 Whois 的更新頻率,承諾的效能規格是每月時間範圍內 95% 的交易為 3 分鐘。也就是說,每月時間範圍內 95% 的 DNS 名稱伺服器和 Whois 更新將在 3 分鐘內完成。更新頻率是從註冊管理運行機構確認更新的時間到更新出現在 DNS 名稱伺服器和 Whois 中的時間計算的。將根據附錄 4 每月向 ICANN 報告更新頻率績效。

請注意用於大量 SLA 的常用標記“95%”。因此,在可行的情況下它接近實時,但實際上通常為 3 分鐘(因此是上述典型的緩衝區設定)。

對於如何使用 BIND 建立可擴展的基礎設施,我有一個相當清晰的了解。我不清楚的是,有人會如何設計一個系統,可以每隔幾秒鐘處理數百個 DNS 區域的新增、刪除和變更。

Verisign 只有幾個區域:.com.net、一些 IDN 等。當然不是數百個,每秒都有很多變化。

您可能/希望對確實託管數百萬個區域且更新頻率可能很高的 DNS 提供者更感興趣。以下是 CloudFlare 的一篇文章,其中解釋了他們在權威 DNS 服務方面如何提高效能:https://blog.cloudflare.com/how-we-made-our-dns-stack-3x-faster/

世界上有無數的網域註冊商

不,不是全部。遠非無數。事實上,不到 2000 個,可能只有 500 個真正活躍且變化量很大的。所有 gTLD 註冊商都必須獲得 ICANN 的認可。您可以在以下位置找到它們的完整清單:https://www.icann.org/en/accredited-registrars

我是否有理由懷疑 TLD 運營商正在使用文字檔案並在每次註冊新 .com 時不斷讓 BIND 重新加載更改?

沒有任何理智的高級交易名稱伺服器軟體會得到文字檔案的支援。即使綁定也不是:啟用動態更新時,您有一個“日誌”文件(二進位),並且您特別不應該編輯該區域的文本文件版本(不首先凍結更新,然後在更新後再次允許它們)編輯) 。

如果是這樣,他們會做什麼?它是支援 SQL 或 LDAP 資料庫嗎?這甚至可以擴展嗎?

我懷疑 SQL 或 LDAP 是否是 DNS 的良好儲存引擎。請記住,DNS 本質上是分層的,這會帶來各種限制。

答案2

首先,在某些情況下您不必立即重新載入。

如果您的 SLA 規定“向我們付款,您將在 X 小時內註冊您的網域”,您甚至可以使用某些 cron 作業或類似作業定期重新加載。因此,一些註冊商可能會使用平面檔案並定期重新載入。

請記住,您可以將多個DNS 伺服器關聯到相同IP 位址(例如,使用任播),因此您甚至可以設定「滾動部署」機制,該機制會更改各處的平面檔案並在某個時間重新載入一台DNS 伺服器。

也就是說,Bind >9 支援 DLZ(動態可載入區域),這本質上允許 Bind 使用資料庫作為區域資料後端。只要您的資料庫擁有有效的 DLZ 驅動程序,就可以根據經典的資料庫擴展策略來擴展資料庫(和資料庫連接)。

最後,正如一則評論所說,垂直擴展(即每台伺服器擁有大量 CPU、RAM 和 IOPS)會有所幫助。

有一個2009年的薩諾格您可能會發現有趣的幻燈片,儘管它顯然有點過時:https://www.sanog.org/resources/sanog14/sanog14-devdas-dns-scalability.pdf

相關內容