Google PCNE: Cloud DNS、服務探索與混合式名稱解析 — 學習指南

By Laurynas Brazys · 23 August 2026 · #google #PCNE #certification #exam-prep #study-guide

屬於 Google Professional Cloud Network Engineer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

Cloud DNS 是 Google Cloud 的可擴充、高可用性 DNS 服務，同時支援 VPC 的公開權威區域 (public authoritative zones) 和私有 DNS (private DNS)。它也提供混合式名稱解析基元 (primitives)——轉送 (forwarding)、對等互連 (peering)、傳入伺服器 (inbound servers)、回應政策 (response policies) 和 DNS 政策 (policies)——以與地端 (on-premises) DNS 和多雲環境整合。本節涵蓋權威 DNS 生命週期、私有區域的可見性與共享、混合式解析、服務探索模式、安全性與完整性 (包含 DNSSEC 和區域轉移)、使用路由政策的進階流量管理、用於私有服務端點的 DNS，以及第二天維運 (day-2 operations)，例如故障排除、快取、日誌記錄以及遷移/共存策略。

權威 DNS 與 DNS 生命週期

託管區域 (Managed zones) 與紀錄
- 託管區域是一個容器，用於存放單一 DNS 名稱 (區域頂點，zone apex) 的資源紀錄集 (RRsets)。
- 紀錄類型：A、AAAA、CNAME、MX、TXT、SRV、PTR、NS、SOA (以及更多)。Cloud DNS 不支援在區域頂點使用 CNAME；請使用 A/AAAA 紀錄搭配負載平衡器的 IP 來進行頂點對應。
- 生命週期：建立區域、新增/修改紀錄 (交易式變更)、傳播，以及維運 (監控/日誌/保護)。
- 從現有的 BIND 檔案匯入以加速遷移：
  - 範例：gcloud dns record-sets import ZONE_FILE –zone-file-format –zone MANAGED_ZONE
公開區域 vs. 私有區域
- 公開區域可透過 Google 的公開權威名稱伺服器進行全域存取。透過在父層更新 NS 紀錄，在註冊商 (registrar) 處進行委派。
- 私有區域僅對其附加的 VPC 網路提供應答。它們由 Google 的 VPC 範圍解析器 (VPC-scoped resolvers) 為這些 VPC 中的執行個體進行解析，並可選擇性地透過傳入轉送 (inbound forwarding) 為混合式用戶端解析。
傳播與 TTL
- 在 Google Cloud 內部，紀錄變更會在數秒內生效；外部快取的失效則取決於 TTL。
- TTL 的權衡：短 TTL 能提高敏捷性並使切換更安全，但會增加查詢負載並可能降低快取效率；長 TTL 則能減少負載，但會延長過時應答的時間。常見做法：動態服務使用 60–300 秒；穩定紀錄使用 600–3600 秒。在進行切換前，應提前 24–48 小時降低 TTL。

私有區域的可見性、VPC 關聯與跨專案設計

將私有區域附加到 VPC
- 一個私有區域會明確地與一個或多個 VPC 網路關聯。此關聯可以跨專案 (需具備適當的 IAM 權限，例如在區域上擁有 dns.admin 權限，以及綁定網路的權限)。
- 優先順序：附加到同一個 VPC 的私有區域中，最長後綴匹配者勝出；當私有區域重疊時 (例如 svc.corp.internal. 和 corp.internal.) 需特別小心。
- 跨 VPC 共享模式
  - 直接附加：將同一個私有區域附加到多個 VPC。操作上簡單；但應避免附加到不需要的網路，以減少爆炸半徑 (blast radius)。
  - 共享 VPC (Shared VPC)：將 DNS 管理集中在宿主專案 (host project) 中，並透過將子網路的 VPC 附加到區域，來將 DNS 開放給服務專案 (service projects) 使用。
  - DNS 對等互連區域 (peering zones)：當網路之間使用 VPC Peering 時，消費者 VPC 中的對等互連區域可以解析來自生產者 VPC 的私有紀錄，而無需複製區域。
故障模式與防護措施
- 遮蔽 (Shadowing)：與公開區域同名的私有區域，會導致附加 VPC 中的用戶端優先採用私有應答，這可能中斷對公開端點的存取。應有意識地使用分割水平 (split-horizon) DNS，並加以文件化和測試。
- 過度附加：將私有區域廣泛附加可能導致內部名稱洩漏。應遵循最小權限原則，並使用獨立的子網域 (依區域/服務劃分範圍) 來限制範圍。
- IAM 職責分離：將 DNS 變更權限 (dns.admin) 與網路附加權限 (綁定網路的權限) 分開委派，以實現獨立的管理領域。

簡短範例：建立並附加一個私有區域

gcloud dns managed-zones create corp-internal \
  --dns-name=corp.internal. \
  --visibility=private \
  --description="Private corp zone" \
  --networks=prod-vpc,stg-vpc

混合式名稱解析：轉送、對等互連與政策

轉送區域
- 將特定後綴（例如 onprem.corp.）的查詢權威性地轉送到指定的名稱伺服器（位於地端或其他雲端）。當您未在 Cloud DNS 中託管該區域，但需要從 GCP 進行無縫解析時，請使用此功能。
- 避免迴圈：確保地端轉送器不會將相同後綴的查詢指回 Cloud DNS。
對等互連區域
- 解析託管於對等互連 VPC 中的私有區域。需要 VPC peering 連線；不具備可轉移性。可用於軸輻式架構設計，將私有 DNS 集中在一個中心 VPC 中。
DNS 政策
- 輸出轉送：VPC 中的執行個體會將無法在 Cloud DNS 私有區域中解析的網域之遞迴查詢，傳送到地端解析器。透過設定 DNS 政策，並指定可經由 Cloud VPN/Interconnect 連線的目標名稱伺服器 IP 來進行配置。
- 輸入伺服器：地端解析器將查詢轉送到 Google 提供的輸入轉送 IP（自動分配的 35.199.192.0/20），以解析 Cloud DNS 私有區域。可用於將 GCP 私有 DNS 的功能延伸至地端和其他雲端。
- 查詢記錄：在政策層級啟用，可將解析器查詢日誌傳送到 Cloud Logging 進行分析和疑難排解。對於公有區域，請啟用個別區域的查詢記錄功能，以記錄權威性查詢。
回應政策
- 定義規則以修改回應（例如，對已知的惡意網域回傳 NXDOMAIN，或合成內部 A 記錄以覆寫公開的答案）。請謹慎套用；並驗證關鍵的第三方網域不會被意外封鎖。
連線先決條件
- 為確保輸出/輸入功能正常運作，請確保混合式連線（Cloud VPN 或 Interconnect）已建立，且防火牆規則已視需求雙向允許 UDP/TCP 53。EDNS0 和 UDP 分片行為在不同網路中可能有所差異——若發生 MTU 問題，請允許 TCP 備援，並考慮在地端解析器上調整 EDNS(0) 緩衝區。
常見陷阱
- 非對稱連線：如果輸出轉送指向地端解析器，但回傳流量被防火牆或路由不對稱所阻擋，查詢將會逾時。請驗證 Cloud Router 已學習到路由，並允許 DNS 回應流量通過。
- 重疊的後綴：企業內部重疊的後綴（例如 corp.local vs corp.internal）可能導致解析器搜尋路徑發生非預期的匹配。請標準化搜尋路徑和後綴的所有權。

簡短範例：

# Outbound forwarding policy to on-prem resolvers
gcloud dns policies create corp-outbound \
  --networks=prod-vpc \
  --forwarding-targets=10.1.0.10,10.1.0.11 \
  --enable-logging

# Forwarding zone for partner domain
gcloud dns managed-zones create partner-fwd \
  --dns-name=partner.example. \
  --visibility=private \
  --forwarding-targets=172.16.10.53,172.16.11.53 \
  --networks=prod-vpc

服務探索、分割水平與私有端點

分割水平 DNS
- 對同一個名稱，在內部和外部提供不同的答案。典型模式：公開的 foo.example.com 解析為一個公開的 Anycast IP；內部的 foo.example.com 則解析為一個 ILB 的 RFC1918 位址。透過建立一個公有區域和一個同名的私有區域來實現，並謹慎地將私有區域的範圍限定在適當的 VPC。
內部服務命名
- 使用一致的內部後綴（例如 svc.corp.internal）和以服務為導向的記錄（A/AAAA、SRV 或用於探索的特定 TXT）。對於動態擴展的服務，請保持較低的 TTL。
- GKE 服務探索：叢集內部名稱（svc.cluster.local）保留在 CoreDNS 內。若要跨 namespace/VPC 公開，可將 ILB VIP 發布到 Cloud DNS 私有區域，或使用 Service Directory 整合。
Service Directory 整合
- 透過 Service Directory 和 Cloud DNS 自動將服務端點發布到 DNS，為每個 namespace/service 產生 SRV 和 A 記錄。這對於解耦生產者和消費者，以及支援具備健康狀態感知的服務實例探索很有用。
私有服務端點
- 使用 Private Service Connect (PSC) 連線至 Google API：使用 PSC 端點將 googleapis.com 的流量導向私有網路，或使用受限制的 Google API VIP (199.36.153.8/30) 搭配 googleapis.com 的私有區域。PSC 提供區域性的本地私有 IP 連線，並具備每個端點的控制能力；受限制的 VIP 較為簡單，但仍使用可透過預設路由連線的公有 IP 範圍。
- 使用 PSC 連線至生產者服務：在私有區域中建立指向 PSC 端點或 ILB VIP 的 A/AAAA 記錄。對於自訂的內部網域，請在 Cloud DNS 中管理私有區域，並將其附加到消費者 VPC。
權衡取捨
- PSC vs 受限制的 VIP：PSC 提供更精細的控制，並可避免經過出口檢查路徑；但它需要在每個區域設定端點/DNS。受限制的 VIP 部署快速，但使用共享的 VIP，且可能與出口路由政策產生交互作用。
- 分割水平風險：範圍設定不當的私有區域可能導致對公有 SaaS 的存取中斷。在廣泛推行前，請透過金絲雀 VM 和查詢記錄進行驗證。

簡短範例：內部 ILB 對應

; Private zone: corp.internal.
web.svc.corp.internal.  60  IN  A 10.20.0.15

安全性、流量管理、維運與遷移

DNSSEC 與完整性
- 公開區域：在 Cloud DNS 中啟用 DNSSEC 簽署，並在註冊商發布 DS 紀錄，以防止詐騙與快取污染。規劃金鑰輪替的窗口，並監控驗證失敗的情況。
- 私有區域：DNSSEC 的驗證/簽署通常非必要，因為解析是在受信任的網路上進行；應著重於傳輸安全 (混合式連結) 與解析器強化。
託管區域轉移
- Cloud DNS 可作為 AXFR/IXFR 的主要 (primary) 或次要 (secondary) 伺服器。使用 TSIG 來驗證/授權轉移，並使用 NOTIFY 確保即時傳播。區域轉移模式簡化了遷移期間的共存方式，並支援因法規或彈性需求而設的地端次要伺服器。
- 失敗模式：轉移被防火牆阻擋、TSIG 金鑰不符、SOA 序號未增加，或主要伺服器上停用 IXFR 導致進行完整的 AXFR。
路由政策與健康狀態檢查
- Cloud DNS 支援流量導向政策 (加權、地理位置、延遲與容錯移轉)。將健康狀態檢查附加到端點，以自動撤銷不健康的應答。
- 設計訣竅：每個政策目標的紀錄集應保持小規模；偏好採用與使用者分佈一致的區域性範圍；結合低 TTL 與故障偵測間隔，以限制容錯移轉時間。
- 陷阱：過於精細的地理位置對應會導致維運複雜性；缺乏一致的健康訊號會導致抖動 (flapping)——應使用穩定閾值與符合應用程式行為的健康狀態檢查逾時設定。
疑難排解
- 工具：使用 dig/nslookup 搭配 +trace、+short 和 +dnssec 來驗證鏈；檢閱 Cloud Logging 中的解析器查詢日誌 (DNS 政策) 和權威查詢日誌 (託管區域)。
- 快取：確認您正在測試哪個解析器 (VM 的 /etc/resolv.conf 通常指向 Google 的 VPC 解析器)。測試 TTL 變更時，請清除本機解析器快取。考慮負面快取 (RFC 2308)：NXDOMAIN 回應會根據 SOA MINIMUM/負面 TTL 進行快取。
- 常見問題：輸出轉送與地端條件式轉送器之間的迴圈；UDP 53 被阻擋或 MTU 問題導致回應被截斷；公開區域被私有區域遮蔽。
維運模式
- 變更控制：使用事務 (transaction) 批次處理變更，在切換前降低 TTL，並使用金絲雀 VPC 附加來驗證可視性。
- 日誌與監控：選擇性地啟用查詢日誌；將日誌匯出至 BigQuery 進行趨勢分析，並針對 SERVFAIL/NXDOMAIN 突增建立警示。
- 存取控制：將紀錄變更角色與網路附加角色分開；對回應政策編輯者強制執行最低權限，以避免無意中封鎖網域。
遷移與共存
- 共存：在地端 DNS 仍為主要伺服器的情況下，透過 AXFR/IXFR 將 Cloud DNS 設定為次要伺服器；或反向操作 (Cloud DNS 為主要，地端為次要)。使用 TSIG 和允許清單。
- 條件式轉送：對於仍保留在地端的網域，建立轉送區域或輸出轉送政策。確保混合式連結具備高可用性 (使用不同對等體和 Cloud Router 的雙 VPN)。
- 多組織橋接：透過 Cloud VPN/Cloud Router 連接 VPC，視情況建立相互的條件式轉送或對等互連，並對要遷移的區域使用區域轉移。在註冊商的 NS 或 DS 變更前，應提早降低 TTL。

簡短範例：

# Enable authoritative query logging for a public zone
gcloud dns managed-zones update prod-public --enable-logging

# Create inbound servers policy (IP allocation is automatic)
gcloud dns policies create corp-inbound --networks=prod-vpc

實務問題情境

Contoso Retail 和 Fabrikam Payments 是兩個獨立的 Google Cloud 組織，在整合網路和 DNS 的一年期間必須互相操作，並將停機時間降至最低。每個組織都使用不重疊的 10.0.0.0/8 位址空間。Contoso 將在 svc.contoso.internal 下託管內部服務；Fabrikam 將繼續在地端託管 pay.fabrikam.internal。雙方都需要解析彼此的私有名稱，並逐步將一些區域遷移到 Cloud DNS。

方法：

建立具備彈性的混合式連線
- 在 Contoso 的中心 VPC 和 Fabrikam 的地端路由器之間建立兩個 Cloud VPN 通道，每個通道連接到一個不同的 Fabrikam 公用 IP，並在兩個通道上都使用 Cloud Router BGP。
- 理由：雙通道加上動態路由提供了路徑備援，並自動傳播 DNS 目標的路由，從而降低了 UDP/TCP 53 的非對稱路由風險。
在雙向實作條件式名稱解析
- 在 Contoso 端，建立一個轉送區域 fabrikam.internal，將查詢轉送到 Fabrikam 的地端 DNS 伺服器 (例如 172.20.10.53 和 172.20.11.53)，並將其附加到應用程式 VPC。
- 在 Fabrikam 端，設定地端 DNS 上的條件式轉送器，將 svc.contoso.internal 的查詢轉送到由 Cloud DNS 輸入政策提供的 Cloud DNS 輸入轉送 IP。
- 理由：轉送區域避免了重複的權威，並允許雙方將其 DNS 維持在現有位置。輸入伺服器將 Cloud DNS 的私有解析能力擴展到 Fabrikam，而無需大規模更改其解析器。
防範轉送迴圈並強制執行可視性邊界
- 確保 Fabrikam 的條件式轉送器不會將 Fabrikam 仍擁有的名稱的 contoso.internal 查詢轉送回 Contoso；同樣地，Contoso 只應轉送 fabrikam.internal。
- 僅將 Contoso 的私有區域附加到需要它們的 VPC；不要全域附加，以減少爆炸半徑。
- 理由：消除 DNS 遞迴迴圈，並防止私有區域遮蔽公開網域。
使用託管區域轉移來遷移共享區域
- 對於目前託管在 Fabrikam 的 BIND 主要伺服器上的舊有共享區域 legacy.shared.internal，將 Cloud DNS 設定為次要伺服器，使用 TSIG 並將 Fabrikam 的主要伺服器加入 AXFR/IXFR 的允許清單。在共存期間，保持 Fabrikam 為主要伺服器。
- 理由：次要模式提供了即時同步，而無需更改用戶端。它能在 Contoso 中進行安全驗證，同時維持單一的事實來源。
為對外公開的服務導入分割視野 (split-horizon)
- 建立一個公開區域 contoso.example，其紀錄指向供客戶使用的全域 HTTPS 負載平衡器 IP。建立一個同名的私有區域，附加到內部 VPC，將相同的名稱對應到內部 ILB 位址。
- 理由：外部使用者繼續存取邊緣負載平衡器；內部服務透過 RFC1918 位址存取私有 ILB，從而優化延遲和成本，同時保持主機名稱的一致性。
提供對 Google API 的私有存取，無需通過防火牆輸出
- 對於沒有外部 IP 的 Contoso VM，啟用 Private Service Connect for Google APIs，並為 googleapis.com 建立託管的私有 DNS 區域，將其對應到 PSC 端點。
- 理由：確保對 BigQuery 和 Pub/Sub 的存取保持私有且位於 VPC 本地，避免使用第三方輸出設備，並維持安全態勢。
啟用可觀測性與控制
- 在 Contoso 的 DNS 政策上為相關 VPC 開啟 Cloud DNS 查詢日誌，並在公開區域上開啟權威查詢日誌。建立回應政策規則，以在整個組織範圍內封鎖已知的惡意網域。
- 理由：查詢遙測資料支援疑難排解和容量規劃；回應政策提供了集中的安全控制，而無需接觸每個解析器。
使用安全的 TTL 執行變更管理
- 在變更前一週，將要遷移的紀錄的 TTL 降至 60 秒。在驗證和切換 (例如，將服務從地端切換到 GCP ILB) 後，逐漸將 TTL 提高到 300-600 秒。
- 理由：短 TTL 在轉換期間限制了風險；在穩定後恢復較高的 TTL 可提高快取效率。
測試、驗證與強化
- 從雙方的金絲雀 VM 上，執行帶有 +trace 的 dig 命令，驗證權威路徑，確認日誌中沒有 SERVFAIL/NXDOMAIN 突增，並模擬連結故障以觀察 VPN 備援下的 DNS 行為。
- 理由：主動驗證能及早發現迴圈/可視性問題；故障模擬可驗證混合式解析在傳輸事件中能否存活下來，而不會影響使用者。