域名系統(簡稱 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 被引入模型中,到達正確來源的機會就會隨之減少。

由出站轉送區域 (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 網路連線方案
善用 Cloud DNS,掌握混合式雲端架構的網路連線
管理 DNS 或許不是您的日常工作,但是在設定企業雲端環境時,了解 DNS 的運作方法非常重要。在本文中,我們展示了如何使用 Google 的某些 DNS 架構,將區域、對等互連和轉送功能結合起來,將多個區域連線到您的本地 DNS 基礎架構。
(本文翻譯改編自 Google Cloud。)
