GCP帳號認證開戶 谷歌云 DNS 權權設定與子域名授權步驟

第一章：先把「權權」講清楚

談谷歌云 DNS（Google Cloud DNS）時，很多人卡在一個詞：權權。實務上它不是某個神秘按鈕，而是「誰擁有某個 DNS 區域（zone）的管理權」，以及「怎麼讓其他人或其他系統取得對子域名的控制」。

DNS 的分層很直觀：根域到頂層域，再到你自己的域名。每一層都由上層透過 NS 記錄指出「請去哪裡問」。所以，只要你能讓上層知道子域名應該由哪組權威 DNS 名稱伺服器（authoritative nameservers）負責，子域名就等於把「查詢入口」交出去了。剩下的，就是你在自己的 DNS 服務上把對應的 zone 建好、設定權限，讓授權方可以管理。

在 Google Cloud DNS 裡，常見的目標通常有兩種：

• 你是主域名持有者（例如 example.com），想把 子域名（例如 dev.example.com）交給另一個團隊或帳號管理。
• 你自己有一個平台，但不同環境（prod、staging、test）或不同產品線需要分開管理。你希望子域能各自自治，同時仍保留安全與可控。

無論哪種，本質都回到一件事：把子域名「委派（delegation）」到對方的權威 DNS，並把你自己的 zone 權限與對方的操作範圍對齊。

GCP帳號認證開戶 第二章：你需要先確認的三件事

開始操作前，先做三個確認，能避免 80% 的踩坑。

1）你的主域名 DNS 現在在哪裡託管？

如果主域名（例如 example.com）的權威 DNS 已經在 Cloud DNS，那流程會相對順；如果主域名仍在其他提供商（例如某個註冊商、Cloudflare、Route 53），你就需要在那裡新增 NS 委派指向。

關鍵判斷：你要控制的是「哪一層」的權威。

• 如果你要把 dev.example.com 委派出去，你必須在 example.com 的權威 DNS 內新增 NS 記錄。
• 如果你要委派 apps.dev.example.com，那就需要在 dev.example.com 的權威 DNS 內新增 NS 記錄。

2）你準備怎麼管理權限？

Google Cloud DNS 的權限是透過 IAM（Identity and Access Management）。你要分清楚「誰擁有 zone 的管理權」以及「權限授予的粒度」。

一般做法是：授權方先取得對某個 zone（或資源）的特定權限，讓它可以新增/修改 DNS 記錄。若你希望授權方只能管子域，通常就把它限制在子域對應的 zone 裡。

3）你要授權的是「建立記錄」還是「完整管理」？

授權不一定等於把所有權限給出去。實務上你可以做到：

• 只允許對 DNS record 做新增與修改（避免刪除 zone 或更改委派）。
• 或允許刪除/建立 zone（通常更高風險，需更嚴格審核）。

這會影響你授予的 IAM 角色選擇。

第三章：權威 DNS 委派的邏輯（NS 記錄就是鑰匙）

DNS 委派的核心是 NS 記錄。當你新增：

GCP帳號認證開戶 dev.example.com 的 NS 指向某組 Cloud DNS 提供的 nameservers（例如 ns-cloud1.googledomains.com 類型的地址），世界各地解析器在查 dev.example.com 時，就會改去問那組權威伺服器。

因此流程常常是：

1. 在你控制的主域權威 DNS（example.com）中，新增一組 NS 記錄，把 dev.example.com 指向 Cloud DNS。
2. 在 Cloud DNS 裡建立對應的 zone（例如 dev.example.com 對應的 zone），並填入需要的 A/CNAME/AAAA 等解析記錄。

注意：委派和解析是兩段式。你只做一半通常都會失效。

第四章：在 Google Cloud DNS 建立子域名 Zone（準備權威端）

假設你的主域名 example.com 在某個地方託管，而你要把 dev.example.com 委派到 Cloud DNS。接下來你要在 Cloud DNS 建立 zone。

GCP帳號認證開戶 步驟一：登入 Google Cloud 控制台並進入 Cloud DNS

進到 Cloud DNS 之後，找到「Zones（區域）」管理頁面。

步驟二：建立新 zone

建立時你會看到幾個關鍵設定：

• Zone name：你的內部識別用名稱，可自訂。
• DNS name：例如 dev.example.com.（注意末尾點號在概念上很重要，介面通常會要求你確認格式）。
• Zone type：通常選 Public（若你要對外公開解析）。

GCP帳號認證開戶 步驟三：選擇紀錄與驗證策略

建立 zone 後，你會獲得一組權威 nameservers。這組就是你在主域名的權威 DNS 裡要填的 NS 記錄內容。

這裡要提前想好你準備放哪些解析記錄：

• 如果你有負載平衡或雲服務，可能是 A/AAAA 指向 IP。
• 如果你要指向某個主機名，常見是 CNAME。
• 若你未來要用憑證或驗證，還可能需要 TXT 記錄（例如 ACME / 驗證用）。

第五章：在主域名權威 DNS 做「委派」設定（交出入口）

到這一步你才算真正開始「授權」。因為委派是上層告訴下層：請去問 Cloud DNS。

假設 example.com 的權威 DNS 現在由其他服務商管理，你要在那裡新增 NS 記錄，指向 Cloud DNS zone 提供的 nameservers。

GCP帳號認證開戶 步驟一：收集 Cloud DNS 提供的 nameservers

回到 dev.example.com 的 zone 詳細頁面，複製 nameservers 列表。一般會有多筆（為了容錯與一致性）。

步驟二：在 example.com 新增 NS 記錄

你需要添加：

• 名稱（Name / Host）：dev（或 dev.example.com.，依介面格式而定）
• 類型（Type）：NS
• 值（Value）：對應的一筆 nameserver（例如 ns-cloud1.googledomains.com.）

通常需要填完整的多筆 NS；缺少可能導致解析不穩或部分解析器行為不一致。

步驟三：確認 TTL 設定合理

TTL 不需要太小。太小會增加變更成本與 DNS 查詢負擔；太大則讓你排錯變慢。初期驗證可以用中等 TTL，待穩定後再調整。

GCP帳號認證開戶 第六章：授予子域名授權（IAM 角色與資源邊界）

完成委派後，接下來要解決「授權管理」。你要讓對方能在 dev.example.com zone 內操作，但又不越界影響其他區域。

在 Google Cloud 中，你可以透過 IAM 控制對 Cloud DNS 資源的存取。

思路：用最小權限包住授權方

你可以把授權方限定為：

• 只能對特定 Project（或特定區域資源）操作
• 只能做 DNS record 的修改
• 避免他擁有更高風險的刪除 zone、修改委派或改動其他 zone 的權限

步驟一：進入 IAM & Admin（或權限）頁面

選擇對應的專案（Project）。如果你的 Cloud DNS zone 在某個 Project 裡，權限也要在那裡設定。

步驟二：新增成員（Member）並選擇角色（Role）

實務上常用的方向是：

• 需要管理記錄：授予能管理 Cloud DNS records 的角色（具體角色名稱以當前介面為準）。
• 只需要讀取：授予 viewer 角色。
• 避免授予能管理整個 zone 的高權限角色，除非你確實需要。

GCP帳號認證開戶 建議你先用「對方必須完成的最小任務」反推角色，而不是先給到看似全能的角色。

步驟三：使用條件（Condition）時再保守

若你的組織有更細的策略（例如僅允許特定網域內的服務帳號、限制特定資源），可以使用 IAM 條件。但初次上手時，先確保基本委派與 zone 配置正確，再談條件可以減少問題定位成本。

第七章：建立子域解析記錄（授權後真正要跑起來）

授權成功不是看你設定了 NS 就結束。你還要確保 dev.example.com 下面的主機能解析，且解析內容符合業務。

常見記錄：A / AAAA / CNAME

• A：IPv4 指向（例如某服務負載的公網 IP）。
• AAAA：IPv6 指向。
• CNAME：把 dev 子域指向另一個完整主機名（常用於指向由服務商提供的端點）。

若你使用的是負載平衡或網關，通常你會有固定的端點或 IP。把它填入對應記錄。

如果你需要 Email 或驗證（TXT / MX / SRV）

很多團隊在上線後才發現：網站能開了，郵件或第三方驗證失敗。這往往是因為 TXT、MX 等記錄沒有納入子域授權與初始化。

常見需求包括：

• ACME/憑證：TXT 記錄驗證
• Email：MX 記錄
• 平台整合：特定服務要求 TXT 或 SRV

建議你在授權流程的早期就列出「子域需要哪些記錄類型」，並把它納入變更計畫。

第八章：驗證與除錯（讓你知道到底是哪一步錯）

當解析不生效，你會遇到兩種狀況：要嘛還沒委派成功，要嘛委派成功但 zone 記錄不正確。以下是實務上最有效的驗證順序。

驗證步驟一：確認 NS 委派是否已反映

在本機或測試機上查詢 dev.example.com 的 NS。你要看到它指向 Cloud DNS zone 的 nameservers。

如果 NS 還停留在原狀，通常是：

• 主域名沒有新增正確 NS
• NS 值填錯（例如少一筆或填到錯誤的 host 格式）
• TTL 尚未過期或快取未刷新（尤其是你頻繁改動時）

驗證步驟二：確認權威 zone 內記錄是否存在

去看 dev.example.com zone 內是否有你期望的 A/CNAME/TXT 記錄。更重要的是，記錄的名稱（例如 www.dev）、類型、值是否正確。

常見低級但高頻問題：

• 記錄的「主機名」輸入錯了（把 dev 當成 www）
• CNAME 與其他記錄衝突（同一名稱下不能同時放某些類型，具體規則依 DNS 標準）
• 把相對值/絕對值混用，導致解析出錯

驗證步驟三：用權威查詢確認落點

你可以針對 Cloud DNS nameserver 做權威查詢（避免本機快取干擾）。如果權威回覆正確，代表 zone 設定沒問題；若權威回覆不對，回去修 zone 記錄。

第九章：維運建議：讓授權能長期穩定

DNS 是長期系統。授權與委派不是一次性設定完就永遠不用管。你要把維運納入流程。

1）建立變更節奏與回滾機制

建議你把：

• 新增記錄
• 更換 CNAME 或 IP
• 調整 TTL
• 變更 NS 委派

都納入版本化管理。至少保留變更前的記錄快照，出問題可以快速回滾。

2）把授權方與你的界線寫清楚

你可以在文件或流程裡規定：

• 對方能改哪些記錄（例如只能改 A/CNAME/TXT，不得改 NS 與 zone 屬性）
• 對方是否能建立新主機名
• 誰負責驗證與公告

權限若設得太寬，出了事故你也不好追責；設得太窄，對方又會頻繁卡流程。

3）監控解析與憑證狀態

很多故障不是「完全不解析」，而是特定區域解析慢、TTL 設定過高、憑證過期、或某個記錄漏配。把監控做起來能大幅降低影響範圍。

GCP帳號認證開戶 監控可以涵蓋：

• DNS 查詢延遲與成功率（至少針對主要主機名）
• 憑證有效期（若依賴 DNS 驗證）
• 關鍵服務健康度（確認解析後仍能連線）

第十章：常見誤區整理（看完就少踩坑）

很多問題不是你不會，而是流程理解偏了。下面列出最常見的誤區。

誤區一：只在 Cloud DNS 設了 zone，但沒做委派

這會導致 dev.example.com 在全球解析時仍由原權威負責，Cloud DNS 變成「你自己在裡面忙，別人根本不問」。

誤區二：做了 NS 委派，但 zone 記錄沒有準備好

委派之後，解析會走到 Cloud DNS，但如果 A/CNAME/TXT 沒填對，就會出現 NXDOMAIN 或指向錯誤端點。

誤區三：授權方拿到權限，但拿不到正確的資源邊界

例如 zone 在 A project，授權方卻在 B project 設了角色；或者你把權限給到太大範圍導致審計困難。權限要對齊資源實體。

誤區四：同時修改多處快取導致排錯失去時間線

頻繁改 NS、頻繁改 TTL、又同時換記錄，很容易不知道哪次變更導致現象。建議一次只改一個核心點，並留意 TTL 與變更時間。

第十一章：一套可落地的「子域名授權」完整流程（建議清單）

如果你希望把整件事做成可交接、可複製的流程，這裡給一套清單式步驟。你可以照做，也可以拿去跟團隊對齊。

階段 A：準備與規劃

• 確認主域名權威 DNS 目前在哪裡託管
• 確定子域名範圍（dev.example.com 還是 apps.dev.example.com）
• 列出子域名需要的記錄類型（A/CNAME/TXT/MX 等）
• 確認授權方要做的任務（僅管理記錄？是否含建立 zone？）

階段 B：在 Cloud DNS 建立子域 zone

• 建立 Public zone：DNS name = dev.example.com
• 記下 Cloud DNS 提供的 nameservers
• 先預填必要的解析記錄（至少包含核心網站/服務所需）

階段 C：在主域權威 DNS 做委派

• 在 example.com 新增 NS：dev.example.com 指向 Cloud DNS nameservers
• 確認至少完整填入所有 NS 記錄
• 觀察 TTL，給出合理的生效時間

階段 D：授予 IAM 權限

• GCP帳號認證開戶 在 zone 所在 project 裡新增授權方成員
• 授予最小權限（能管理 records 的角色，而非全能管理）
• 必要時限制只能作用於目標 zone（若組織策略允許）

階段 E：驗證與交付

• 驗證 NS 委派已指向 Cloud DNS
• 驗證 A/CNAME/TXT 等記錄解析正確
• 通知授權方開始配置剩餘記錄
• 建立監控與回滾預案

GCP帳號認證開戶 結語：把「委派」與「權限」拆開，你就會越做越順

谷歌云 DNS 權權設定與子域名授權步驟之所以容易讓人挫折，是因為它同時包含兩個層面的事情：一個是 DNS 查詢路徑要走到哪裡（委派），另一個是有人能不能在那裡改東西（權限）。當你能把這兩件事分開思考，你就能像排程一樣逐步完成，遇到問題也知道先查哪裡。

只要你沿著「建立 zone → 主域委派 NS → 授予 IAM → 驗證解析」這條主線走，再配上最小權限與變更節奏，子域名授權就不會只是操作手冊上的一句話，而會成為你團隊可持續運作的能力。