域名系統（簡稱 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 網路？簡單決策流程，找到最適合你的 Google Cloud 網路連線方案
善用 Cloud DNS，掌握混合式雲端架構的網路連線
管理 DNS 或許不是您的日常工作，但是在設定企業雲端環境時，了解 DNS 的運作方法非常重要。在本文中，我們展示了如何使用 Google 的某些 DNS 架構，將區域、對等互連和轉送功能結合起來，將多個區域連線到您的本地 DNS 基礎架構。
（本文翻譯改編自 Google Cloud。）
相關文章
