了解 Google Cloud DNS 中的轉送 (forwarding)、對等互連 (peering) 與私人可用區 (private zones) 服務

域名系統(簡稱 DNS)是網際網路世界最基礎的服務之一,它將人性化的域名轉換為 IP 位址。DNS 通常由組織內專業的網路工程師處理,但對於不常使用它的人來說,DNS 就像是一個黑盒子。首先,DNS 術語可能會造成混淆,且某些術語在雲端網路(例如 peering)中,可能具有不同的含義。了解 DNS 的運作原理非常重要,您會需要用 DNS 將您的應用程式提供給企業客戶使用(尤其在雲端環境中)。本文將帶您探討 DNS 的眾多功能與使用情境。

如果您在 Google Cloud 上運行服務,那麼您很有可能使用 Cloud DNS 這項可擴充且穩固可靠的 DNS 代管服務,而它就運行在 Google 的基礎架構上。它具有低延遲、高可用性和可擴展性,是一種經濟高效的方式,使您的客戶可以使用您的應用程式和服務。

我們經常碰到的、比較複雜 DNS 設定之一,就是建立多個專案和 VPC。這些情境,都是需要建立與本地 DNS 資源的連線。除非本地網路或其它雲端有建立外部連線,否則 VPC 在邏輯上,看起來就像是「孤島」或獨立的網路。因此,邏輯上的假設是,每個 VPC 會使用自己的轉送區域 (forwarding zone) 並將 DNS 請求獨立轉發回本地進行解析。

然而,隔離的 VPC 會帶來更多挑戰,而且,您擁有的 VPC 越多,難度就越大。首先,讓我們解釋一下為什麼這會具有挑戰性,接著再說明如何解決這樣的問題。

在 VPC 中處理 DNS 轉送請求的麻煩之處

基本上,路由是一個挑戰。Google 使用一個出口代理程式 (egress proxy) 來處理所有出站轉送區域 (outbound forwarding zone) 到本地環境的 DNS 請求。這個高可用性且可擴展的代理池,都使用相同的 IP 位址區段,所有 VPC 也是如此。如果您有多個 VPC 將 DNS 請求轉發到同一個地端網路,則會無法建立一條路由路徑來專門將回應發送到原始 VPC(因為它們都使用相同的 IP 區段作為代理)。使用代理池的 VPC 越多,將內容發送回錯誤 VPC 的機會就越大。我們來看下面的例子。

在下圖中,兩個 VPC A 和 B 都設定了到本地端的出站轉送區段,且雲端路由器 A 和 B 都在 35.199.192.0/19 的 DNS 代理範圍。對於本地網路,所有流量似乎都來自於 35.199.192.0/19,而且在本地產生回應時,返回流量可能回傳到錯誤的 VPC 網路中。在這種情況下,本地網路有一半的機會猜測哪個 VP C發起了請求。但隨著越來越多的 VPC 被引入模型中,到達正確來源的機會就會隨之減少。

(圖片來源: Google Cloud)

由出站轉送區域 (Outbound forwarding zones) 和 DNS 對等互連 (peering),連接多個 VPC

為了解決將多個 VPC 連線至本地網路的難題,您需要在 hub-and-spoke 模型中結合使用出站轉送區域和 DNS 對等互連。hub VPC 使用 DNS 轉送 (DNS forwarding) 功能實現雲地網路的混合連接,而 spoke VPC 則使用 DNS 對等互連 (DNS peering) 連線至 hub VPC。請看下方的例子。

如下圖,我們在 VPC H 中設定了一個出站轉送區域,其它 VPC 以 VPC H 作為端點。從本地解析的任何請求,現在都將從原始 VPC(A、B或C)傳到 VPC H。一旦進入 VPC H,它將識別為出站轉送區域的一部分,並透過已建立的網路連線,將請求轉發到本地。在這種情況下,只有 VPC H 的雲端路由器由 35.199.192.0/19 範圍發佈,因此,當這個查詢被 route 回 Google Cloud 時,路由路徑上只會有一個 VPC 網路路徑。然後 VPC H 將適當的資訊串接回原始 VPC(A、B 或 C),達到預期功能。

(圖片來源: Google Cloud)

不熟悉 Google Cloud 網路?簡單決策流程,找到最適合你的 Google Cloud 網路連線方案

善用 Cloud DNS,掌握混合式雲端架構的網路連線

管理 DNS 或許不是您的日常工作,但是在設定企業雲端環境時,了解 DNS 的運作方法非常重要。在本文中,我們展示了如何使用 Google 的某些 DNS 架構,將區域、對等互連和轉送功能結合起來,將多個區域連線到您的本地 DNS 基礎架構。

(本文翻譯改編自 Google Cloud。)


連絡「GCP 專門家」