Cloud DNS 入門：公開、私有網域與解析路徑

前言

網站網域要指向服務，或內部系統要用私有名稱互相找到，背後都需要 DNS。Cloud DNS 讓你管理這些解析紀錄；公開與私有 Zone 的差別，會直接影響誰查得到。這篇就從一次查詢會走到哪裡開始說。

如果還不熟 VPC，建議先看 GCP 網路基礎；後面談 Private Zone 和 Split-Horizon DNS 時會用到。

什麼是 Cloud DNS？

Cloud DNS 是 GCP 的全託管權威 DNS 服務，負責將域名（如 example.com）解析為 IP 位址：

flowchart LR
  subgraph CLIENT["1. 用戶端與遞迴解析"]
    direction TB
    USER["瀏覽器／應用查詢<br/>www.example.com"] --> RESOLVER["遞迴 Resolver<br/>ISP、企業或 Public DNS"]
    RESOLVER --> CACHE{"TTL 快取中已有<br/>有效答案？"}
    CACHE -->|"是"| CACHED["直接回傳快取結果"]
  end
  subgraph DELEGATION["2. 尋找權威名稱伺服器"]
    direction TB
    ROOT["Root 與 TLD 委派"] --> NS["取得 example.com 的<br/>Cloud DNS NS 記錄"]
  end
  subgraph AUTHORITATIVE["3. 權威回答"]
    direction TB
    ANYCAST["Google 全球 Anycast<br/>就近到達 Cloud DNS"] --> ZONE["查詢 Managed Zone<br/>中的 Resource Record Set"]
    ZONE --> ANSWER["回傳權威答案與 TTL<br/>例如 203.0.113.1"]
  end
  CACHE -->|"否"| ROOT
  NS --> ANYCAST
  ANSWER --> RESOLVER

核心特性

• 100% SLA 目標——適用於官方條款定義的權威 DNS 查詢服務，不等於整條網站連線都保證不中斷
• 全球 Anycast 網路——自動路由到最近的節點以降低查詢延遲。對你的意義是：不管使用者在台北還是巴黎，查你的域名都是就近回應，不用自己架一堆海外 DNS 伺服器
• 自動擴展——支援數百萬 DNS Zone 和記錄
• 完整 API——Console、gcloud CLI、REST API、Terraform 全支援

Zone 類型

Cloud DNS 有好幾種 Zone 類型，各自對應不同的使用情境：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

建立 Zone

# 建立 Public Zone
gcloud dns managed-zones create my-zone \
  --dns-name="example.com." \
  --description="Production zone" \
  --visibility=public

# 建立 Private Zone（綁定到 VPC）
gcloud dns managed-zones create my-private-zone \
  --dns-name="internal.example.com." \
  --description="Internal services" \
  --visibility=private \
  --networks=my-vpc-network

flowchart TB
  subgraph SCOPE["1. 判斷可見範圍"]
    direction TB
    START["要提供哪一段 DNS Namespace？"] --> INTERNET{"公開網際網路<br/>必須能查詢？"}
    INTERNET -->|"是"| PUBLIC["Public Zone<br/>公開權威記錄"]
  end
  subgraph PRIVATE_TYPE["2. 選擇私有 Zone 類型"]
    direction TB
    SOURCE{"答案由 Cloud DNS<br/>直接管理？"}
    SOURCE -->|"是"| PRIVATE["Private Zone<br/>綁定 VPC／GKE"]
    SOURCE -->|"否"| OTHER_VPC{"要沿用另一個 VPC<br/>的解析順序？"}
    OTHER_VPC -->|"是"| PEERING["Peering Zone<br/>指向 Producer VPC"]
    OTHER_VPC -->|"否"| REVERSE_Q{"用途是內部 IP<br/>到主機名稱反查？"}
    REVERSE_Q -->|"是"| REVERSE["Managed<br/>Reverse Lookup<br/>提供 PTR 反解"]
    REVERSE_Q -->|"否，送往指定 DNS"| FORWARD["Forwarding Zone<br/>轉送特定 DNS 尾碼"]
  end
  INTERNET -->|"否，只限內部"| SOURCE

DNS 記錄管理

支援的記錄類型

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

使用 Transaction 管理記錄

Cloud DNS 使用 Transaction 確保記錄變更的原子性：

# 新增 A 記錄
gcloud dns record-sets transaction start --zone=my-zone
gcloud dns record-sets transaction add "203.0.113.1" \
  --name="www.example.com." \
  --ttl=300 \
  --type=A \
  --zone=my-zone
gcloud dns record-sets transaction execute --zone=my-zone

# 新增 MX 記錄
gcloud dns record-sets transaction start --zone=my-zone
gcloud dns record-sets transaction add "10 mail.example.com." \
  --name="example.com." \
  --ttl=300 \
  --type=MX \
  --zone=my-zone
gcloud dns record-sets transaction execute --zone=my-zone

# 列出所有記錄
gcloud dns record-sets list --zone=my-zone

flowchart LR
  subgraph PREPARE["1. 準備變更"]
    direction TB
    START["transaction start"] --> STAGE["暫存一或多筆 add／remove<br/>尚未影響權威答案"]
    STAGE --> REVIEW["檢查名稱、類型、TTL<br/>與完整 RRset"]
  end
  subgraph COMMIT["2. 原子提交"]
    direction TB
    EXECUTE["transaction execute"] --> RESULT{"整批變更<br/>通過驗證？"}
    RESULT -->|"否"| REJECT["整批拒絕<br/>修正後重建 Transaction"]
  end
  subgraph OBSERVE["3. 等待快取更新"]
    direction TB
    PUBLISH["原子發布新版本<br/>不會看到半套記錄"] --> CACHE["Resolver 仍可能依舊 TTL<br/>暫時回傳快取答案"]
  end
  REVIEW --> EXECUTE
  RESULT -->|"是"| PUBLISH

DNSSEC

DNSSEC（DNS Security Extensions）防止 DNS 欺騙和快取中毒攻擊。Cloud DNS 提供全託管 DNSSEC：

# 建立時啟用 DNSSEC
gcloud dns managed-zones create secure-zone \
  --dns-name="secure.example.com." \
  --description="DNSSEC-enabled zone" \
  --dnssec-state=on

# 對既有 Zone 啟用 DNSSEC
gcloud dns managed-zones update my-zone --dnssec-state=on

# 取得 DS 記錄（需在域名註冊商設定）
gcloud dns dns-keys list \
  --filter='type=keySigning' \
  --format='value(ds_record())' \
  --zone=my-zone

DNSSEC 金鑰管理

• ZSK（Zone Signing Key）：自動建立和輪換
• KSK（Key Signing Key）：自動建立，但輪換需手動更新域名註冊商的 DS 記錄
• 支援 RSASHA256（預設）、ECDSAP256SHA256 等演算法
• 支援 NSEC 和 NSEC3 否定存在證明
• 啟用 DNSSEC 不額外收費

flowchart TB
  subgraph SIGN["1. Cloud DNS 簽署 Zone"]
    direction TB
    RRSET["A／AAAA 等<br/>Resource Record Set"] --> RRSIG["ZSK 產生 RRSIG"]
    DNSKEY["KSK 簽署 DNSKEY 集合"]
  end
  subgraph DELEGATE["2. 在父 Zone 建立信任"]
    direction TB
    DS["從 Cloud DNS 取得 DS"] --> REGISTRAR["到 Registrar／父 Zone<br/>發布 DS 記錄"]
  end
  subgraph VALIDATE["3. Resolver 驗證"]
    direction TB
    ROOT["Root／TLD 信任鏈"] --> CHECK["驗證 DS →<br/>DNSKEY → RRSIG"]
    CHECK --> RESULT{"簽章與資料一致？"}
    RESULT -->|"是"| ACCEPT["回傳已驗證答案"]
    RESULT -->|"否"| SERVFAIL["驗證失敗<br/>不接受遭竄改答案"]
  end
  DNSKEY --> DS
  REGISTRAR --> ROOT
  RRSIG --> CHECK

Split-Horizon DNS

Split-Horizon DNS（也叫分割視野 DNS）讓同一個域名在內部和外部回傳不同 IP——白話講就是「同一個門牌，公司內部的人走的是內網捷徑，外面的人走的是大馬路」：

flowchart TB
  subgraph SOURCE["1. 判斷查詢來源"]
    direction TB
    QUERY["查詢 api.example.com"] --> ORIGIN{"查詢來自哪裡？"}
  end
  subgraph PUBLIC_PATH["2A. 公開解析"]
    direction TB
    PUBLIC["沿公開 DNS 委派<br/>查詢 Public Zone"] --> EXTERNAL["回傳外部 Load Balancer<br/>203.0.113.1"]
  end
  subgraph PRIVATE_PATH["2B. VPC 私有解析"]
    direction TB
    PRIVATE["用最長尾碼匹配<br/>Private、Forwarding<br/>或 Peering Zone"] --> MATCH{"最相符的 Zone<br/>包含該記錄？"}
    MATCH -->|"是"| INTERNAL["回傳內部 Load Balancer<br/>10.128.0.5"]
    MATCH -->|"否，但 Zone 已匹配"| NXDOMAIN["回傳 NXDOMAIN<br/>不退回同名 Public Zone"]
  end
  ORIGIN -->|"公開網路"| PUBLIC
  ORIGIN -->|"授權 VPC 內的 VM／GKE"| PRIVATE
  PRIVATE -->|"沒有任何私有 Zone 匹配"| PUBLIC

設定方式

1. 建立 example.com 的 Public Zone，指向外部 IP
2. 建立 example.com 的 Private Zone，綁定 VPC，指向內部 IP
3. VPC 內的查詢自動走 Private Zone（Private Zone 優先於 Public Zone）

💡 重點提點

Split-Horizon 的重點是：同一個網域名稱，VPC 內外可以得到不同的回應。若 VM 查到的仍是公開 IP，先確認 Private Zone 是否綁定了該 VM 所在的 VPC，以及記錄名稱是否正確，再檢查其他解析路徑。不要只看 Public Zone 的記錄就判斷內部查詢結果。

# Public Zone（對外）
gcloud dns managed-zones create example-public \
  --dns-name="example.com." \
  --visibility=public

# Private Zone（對內）
gcloud dns managed-zones create example-private \
  --dns-name="example.com." \
  --visibility=private \
  --networks=my-vpc

DNS 路由策略

Cloud DNS 可以直接在 DNS 層級做流量導引：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

加權輪詢範例

# 90% 流量到 v1（203.0.113.1），10% 到 v2（203.0.113.2）（金絲雀部署）
gcloud dns record-sets create www.example.com. \
  --zone=my-zone \
  --type=A \
  --ttl=300 \
  --routing-policy-type=WRR \
  --routing-policy-data="0.9=203.0.113.1;0.1=203.0.113.2"

flowchart LR
  subgraph GOAL["1. 判斷分流目標"]
    direction TB
    START["同一 DNS<br/>名稱有多個端點"] --> PERCENT{"要依比例做<br/>Canary、A/B<br/>或漸進切換？"}
    PERCENT -->|"否"| LOCATION{"要依查詢來源地區<br/>回傳就近端點？"}
    LOCATION -->|"否"| RECOVERY{"要在主要<br/>端點失效時<br/>自動改用備援？"}
  end
  subgraph POLICY["2. 選擇 Routing Policy"]
    WRR["Weighted<br/>Round Robin<br/>為每組端點<br/>設定權重"]
    GEO["Geolocation<br/>依來源<br/>地理位置回應"]
    FAILOVER["Failover<br/>搭配 Health<br/>Check"]
    RECHECK["若需逐連線<br/>精準分流<br/>改由 Load<br/>Balancer 處理"]
  end
  PERCENT -->|"是"| WRR
  LOCATION -->|"是"| GEO
  RECOVERY -->|"是"| FAILOVER
  RECOVERY -->|"否"| RECHECK
  WRR --> VERIFY["設定 TTL，<br/>並用多個<br/>Resolver<br/>與地區驗證"]
  GEO --> VERIFY
  FAILOVER --> VERIFY

Response Policy

Response Policy 可以在 DNS 層級覆寫解析結果：

# 建立 Response Policy
gcloud dns response-policies create security-policy \
  --networks=my-vpc \
  --description="Block malicious domains"

# 封鎖惡意域名（回傳 0.0.0.0）
gcloud dns response-policies rules create block-malware \
  --response-policy=security-policy \
  --dns-name="malicious-site.com." \
  --local-data='name=malicious-site.com.,type=A,ttl=300,rrdatas=0.0.0.0'

# 豁免特定域名（passthru）
gcloud dns response-policies rules create allow-safe \
  --response-policy=security-policy \
  --dns-name="safe-site.com." \
  --behavior=bypassResponsePolicy

常見用途

• 安全封鎖：阻擋已知惡意域名
• VPC Service Controls：重導 *.googleapis.com 到受限 VIP
• 內部服務覆寫：自訂特定服務的 DNS 解析

💡 重點提點

每個 VPC 只能綁定一個 Response Policy——這個限制很容易在實作時踩雷。新手常見的卡關情境是：已經有一條 Response Policy 在跑，又想加第二條規則集，結果建立時報錯。解法不是再建一個 Response Policy，而是把新規則加進現有的那一條裡（一個 Response Policy 底下可以放很多條 rule）。備考時留意這個一對一關係：看到「想在同一個 VPC 套用兩個 Response Policy」這種選項，直接刷掉。

DNS Server Policy

Server Policy 控制 VPC 內的 DNS 行為：

# 啟用 Inbound Forwarding + 查詢日誌
gcloud dns policies create my-policy \
  --description="Inbound forwarding and query logging" \
  --networks=my-vpc \
  --enable-inbound-forwarding \
  --enable-logging

# 設定 Alternative Name Servers（轉發到地端 DNS；一個 VPC 只能綁一個 Server Policy，這裡換另一個 VPC 示範）
gcloud dns policies create outbound-policy \
  --description="Forward queries to on-prem DNS" \
  --networks=my-other-vpc \
  --alternative-name-servers="10.0.0.53,10.0.0.54"

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

%%{init: {"flowchart": {"rankSpacing": 34}}}%%
  flowchart TB
  START["VPC／地端 DNS 整合需求"] --> PURPOSE{"主要要改哪一段<br/>名稱解析行為？"}
  PURPOSE -->|"依名稱覆寫、封鎖或放行"| RESPONSE["Response Policy<br/>命中規則時覆寫私有解析"]
  PURPOSE -->|"地端與 Google Cloud 互查"| DIRECTION{"查詢方向"}
  PURPOSE -->|"跨 VPC 共用 Namespace"| PEERING["Peering Zone<br/>使用 Producer VPC 的解析順序"]
  PURPOSE -->|"一般 Cloud DNS 解析"| DEFAULT["維持 Private／Public<br/>名稱解析順序"]
  DIRECTION -->|"地端查 Cloud 私有名稱"| INBOUND["Inbound Server Policy<br/>提供地端查詢入口 IP"]
  DIRECTION -->|"VPC 查地端／自管 DNS"| SCOPE{"轉送範圍"}
  SCOPE -->|"只有特定 DNS 尾碼"| FORWARDZONE["Forwarding Zone<br/>轉送特定 Namespace"]
  SCOPE -->|"整個 VPC 使用替代 DNS"| OUTBOUND["Outbound Server Policy<br/>設定 Alternative Name Servers"]

與其他 GCP 服務整合

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

定價

Zone 費用

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

查詢費用

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

使用 WRR、Geolocation 或 Failover 路由策略的查詢，費用較標準查詢高。

成本估算

10 個 Zone + 1 億次查詢 / 月：

• Zone：10 × $0.20 = $2.00
• 查詢：100 × $0.40 = $40.00
• 合計：~$42 / 月

Cloud DNS 沒有免費層，但 GCP 新帳號有 $300 免費試用額度可折抵。

配額與限制

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

ACE 考試重點整理

必背知識點

1. Cloud DNS 是全託管權威 DNS 服務，跑在 Google Anycast 網路上
2. Cloud DNS 的 SLA 目標為 100%——範圍以官方條款定義的權威 DNS 查詢服務為準
3. Private Zone 優先於 Public Zone（VPC 內查詢）
4. Split-Horizon DNS：同一域名內外回傳不同 IP
5. DNSSEC：全自動管理 KSK/ZSK 輪換
6. Response Policy：DNS 層級封鎖惡意域名
7. DNS 路由策略：WRR（加權）、Geolocation（地理）、Failover（故障轉移）

常見陷阱題

Q：需要讓同一域名在公司內部和外部解析到不同 IP，怎麼做？ A：Split-Horizon DNS。建立同名的 Public Zone 和 Private Zone，VPC 內查詢自動走 Private Zone。

Q：Cloud DNS 的 SLA 是多少？ A：官方 SLA 目標是 100%，涵蓋條款定義的權威 DNS 查詢服務。回答時也要說清楚適用範圍與排除條件，不能把它當成整個網站的可用性保證。

Q：如何在 DNS 層級阻擋員工存取惡意網站？ A：使用 Response Policy，建立規則將惡意域名導向 0.0.0.0。

Q：地端伺服器需要查詢 Cloud DNS 的 Private Zone，怎麼設定？ A：建立 DNS Server Policy 並啟用 Inbound Forwarding，建立進入點 IP 供地端 DNS 轉發查詢。

Q：Cloud DNS 和 Cloud Domains 有什麼不同？ A：Cloud DNS 是 DNS 代管服務（管理 DNS 記錄）。Cloud Domains 是域名註冊服務（購買和管理域名）。兩者是獨立的服務，通常搭配使用。

總結

Cloud DNS 負責託管權威 DNS 記錄。規劃時可以從下面幾點檢查：

• 定位：全託管權威 DNS，透過全球 Anycast 網路提供查詢服務
• Zone 類型：Public（對外）、Private（對內）、Forwarding（混合雲）、Peering（跨 VPC）
• 安全：DNSSEC 自動管理、Response Policy 封鎖惡意域名
• 路由：WRR、Geolocation、Failover 三種策略
• Split-Horizon：同一域名內外不同解析
• 定價：$0.20 / Zone / 月 + $0.40 / 百萬查詢

設定 Private Zone 後，最好從實際會發出查詢的 VM 或服務測一次解析結果。如果得到公開 IP，先檢查 Zone 綁定的 VPC、記錄名稱與查詢路徑；這比只看 Console 裡的記錄更能確認設定是否生效。

下一課 ACE-215：GCP 基礎架構即代碼（IaC）策略，學習 Terraform、Infrastructure Manager 和 Config Connector 的實戰應用。