Cloud DNS 簡介
Cloud DNS 是 Google Cloud 的受管權威網域名稱系統（DNS）服務。它把你的區域託管在 Google 的 anycast 名稱伺服器上，於數秒內傳播變更，並為公開 DNS 查詢提供 100% 可用性服務水準目標。PCNE 考試把 Cloud DNS 視為串接 VPC、混合鏈路、負載平衡器以及身分感知 Proxy 的結締組織，所以每位 Professional Cloud Network Engineer 都需要熟悉的不只是要建立哪些記錄，更要懂得在每個情境裡該選哪一種區域類型、路由原則與解析流程。
這份學習筆記涵蓋 Cloud DNS 支援的所有區域類型、每個區域可以存放哪些記錄、DNSSEC 與回應原則如何加固解析路徑，以及路由原則如何把 DNS 回答轉成流量工程的基本元件。文中穿插具體的 gcloud dns 指令與解析順序規則，因為考試常常問「這個查詢會先被哪一台 DNS 伺服器接到」，而不是抽象的小知識。
白話文解釋（Plain English Explanation）
在把每個 Cloud DNS 功能對映到 gcloud 旗標前，三個具體的畫面能讓零件一次到位。
把 Cloud DNS 想像成大型辦公大樓的接待櫃台
一位訪客走進 60 層辦公大樓的大廳，問櫃台「Acme Legal」在哪一層。櫃台翻一翻租戶目錄，回答「23 樓 B 室」。如果訪客接著問位在私人主管樓層裡的某間公司，櫃台會打電話給主管樓層接待，後者手上有另一份未公開的目錄。Cloud DNS 同時扮演兩個角色。公開代管區域是面向街道的櫃台，網際網路上任何人都能問。私有代管區域是主管樓層接待，只能從建築物內部（你的 VPC）抵達。轉送區域是櫃台拿起電話打給外部目錄（你的地端 DNS），因為客人問的租戶櫃台不認得。對等互連區域則是櫃台把問題轉給對街姊妹大樓的櫃台，因為兩棟大樓共用同一份租戶名冊。
把 DNSSEC 想像成蓋在皇家詔書上的蠟封
中世紀國王把詔書送到全國各地，收件人用國王戒指壓出的蠟封來驗證真偽。冒名者可以寫假詔書，但沒有戒指就無法偽造蠟封。DNSSEC 用同樣的概念。區域擁有者用私密金鑰簽署每組記錄集，解析器用公開金鑰驗證簽章。攻擊者把假回答塞進快取，由於沒辦法偽造簽章，解析器會拒絕這個回應。沒有 DNSSEC 的情況下，針對 your-bank.example 的偽造回答會一路混過解析鏈，把使用者導去攻擊者的 IP。在 Cloud DNS 上，公開區域只要切換一個布林值就能打開這層保護。
把 DNS 路由原則想像成依照來電者身分接電話的總機
一間跨國律師事務所有一支電話號碼，會依照來電者所在位置把電話轉到不同辦公室。東京打進來的接到東京辦公室，法蘭克福打進來的接到法蘭克福。若東京放假，電話自動轉接到新加坡。事務所想做新接案團隊的 A/B 測試時，10% 的電話會被轉給新進的初級團隊。Cloud DNS 路由原則就在 DNS 這一層做完全相同的事。api.example.com 不再固定回一個 IP，地理原則回一個區域性 IP、容錯移轉原則在主機不健康時回備援 IP、加權輪詢原則依百分比拆流量。客戶端看不到背後的邏輯，只是解析名稱卻拿到隨情境而變的答案。
Cloud DNS 核心概念
幾個術語會反覆出現在 Cloud DNS 主控台、PCNE 考試與 gcloud dns 指令面板裡，定義要記得精確。
代管區域（Managed Zone）
代管區域是頂層容器，裝著像 example.com. 這樣一個 DNS 名稱空間。每個區域具備可見度（public 或 private）、DNS 名稱（API 中結尾的句點是必要的）以及一份 Google 在建立時指派的權威名稱伺服器清單。一個專案可以有許多區域，名稱重疊也可以，前提是可見度不同（一個公開、一個私有用同樣的 DNS 名稱）——這正是水平分割 DNS 的基礎。
記錄集（Record Set）
記錄集是同名、同類型、同 TTL 的一組記錄。Cloud DNS 支援的標準類型包括 A（IPv4 位址）、AAAA（IPv6 位址）、CNAME（正式名稱別名）、MX（郵件交換）、TXT（自由文字，通常裝 SPF / DKIM / 網站驗證）、SRV（給 SIP / Kerberos / Autodiscover 用的服務探索）、CAA（憑證頒發機構授權）、NS（名稱伺服器委派）、PTR（反向指標）、SOA（授權起始）與 SPF。記錄集可以是單純的值清單，也可以是依地理或健康狀態回傳不同值的路由原則。
VPC 內部的解析順序
當 VPC 裡的 VM 發出 DNS 查詢時，metadata 伺服器 169.254.169.254（或 metadata.google.internal）會依嚴格順序處理：先是 Google 內部 DNS 處理 *.internal 與 *.google.internal、然後是任何授權給該 VPC 的 Cloud DNS 私有區域、接著是 DNS 伺服器原則轉送器或回應原則規則，最後在都沒命中時才落到 Google 公開解析器。把這個順序搞錯是 PCNE 上最常見的單一陷阱。
一台 DNS 伺服器若擁有區域的原始記錄資料、回答時把 AA（Authoritative Answer）旗標設起來，便是該區域的權威伺服器。Cloud DNS 只做權威——它不會去開放網際網路上做遞迴。像 8.8.8.8 這類解析器則是遞迴解析器，會代客戶端走完整條委派鏈。
參考：https://cloud.google.com/dns/docs/overview
DNS 伺服器原則（Server Policy）
伺服器原則附加在 VPC 網路上（不是附在區域上），用來改變 metadata 解析器的行為。入站（Inbound）伺服器原則在 VPC 的每個地區保留一個內部 IP，讓地端解析器可以打進來查 Cloud DNS 私有區域。出站（Outbound）伺服器原則則把所有沒命中私有區域的查詢全部轉送給指定的替代名稱伺服器，繞過 Google Public DNS。
路由原則（Routing Policy）
路由原則把單一記錄集變成聰明的記錄。Cloud DNS 支援四種路由原則類型：加權輪詢（依百分比拆流量）、地理位置（依來源區域回不同 IP）、容錯移轉（主機健康時回主要 IP、失敗時回備援 IP），以及最新的具備多答覆的地理圍欄路由。容錯移轉需要 health check，地理位置則使用 EDNS Client Subnet 擴充來判斷來源。
公開代管區域
公開代管區域讓你的網域可以從網際網路任何地方解析。建立區域後，把 Google 指派的四個名稱伺服器（ns-cloud-{a,b,c,d}1.googledomains.com.）複製到你的註冊商，Cloud DNS 就會在數秒內開始權威回答。
建立公開區域
gcloud dns managed-zones create example-public \
--dns-name=example.com. \
--description="正式環境公開區域" \
--visibility=public \
--dnssec-state=on
--dnssec-state=on 旗標會在建立區域時就立即啟用 DNSSEC 簽章，這是建議的做法，因為事後補上 DNSSEC 還要小心翼翼地在註冊商那邊做 DS 記錄輪替。
Anycast 名稱伺服器
每個公開區域都由 Google 全球的 anycast 名稱伺服器機隊服務——那四個 ns-cloud-* 名稱從任何地方解析都會得到一樣的 IP，但 BGP 會把查詢導向最近的 Google 接入點。結果是大多數客戶端解析延遲低於 50 毫秒，也有對抗區域性中斷的韌性：若某個 PoP 掛掉，anycast 廣播會撤掉、最近的下一個 PoP 自然接手查詢，DNS 完全不用改。
公開區域上你會設定的記錄類型
一個正式環境公開區域幾乎一定包含：
- 在根（
example.com.）放A與 / 或AAAA記錄，指向負載平衡器 IP。 www.example.com.一個CNAME指回根（若你的服務商不允許在根做 CNAME，就改放另一筆A）。MX記錄指向 Google Workspace 或其他郵件服務商，加上裝載 SPF（v=spf1 include:_spf.google.com ~all）、DKIM、DMARC 原則的TXT記錄。CAA記錄（0 issue "letsencrypt.org"）限制哪些 CA 可以為這個網域簽發憑證。PCNE 考試很愛 CAA，因為它是防止憑證誤簽的便宜保險。- 視需要加上 SIP、XMPP、Kerberos 或 Microsoft Exchange Autodiscover 的
SRV記錄。
根記錄（example.com.）不能是 CNAME，因為 RFC 1034 禁止在區域根放 CNAME。Cloud DNS 在根支援類似 CNAME 的行為，只能透過 Application Load Balancer 整合，或者直接把負載平衡器 IP 寫成 A 記錄。PCNE 會丟一個看起來誘人的「在根用 CNAME 指向 LB 主機名稱」選項——那是錯的。
參考：https://cloud.google.com/dns/docs/records-overview
私有代管區域
私有代管區域只有你授權的 VPC 網路能存取。私有區域沒有根上的 CNAME 限制、不會出現在任何公開委派裡，只在 Google Cloud 內部解析——外部 dig 過來會收到 NXDOMAIN。
授權 VPC
gcloud dns managed-zones create internal-services \
--dns-name=svc.internal. \
--description="正式環境服務探索" \
--visibility=private \
--networks=prod-vpc,shared-svc-vpc
--networks 旗標列出每個被允許解析這個區域的 VPC。沒在清單裡的 VPC，即便在同一個專案內也看不到這個區域。之後可以用 gcloud dns managed-zones update 加上或移除網路。
水平分割 DNS（Split-Horizon）
水平分割解析對同一個名稱回給內部與外部客戶端不同答案。在 Cloud DNS 上的作法很直接：給 example.com. 建立一個公開區域，裡面放對外的 IP；再建一個私有區域，DNS 名稱同樣是 example.com.、授權給你的 VPC，裡面放內部 IP。VPC 內的 VM 解析 api.example.com 時，私有區域會贏，因為私有區域在 metadata 解析器的順序中排在公開區域前面。外部客戶端解析同一個名稱時，只看得到公開區域。
跨專案綁定
Shared VPC 拓樸常常把私有區域放在主機專案，但希望服務專案也能解析它。只要服務專案的 VM 跑在共用 VPC 上，這個綁定就直接生效，不必逐個專案複製區域。若是非共用 VPC 的跨專案解析，則改用 DNS 對等互連。
DNS 轉送區域與伺服器原則
混合連線需要雙向 DNS：地端客戶端要查雲端名稱，雲端負載也要查地端名稱。
出站轉送（雲端 → 地端）
轉送區域是一種特殊的私有區域，裡面不放記錄、而是放一份替代名稱伺服器清單。VPC 中的 VM 查詢落入該區域的 DNS 名稱時，Cloud DNS 會透過 Cloud VPN 或 Cloud Interconnect 把查詢代理到清單裡的伺服器。
gcloud dns managed-zones create onprem-corp \
--dns-name=corp.example.internal. \
--visibility=private \
--networks=prod-vpc \
--forwarding-targets=10.10.0.53,10.10.0.54
轉送目標必須能透過 RFC 1918 位址跨混合鏈路抵達。Cloud DNS 出站查詢的來源 IP 落在 35.199.192.0/19 區段內，你必須在地端防火牆放行這個範圍、並且把它從 VPN / Interconnect 路由回去。
入站伺服器原則（地端 → 雲端）
入站伺服器原則綁在 VPC 上，會在每個子網路所屬的地區保留一個地區性內部 IP，讓地端解析器可以鎖定這些 IP 查詢。
gcloud dns policies create allow-inbound \
--networks=prod-vpc \
--enable-inbound-forwarding \
--description="允許地端查詢私有區域"
建立後用 gcloud dns policies describe 可以看到地區性 IP 清單。地端 BIND 或 Windows DNS 把雲端私有網域全部轉送到這些 IP 即可。
35.199.192.0/19 來源範圍不是打錯——它是 Google 已知的 DNS Proxy 區段，也是 Cloud DNS 出站轉送、health check 與 IAP TCP forwarding 共用的同一段。把它在地端防火牆放行一次，十幾個 GCP 功能就會一起運作。
參考：https://cloud.google.com/dns/docs/zones/forwarding-zones
轉送模式：標準與私有
轉送流程有兩種傳輸模式。標準模式把查詢透過公開網際網路送給轉送 IP（少用）。私有模式則透過 VPC 的 RFC 1918 連通性（Cloud VPN、Cloud Interconnect 或 Network Connectivity Center）送出。PCNE 偶爾會出題：轉送器「藏在」VPN 後面——只有私有模式可行。
DNS 對等互連區域
DNS 對等互連讓一個 VPC 重用另一個 VPC 的名稱解析，而不必複製記錄。消費者 VPC 建立一個對等互連區域指向生產者 VPC；落入該區域 DNS 名稱的查詢，會用生產者 VPC 的完整解析順序回答——包括生產者的私有區域、轉送區域以及 Google 內部 DNS。
gcloud dns managed-zones create hub-services-peer \
--dns-name=services.internal. \
--visibility=private \
--networks=spoke-vpc \
--dns-peering-network=projects/HUB_PROJECT/global/networks/hub-vpc
這個模式撐起了 hub-and-spoke 架構：單一中樞 VPC 擁有私有區域、地端轉送器與回應原則，每個輻條 VPC 都對等互連到它。沒有 DNS 對等互連的話，每個輻條都得自備一份區域副本，久了會漂移。
DNS 對等互連不具傳遞性。若輻條 A 對等到中樞 H、中樞 H 對等到輻條 B，輻條 A 還是解不到只存在於輻條 B 的記錄。PCNE 考試常常畫三個 VPC 的圖、問為何某個輻條解不到姊妹的記錄——答案永遠是「不具傳遞性」。請改用 hub-pull 模型：每個輻條都直接對等到中樞，記錄統一放在中樞。 參考：https://cloud.google.com/dns/docs/zones/zones-overview#peering_zones
回應原則區域（DNS 防火牆）
回應原則區域（Response Policy Zone, RPZ）是 Cloud DNS 在 DNS 這層的防火牆。它會在解析器把答案回給客戶端之前，覆寫或封鎖特定名稱。每個原則綁一個或多個 VPC，內含規則：比對 DNS 名稱樣式，套用動作——改寫成其他值、回 NXDOMAIN、回固定 IP，或者放行。
使用情境
PCNE 上最主要的兩個情境是封鎖惡意 C2 網域（已知壞主機名稱回 NXDOMAIN）以及把公開主機名稱改寫到內部 IP（storage.googleapis.com → Private Google Access 端點）。改寫模式讓你的 client SDK 不必修改，就能強制流量走私有連線。
gcloud dns response-policies create corp-rpz \
--networks=prod-vpc \
--description="封鎖已知惡意 C2 + 把 GCS 改寫到 PGA"
gcloud dns response-policies rules create block-c2 \
--response-policy=corp-rpz \
--dns-name="malware-c2.example." \
--behavior=bypassResponsePolicy=false \
--local-data='name=malware-c2.example.,type=A,ttl=60,rrdatas=0.0.0.0'
有 RPZ 時的解析順序
回應原則會在任何區域查找之前攔截查詢。順序變成：回應原則 → 私有區域（含對等互連 / 轉送）→ 公開區域 → Google Public DNS。記熟這個順序是考試必考——一個對應 example.com. 的私有區域，會輸給比對同一名稱的 RPZ 規則。
Cloud DNS 上的 DNSSEC
DNSSEC 為 DNS 記錄加上密碼學簽章，讓解析器能偵測快取污染與路徑上的竄改。
啟用 DNSSEC
建立新區域時：
gcloud dns managed-zones create example-public \
--dns-name=example.com. \
--visibility=public \
--dnssec-state=on
既有區域則切換狀態即可，Cloud DNS 會在數分鐘內簽完所有記錄、產出 DNSKEY 與 RRSIG 集。
DS 記錄交接
只在 Cloud DNS 啟用 DNSSEC 是不夠的。你必須在註冊商那邊發佈 DS（Delegation Signer）記錄，讓父區域（com.、org. 等等）公告你的區域已經簽章。沒有 DS，驗證型解析器看到的是未簽章的委派、會直接忽略 RRSIG。用 gcloud dns dns-keys list --zone=example-public 取得 DS 值，貼進註冊商 UI。
PCNE 的 DNSSEC 上線檢查清單：(1) 在 Cloud DNS 區域啟用 DNSSEC、(2) 等到 gcloud dns dns-keys list 顯示 key-signing key、(3) 在註冊商發佈相對應 key tag、演算法、digest 類型的 DS 記錄、(4) 用 dig +dnssec example.com DNSKEY 驗證，確認回應的 ad 旗標出現。略過第 3 步是 DNSSEC 失敗最常見的原因。
參考：https://cloud.google.com/dns/docs/dnssec-config
演算法選擇
Cloud DNS 支援 RSASHA256、RSASHA512，以及橢圓曲線的 ECDSAP256SHA256 與 ECDSAP384SHA384。ECDSAP256SHA256 是建議預設——簽章短、驗證快、解析器支援度廣。只有當你的解析器機隊太舊、無法驗證 ECDSA 時，才退回 RSASHA256。
DNS 路由原則
路由原則把單一記錄集變成流量工程旋鈕。PCNE 期望你對四種類型都熟。
加權輪詢（Weighted Round-Robin）
每個後端有一個非負整數權重。Cloud DNS 依比例回傳 IP。90 / 10 的拆分是 DNS 層金絲雀部署的經典模式。
gcloud dns record-sets create api.example.com. \
--zone=example-public --type=A --ttl=60 \
--routing-policy-type=WRR \
--routing-policy-data="35.1.1.1=90;35.2.2.2=10"
地理位置（Geolocation）
原則把 GCP 區域或客戶端子網路對映到 IP 組。us-east1 的客戶端收到美國後端、asia-northeast1 的客戶端收到東京後端。Cloud DNS 透過 EDNS Client Subnet（ECS）擴充判斷客戶端所在區域；會去掉 ECS 的解析器則退回到由 Google anycast 歸因得到的最近區域。
容錯移轉（Failover）
容錯移轉把主與備援 IP 連同一組 Cloud DNS health check（與負載平衡器的 health check 是分開的）組合在一起。主機健康時 Cloud DNS 只回主要 IP；主機失敗時改回備援 IP。備援 IP 要可達，但本身不會被 health check 檢查。
多值（Multi-Value）
最新加入的多值路由原則，會從更大的池中回傳最多 10 個健康 IP，並隨機化順序。這是 Cloud DNS 對自帶重試客戶端最接近「窮人版負載平衡器」的方案。
DNS 路由原則不能取代負載平衡器。瀏覽器 DNS 快取對 TTL 的遵守並不完美，EDNS Client Subnet 訊號也不是處處都有，客戶端在錯的秒數打一個 dig 就可能被釘在過期答案數小時。把路由原則用在站台層級容錯移轉或粗粒度地理分布上，但每請求等級的決策還是要交給真正的 Global External Application Load Balancer。
參考：https://cloud.google.com/dns/docs/zones/manage-routing-policies
內部 DNS 與 .internal 網域
每台 GCE VM 都自動有兩個 DNS 名稱。新式名稱 <vm-name>.<zone>.c.<project>.internal 可以在整個專案的 VPC 中解析。舊式的地區性 DNS 名稱 <vm-name>.c.<project>.internal 只在 VPC 使用 zonal DNS 時存在。新專案預設用全域內部 DNS，這也是 PCNE 預期的設定。
為什麼重要
*.internal 名稱空間由 Google 管理、永遠在解析順序中勝出——你沒辦法建立一個給 internal. 的私有區域去覆蓋它。若你要自訂內部主機命名規則（api.prod.svc.example.），請放到自己的私有區域、用其他父名稱，絕對不要塞到 .internal 底下。
其他服務的 DNS 名稱
數個 Google API 會發佈可透過 Private Google Access 或 Private Service Connect 使用的私有 DNS 名稱：storage.googleapis.com、bigquery.googleapis.com、compute.googleapis.com。搭配回應原則改寫到 PGA 端點（restricted.googleapis.com 對應 199.36.153.8/30）效果最好。
BIND 相容的區域檔
Cloud DNS 用標準 BIND 格式匯入與匯出區域檔，讓既有區域從 Route 53、地端 BIND 或其他權威伺服器搬過來變得簡單。
匯入區域檔
gcloud dns record-sets import example.zone \
--zone=example-public \
--zone-file-format
典型 BIND 檔包含 SOA 記錄、NS 記錄與大量記錄集。Cloud DNS 會根據指派的 anycast 名稱伺服器自動產生 SOA 與 NS 記錄，所以匯入時若 SOA / NS 有衝突，會被改寫成 Google 的值。
匯出區域檔
gcloud dns record-sets export current.zone \
--zone=example-public \
--zone-file-format
輸出是一份有效的 BIND 區域檔，適合做備份、稽核或遷移。搭配版本控管可以追蹤每一筆變更。
用交易做大量編輯
要做原子性的多筆記錄變更，使用交易：
gcloud dns record-sets transaction start --zone=example-public
gcloud dns record-sets transaction add 35.1.1.1 --name=api.example.com. --ttl=60 --type=A --zone=example-public
gcloud dns record-sets transaction remove 35.0.0.1 --name=api.example.com. --ttl=60 --type=A --zone=example-public
gcloud dns record-sets transaction execute --zone=example-public
任何一筆失敗交易就會乾淨地復原，這是藍綠 DNS 切換的安全路徑。
記錄、IAM 與營運
Cloud DNS 整合了 Cloud Audit Logs 與 Cloud Logging，控制平面與資料平面都看得到。
稽核記錄
每一筆 Create、Update、Delete API 呼叫都會落到 cloudaudit.googleapis.com/activity 記錄裡。用這個串流對非預期的記錄變更發警報——一筆未經規劃的 DELETE 動到根 A 記錄，就是值得呼叫值班的事件。
查詢記錄
私有區域可以在 VPC 原則上開啟 DNS 查詢記錄。VM 的每一筆查詢會出現在 dns.googleapis.com/dns_queries 裡，包含來源 IP、查詢名稱、回應碼與權威來源。這份資料對診斷「為什麼解析不到」非常有用——通常都是查錯了名稱空間、或撞到了回應原則。
IAM 角色
你需要在意的角色：roles/dns.admin（完整讀寫）、roles/dns.reader（讀所有區域）、roles/dns.peer（允許另一個專案的 VPC 當對等互連的生產者端）。在專案層級給 roles/dns.admin 範圍太大；要縮小爆炸半徑，請把它授權在特定代管區域上。
常見問題
轉送區域和出站伺服器原則差在哪？
轉送區域是針對特定 DNS 名稱（例如 corp.example.internal.）把查詢轉給設定的轉送器。出站伺服器原則是把 VPC 中所有未命中的查詢都轉給設定的轉送器，取代 Google Public DNS 當 fallthrough。需要精準混合解析時用轉送區域；若地端是所有名稱的權威來源，就用出站伺服器原則。
我可以把私有區域對等到另一個組織的 VPC 嗎？
可以，前提是生產者端的 VPC 在網路上把 roles/dns.peer 角色授權給消費者專案的服務帳號。消費者建立一個對等互連區域指向生產者 VPC，解析就會跨組織邊界流通，不需要 VPC Network Peering。
我的 DNSSEC 已簽署區域為什麼還收到「insecure」回應？
幾乎都是註冊商那邊的 DS 記錄缺失、過期，或指到 Cloud DNS 已經輪替掉的金鑰。重新跑一次 gcloud dns dns-keys list --zone=ZONE 拿到目前的 DS digest，貼回註冊商、等父區域 TTL 過期（通常 24 到 48 小時）就會生效。
Cloud DNS 在同一個專案裡支援同網域的水平分割嗎？
支援。建立一個公開代管區域與一個私有代管區域，兩者 --dns-name 相同。授權的 VPC 中的 VM 會看到私有區域勝出；網際網路只看得到公開區域。兩個區域各自保有獨立的記錄集，所以同一個名稱可以依呼叫端不同而解析到不同 IP。
我要怎麼在組織裡每個 VPC 上同時封鎖一個惡意網域？
建立一個回應原則，加上對目標名稱回 NXDOMAIN 的規則，然後把這個原則附加到每個需要保護的 VPC。要做組織範圍的原則，就用 Terraform 或 Cloud Asset Inventory 自動掛附網路，新建立的 VPC 也能繼承同一份封鎖清單。
路由原則的 TTL 行為是什麼？
Cloud DNS 會遵守你在記錄集上設定的 TTL，但路由原則讓 TTL 的後果放大。容錯移轉原則設 300 秒 TTL，等於主機 health check 失敗後客戶端仍可能被釘在失敗 IP 長達五分鐘。建議把帶路由原則的記錄 TTL 設在 30 到 60 秒，並接受隨之而來的查詢量提升。