Cloud DNS 最佳做法

本文提供私人區域、DNS 轉送的最佳做法,以及混合式 DNS 的參考架構。

對使用者和應用程式而言,使用網域名稱系統 (DNS) 稱呼應用程式和服務都比較輕鬆,因為名稱比 IP 位址更容易記住,也更具彈性。混合式環境中,通常包含地端部署平台和一或多個雲端平台,因此經常需要跨環境存取內部資源的 DNS 記錄。傳統上,地端部署 DNS 記錄是使用權威 DNS 伺服器手動管理,例如 UNIX/Linux 環境中的 BIND,或 Microsoft Windows 環境中的 Active Directory。

本文將說明在不同環境之間轉送私人 DNS 要求的最佳做法,確保可從地端部署環境和 Google Cloud內存取服務。

一般原則

瞭解 Google Cloud上的 DNS 概念

在 Google Cloud使用 DNS時,務必瞭解 Google Cloud 中 DNS 解析和網域名稱適用的不同系統和服務:

  • 內部 DNS 服務可自動為 Compute Engine 上的虛擬機器和內部負載平衡器,建立 DNS 名稱。
  • Cloud DNS 服務可提供低延遲和高可用性的 DNS 區域服務,可做為用於網際網路公開區域的權威 DNS 伺服器,或只用於您網路私人區域的權威 DNS 伺服器。
  • Managed Service for Microsoft Active Directory 是可用性高的強化服務,可執行 Microsoft Active Directory,包括網域控制器。
  • 公用 DNS 是 Google 服務,不屬於 Google Cloud ,可做為開放式遞迴 DNS 解析器。
  • Cloud Domains 是網域註冊商,可供您在 Google Cloud中購買、轉移及管理網域。Cloud Domains 可讓您透過 API 與網域註冊系統互動。

確認相關人員、工具和流程

如要在混合式環境建構 DNS 策略,務必先熟悉目前架構,並洽詢所有相關人員。請執行下列步驟:

  • 找出並聯絡組織的企業 DNS 伺服器管理員,請他們提供必要設定的資訊,瞭解如何將地端部署設定對應至Google Cloud上的合適架構。如要瞭解存取Google Cloud DNS 記錄的方法,請參閱「使用條件轉送從地端部署環境存取 DNS 記錄」。
  • 熟悉目前的 DNS 軟體,找出組織內部使用的網域名稱。
  • 找出網路團隊的聯絡人,請他們確保流量正確轉送至 Cloud DNS 伺服器。
  • 熟悉混合式連線策略,以及混合雲和多雲端的模式與做法。

建立一致的命名標準

請建立全組織一致的命名標準。舉例來說,假設組織使用 example.com 做為第二層網域名稱,並將該網域用於公開資源 (例如 www.example.com)。就本文而言,公開區域的託管位置並不重要,因為本文的範圍僅限遷移私人區域。

如要為地端部署的企業資源命名,可以選擇下列模式:

  • 地端部署伺服器和Google Cloud可以使用不同的網域名稱。這個模式會在不同環境使用不同網域,例如 corp.example.com 用於地端部署伺服器,gcp.example.com 用於 Google Cloud上所有資源。如果使用其他公有雲環境,每個環境都可以有各自的子網域。這是建議採用的模式,因為可以在各環境之間轉送要求。

    您也可以使用不同的網域名稱,例如 example.comexample.cloud

  • 您可以將 Google Cloud 網域設為子網域,隸屬於包含地端部署伺服器的網域。使用 example.com 網域時,地端部署環境可使用 corp.example.com, Google Cloud 則可使用 gcp.corp.example.com。若大部分資源仍保留在地端部署環境,通常會使用這個模式。

  • 您可以將地端部署網域設為子網域,隸屬於包含Google Cloud 記錄的網域。使用 example.com 網域時, Google Cloud可使用 corp.example.com,地端部署環境則可使用 dc.corp.example.com。這種模式並不常見,但如果數位組織的地端部署環境較小,或許可採用這種模式。

  • Google Cloud 和地端部署環境可以使用相同網域。在本案例中, Google Cloud 和地端部署環境都會使用 corp.example.com 網域的資源。不過,請避免使用這種模式,因為會大幅增加在混合式環境管理記錄的難度,而且只在使用單一權威 DNS 系統時才可行。

本頁面其餘部分會使用下列網域名稱:

  • example.com 是公開記錄的網域名稱,無論託管位置為何皆然。
  • corp.example.com 是地端部署 DNS 伺服器託管的區域。這個區域會託管地端部署資源的記錄。
  • gcp.example.com 是託管您 Google Cloud 資源記錄的 Cloud DNS 私人代管區域。

圖 1 顯示在地端部署網路和 Google Cloud中,網域名稱設定保持一致。

圖 1. 組織的網域名稱設定保持一致。
圖 1. 網域名稱設定在整個組織保持一致。

如要為虛擬私有雲 (VPC) 網路內的資源命名,可以遵循解決方案指南「虛擬私有雲設計的最佳做法和參考架構」中的指引。

選擇 DNS 解析的執行位置

在混合式環境,DNS 解析可以在不同位置執行。您可以採取以下做法:

  • 採用具備兩套權威 DNS 系統的混合做法。
  • 維持在地端部署環境執行 DNS 解析。
  • 改由 Cloud DNS 執行所有 DNS 解析。

我們建議採用混合做法,因此本文將重點說明此做法。不過,為求完整,本文也會簡要說明其他做法。

採用具備兩套權威 DNS 系統的混合做法

建議您採用具備兩個權威 DNS 系統的混合做法。在這個做法中:

  • Cloud DNS 會為您的私人 Google Cloud 環境執行權威 DNS 解析。
  • 地端部署資源的權威 DNS 解析,則由現有的地端部署 DNS 伺服器託管。

圖 2 顯示這種做法。

圖 2. 混合式 DNS 架構,同時使用 Cloud DNS 和地端部署 DNS 伺服器提供權威 DNS 解析。
圖 2. 混合式 DNS 架構,同時使用 Cloud DNS 和地端部署 DNS 伺服器提供權威 DNS 解析。

圖 2 所示情境是建議做法。下列細節請見本頁後續內容:

  • 如何使用私人區域和 DNS 轉送,設定環境之間的轉送。
  • 如何設定防火牆和路由。
  • 說明如何使用一或多個 VPC 網路的參考架構。

維持在地端部署環境執行 DNS 解析

另一種做法是繼續使用現有的地端部署 DNS 伺服器,以權威伺服器的方式託管所有內部網域名稱。在這種情況下,您可以透過傳出 DNS 轉送,使用替代名稱伺服器轉送來自Google Cloud 的所有要求。

這種做法有以下優點:

  • 減少業務流程的變更。
  • 可繼續使用現有工具。
  • 可使用拒絕清單,在地端部署環境篩選個別 DNS 要求。

但有以下缺點:

  • 來自 Google Cloud 的 DNS 要求延遲時間較長。
  • 系統依賴地端部署環境的連線能力執行 DNS 作業。
  • 可能難以整合高度彈性的環境,例如自動調度資源的執行個體群組。
  • 系統可能無法與 Dataproc 等產品相容,因為這些產品依賴 Google Cloud執行個體名稱的反向解析。

改由 Cloud DNS 執行所有 DNS 解析

另一種做法是遷移至 Cloud DNS,做為所有網域解析的權威服務。您可以使用私人區域和傳入 DNS 轉送,將現有的地端部署名稱解析遷移至 Cloud DNS。

這種做法有以下優點:

  • 不必在地端部署環境維護高可用性 DNS 服務。
  • 您的系統可以使用 Cloud DNS,享有集中式記錄和監控的優勢。

但有以下缺點:

  • 來自地端部署環境的 DNS 要求延遲時間較長。
  • 您的系統需要與 VPC 網路建立可靠連線,才能解析名稱。

Cloud DNS 私人區域的最佳做法

私人區域會託管僅供組織內部查看的 DNS 記錄。本文未述及 Cloud DNS 公開區域。公開區域涵蓋組織的公開記錄,例如公開網站的 DNS 記錄,在混合式設定中不太重要。

使用自動化功能管理 Shared VPC 主專案的私人區域

如果在組織內使用 Shared VPC 網路,則必須在主專案中,透過 Cloud DNS 託管所有私人區域。所有服務專案都可在附加至 Shared VPC 網路的私人區域中,自動存取記錄。或者,您也可以使用跨專案繫結,在服務專案中設定區域。

圖 3 顯示私人區域在 Shared VPC 網路託管的方式。

圖 3. 在 Shared VPC 網路託管的私人區域 (按一下可放大)。
圖 3. 這個設定說明如何將私人區域附加至 Shared VPC。

如要讓團隊自行設定 DNS 記錄,建議使用自動化功能建立 DNS 記錄。舉例來說,您可以建立網頁應用程式或內部 API,方便使用者在特定子網域設定自己的 DNS 記錄。應用程式會驗證記錄是否符合組織規則。

或者,也可以透過 TerraformCloud Deployment Manager 描述元的形式,將 DNS 設定放在程式碼存放區 (例如 Cloud Source Repositories),並接受團隊的提取要求。

在上述兩種情況下,主專案中具備 IAM DNS 管理員角色的服務帳戶,可在變更獲准後自動完成部署。

依最小權限原則設定 IAM 角色

請依循最小權限安全性原則,只授權組織中需要變更 DNS 記錄的使用者執行這項工作。請避免使用基本角色,因為這可能導致使用者存取超出需求的資源。Cloud DNS 提供角色和權限,方便您授予 DNS 專屬的讀取和寫入權限。

如有必要區分建立私人 DNS 區域與公開區域的權限,請使用 dns.networks.bindPrivateDNSZone 權限。

DNS 轉送區域和伺服器政策的最佳做法

Cloud DNS 提供 DNS 轉送區域DNS 伺服器政策,供您在地端部署和 Google Cloud 環境之間查詢 DNS 名稱。您可以透過多種方式設定 DNS 轉送。下一節將列出混合式 DNS 設定的最佳做法。如要進一步瞭解這些最佳做法,請參閱「混合式 DNS 參考架構」。

使用轉送區域查詢地端部署伺服器

如要確保能在地端部署環境查詢 DNS 記錄,請在您企業資源適用的地端部署網域 (例如 corp.example.com),設定轉送區域。相較於啟用替代名稱伺服器的 DNS 政策,這個方法更為理想。這樣一來,Compute Engine 內部 DNS 名稱仍可存取,外部 IP 位址也仍會解析,不必透過地端部署名稱伺服器的額外躍點。

如要瞭解使用這項設定的流量流程,請參閱「混合式 DNS 參考架構」。

只有在地端部署環境需要監控或篩選所有 DNS 流量,且私人 DNS 記錄無法滿足需求時,才應使用替代名稱伺服器。

使用 DNS 伺服器政策支援地端查詢

如要允許地端部署主機查詢 Cloud DNS 私人區域 (例如 gcp.example.com) 中託管的 DNS 記錄,請利用傳入 DNS 轉送機制,建立 DNS 伺服器政策。透過這項機制,您的系統可查詢專案中的所有私人區域,以及內部 DNS IP 位址和對接區域。

如要瞭解使用這項設定的流量流程,請參閱「混合式 DNS 參考架構」。

將 Google Cloud 和地端部署防火牆設為允許 DNS 流量

請執行下列操作,確保 VPC 網路或地端部署環境內沒有任何 DNS 流量遭到篩除:

  • 確認地端部署防火牆會傳遞來自 Cloud DNS 的查詢。Cloud DNS 會從 IP 位址範圍 35.199.192.0/19 傳送查詢。DNS 會使用 UDP 通訊埠 53 或 TCP 通訊埠 53,具體取決於要求或回應的大小。

  • 確認 DNS 伺服器不會封鎖查詢。如果地端部署 DNS 伺服器只接受來自特定 IP 位址的要求,請務必納入 IP 位址範圍 35.199.192.0/19

  • 確認流量可從地端部署環境流向轉送 IP 位址。在 Cloud Router 執行個體,為 VPC 網路的 IP 位址範圍 35.199.192.0/19 新增自訂 advertise 路由,指向地端部署環境。

使用條件式轉送,從地端部署環境存取 DNS 記錄

使用 Cloud DNS 時,如要存取地端部署企業 DNS 伺服器託管的私人記錄,只能使用轉送區域。不過,根據您使用的 DNS 伺服器軟體,可能有多種方法能從地端部署環境,存取 Google Cloud 中的 DNS 記錄。無論何種情況,都可以透過傳入 DNS 轉送,存取記錄:

  • 條件式轉送。使用條件式轉送時,企業 DNS 伺服器會將特定區域或子網域的要求,轉送至 Google Cloud上的轉送 IP 位址。建議採用這種做法,因為這是最不複雜的方式,您可以在企業 DNS 伺服器上集中監控所有 DNS 要求。

  • 委派。如果 Google Cloud 上的私人區域是地端部署區域的子網域,您也可以在區域中設定 NS 項目,將這個子網域委派給Google Cloud 名稱伺服器。使用這項設定時,用戶端可與Google Cloud 上的轉送 IP 位址直接通訊,因此請確保防火牆會傳遞這些要求。

  • 區域轉移。Cloud DNS 不支援區域轉移,因此您無法透過區域轉移,同步處理 DNS 記錄與地端部署 DNS 伺服器。

使用 DNS 對接,避免從多個 VPC 網路傳出轉送

請勿從多個 VPC 網路,使用傳出轉送至地端部署 DNS 伺服器,這會造成流量回傳問題。只有當 DNS 伺服器的回應轉送至發出查詢的 VPC 網路時, Google Cloud 才會接受這些回應。不過,來自任何 VPC 網路的查詢,都擁有相同的來源 IP 位址範圍 35.199.192.0/19。因此,除非您分別設定多個地端部署環境,否則回應無法正確轉送。

圖 4. 多個 VPC 將流量轉送至網路外,就會發生問題。
圖 4. 多個 VPC 網路執行傳出轉送,會發生問題。

建議您指定單一 VPC 網路,透過傳出轉送,查詢地端部署名稱伺服器。其他 VPC 網路就能利用 DNS 對接區域,以指定的 VPC 網路為目標,查詢地端部署名稱伺服器。系統會根據指定 VPC 網路的名稱解析順序,將查詢轉送至地端部署名稱伺服器。如要瞭解這種設定,請參閱「混合式 DNS 參考架構」。

瞭解 DNS 對接和 VPC 網路對接的差異

VPC 網路對接與 DNS 對接不同。VPC 網路對接可讓多個專案中的虛擬機器 (VM) 執行個體彼此連線,但不會變更名稱解析。各 VPC 網路中的資源仍會依循自己的解析順序。

相較之下,DNS 對接則可將特定區域的要求,轉送至其他 VPC 網路。無論 VPC 網路是否互連,您都能將要求轉送至不同 Google Cloud 環境。

VPC 網路對接和 DNS 對接的設定也不同。若是 VPC 網路對接,兩個 VPC 網路都需要設定與另一個 VPC 網路的對接關係。對接隨後會自動設為雙向。

DNS 對接則是單向轉送 DNS 要求,VPC 網路之間不必存在雙向關係。一個稱為 DNS「用戶」網路的 VPC 網路,會在另一個稱為 DNS「供應商」網路的 VPC 網路中,查詢 Cloud DNS 對接區域。供應商網路專案中具備 IAM 權限 dns.networks.targetWithPeeringZone 的使用者,可以在用戶網路和供應商網路之間建立 DNS 對接。如要從用戶 VPC 網路設定 DNS 對接,您必須擁有供應商 VPC 網路主專案的 DNS 對接角色。

若使用自動產生的名稱,請在內部區域使用 DNS 對接

如果內部 DNS 服務建立的 VM 採用自動產生名稱,您可以透過 DNS 對接,將 projectname.internal 區域轉送至其他專案。如圖 5 所示,您可以將中樞專案的所有 .internal 區域分組,設為可從地端部署網路存取這些區域。

圖 5. DNS 對接可用來將所有 .internal 區域整理到中樞。
圖 5. DNS 對接可用來將所有 .internal 區域整理到中樞。

若遇到問題,請參閱疑難排解指南

Cloud DNS 疑難排解指南提供操作說明,協助您解決設定 Cloud DNS 時可能遇到的常見錯誤。

混合式 DNS 參考架構

本節提供一些參考架構,適用於在混合式環境使用 Cloud DNS 私人區域的常見情境。無論何種情境,地端部署資源、 Google Cloud 資源記錄和區域都會在環境中代管。所有記錄都可從地端部署和 Google Cloud 主機查詢。

請使用與您的 VPC 網路設計相對應的參考架構:

  • 使用單一 Shared VPC 網路的混合架構:使用單一 VPC 網路,連線至地端部署環境,或從地端部署環境連線。

  • 使用多個獨立 VPC 網路的混合架構:透過不同的 VPN 通道或 VLAN 連結,將多個 VPC 網路連線至地端部署環境,並共用相同的地端部署 DNS 基礎架構。

  • 使用從中樞 VPC 網路連線至輪輻 VPC 網路的混合架構:使用 VPC 網路對接,讓中樞 VPC 網路連線至多個獨立的輪輻 VPC 網路。

在上述各種情況下,地端部署環境都會連線至 Google CloudVPC 網路,無論是透過一或多個 Cloud VPN 通道,或 Dedicated Interconnect/Partner Interconnect 連線都一樣。各 VPC 網路使用何種連線方式並不重要。

使用單一 Shared VPC 網路的混合架構

最常見的用途是將單一 Shared VPC 網路連線至地端部署環境,如圖 6 所示。

圖 6. 使用單一 Shared VPC 網路連線至地端部署網路的混合架構。
圖 6. 使用單一 Shared VPC 網路連線至地端部署網路的混合架構。

如要設定此架構,請按照下列步驟操作:

  1. 將地端部署 DNS 伺服器設為 corp.example.com 的權威伺服器。
  2. 在 Shared VPC 網路的主專案,設定 Cloud DNS 權威私人區域 (例如 gcp.example.com),並為該區域的資源設定所有記錄。
  3. 在 Shared VPC 網路的主專案設定 DNS 伺服器政策,允許傳入 DNS 轉送。
  4. 設定 DNS 轉送區域,將 corp.example.com 轉送至地端部署 DNS 伺服器。Shared VPC 網路必須獲得授權,才能查詢轉送區域。
  5. 在地端部署 DNS 伺服器上,為 gcp.example.com 設定轉送,指向 Shared VPC 網路的傳入轉送站 IP 位址。
  6. 確認地端部署防火牆允許 DNS 流量。
  7. 在 Cloud Router 執行個體,新增範圍 35.199.192.0/19 的自訂 advertise 路由,指向地端部署環境。

使用多個獨立 VPC 網路的混合架構

混合架構的另一個選項是使用多個獨立的 VPC 網路。您Google Cloud 環境中的這些 VPC 網路,並未透過 VPC 網路對接相互連線。所有 VPC 網路都會使用獨立的 Cloud VPN 通道或 VLAN 連結,連線至地端部署環境。

如圖 7 所示,這種架構的典型用途,是使用獨立的正式環境和開發環境,兩者不會互相通訊,但共用 DNS 伺服器。

圖 7. 混合架構可使用多個獨立 VPC 網路。
圖 7. 混合架構可使用多個獨立的 VPC 網路。

如要設定此架構,請按照下列步驟操作:

  1. 將地端部署 DNS 伺服器設為 corp.example.com 的權威伺服器。
  2. 在正式版 Shared VPC 網路的主專案,設定 Cloud DNS 私人區域 (例如 prod.gcp.example.com),並為該區域的資源設定所有記錄。
  3. 在開發版 Shared VPC 網路的主專案,設定 Cloud DNS 設定私人區域 (例如 dev.gcp.example.com),並為該區域的所有資源設定記錄。
  4. 在正式版 Shared VPC 網路的主專案,設定 DNS 伺服器政策,允許傳入 DNS 轉送。
  5. 在正式版 Shared VPC 網路,將 DNS 區域設為將 corp.example.com 轉送至地端部署 DNS 伺服器。
  6. 從開發版 Shared VPC 網路到正式版 Shared VPC 網路,為 prod.gcp.example.com 設定 DNS 對接區域。
  7. 從正式版 Shared VPC 網路到開發版 Shared VPC 網路,為 dev.gcp.example.com 設定 DNS 對接區域。
  8. 在地端部署名稱伺服器,將 gcp.example.com. 解析作業委派給 Cloud DNS 傳入轉送虛擬 IP 位址,藉此設定傳入轉送。
  9. 確認防火牆允許地端部署和Google Cloud 防火牆的 DNS 流量。
  10. 在 Cloud Router 執行個體,為正式版 Shared VPC 網路的 IP 位址範圍 35.199.192.0/19,新增自訂 advertise 路由,指向地端部署環境。

使用連接中樞與輪輻 VPC 網路的混合架構

另一種做法是使用 Cloud Interconnect 或 Cloud VPN,將地端部署基礎架構連線至中樞 VPC 網路。如圖 8 所示,您可以使用 VPC 網路對接,將一個 VPC 網路與多個輪輻 VPC 網路對接。每個輪輻 VPC 網路都會在 Cloud DNS 上託管自己的私人區域。每當 VPC 網路對接的自訂路由,搭配 Cloud Router 上的自訂路由 advertisement,就可以在地端部署網路與所有輪輻 VPC 網路之間,達成完整路由交換及連線。為了在環境之間執行名稱解析,DNS 對接會與 VPC 網路對接連線平行運作。

下圖呈現了這個架構。

圖 8. 混合架構可透過 VPC 網路對接,使用連線至輪輻 VPC 網路的中樞 VPC 網路。
圖 8. 混合架構可使用連線至輪輻 VPC 網路的中樞 VPC 網路。

如要設定此架構,請按照下列步驟操作:

  1. 將地端部署 DNS 伺服器設為 corp.example.com 的權威伺服器。
  2. 在 Cloud DNS 設定每個輪輻 VPC 網路的私人區域 (例如 projectX.gcp.example.com),並為該區域的資源設定所有記錄。
  3. 在正式版 Shared VPC 網路的中樞專案,設定 DNS 伺服器政策,允許傳入 DNS 轉送。
  4. 在中樞 VPC 網路,建立 corp.example.com 的私人 DNS 區域,並設定傳出轉送至地端部署 DNS 伺服器。
  5. 從中樞 VPC 網路到各個輪輻 VPC 網路,設定 projectX.gcp.example.com 的 DNS 對接區域。
  6. 從各個輪輻 VPC 網路到中樞 VPC 網路,設定 example.com 的 DNS 對接區域。
  7. 在地端部署 DNS 伺服器上,為 gcp.example.com 設定轉送,指向中樞 VPC 網路的傳入轉送站 IP 位址。
  8. 確認防火牆允許地端部署和Google Cloud 防火牆的 DNS 流量。
  9. 在 Cloud Router 執行個體,為中樞 VPC 網路的 IP 位址範圍 35.199.192.0/19 新增自訂 advertise 路由,指向地端部署環境。
  10. (選用) 如果您也使用自動產生的內部 DNS 名稱,請將各輪輻專案區域 (例如 spoke-project-x.internal) 與中樞專案對接,並從地端部署環境轉送所有對 .internal 的查詢。

使用 Cloud DNS 建立多供應商公用 DNS

做為應用程式網路的基本要素,可靠的 DNS 是確保應用程式或服務可供使用者存取的關鍵。您可以設定多個 DNS 供應商,提高應用程式和服務的可用性和韌性。設定多個 DNS 供應商後,即使其中一個 DNS 供應商服務中斷,使用者仍可存取您的應用程式或服務。此外,當混合式應用程式在地端部署和雲端環境皆具有依附元件,即可透過多供應商 DNS 設定,簡化這類應用程式的部署和遷移作業。

Google Cloud 提供以 octoDNS 為基礎的開放原始碼解決方案,協助您設定及操作多 DNS 供應商的環境。多供應商 DNS 解決方案會將 Cloud DNS 用做其中一個 DNS 供應商,並採用 active-active (建議做法) 或 active-passive 設定,確保打造可用性高的 DNS 架構。部署解決方案後,octoDNS 會在目前的 DNS 區域和託管於 Cloud DNS 的代管 DNS 區域之間,執行單次及持續性的同步作業。個別 DNS 記錄更新時,變更會傳播至託管於 Cloud DNS 的相對應 DNS 區域,因此無須變更 CI/CD 管道。

後續步驟