域名系統（簡稱 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。）