GCP認證帳號購買 GCP 域名轉入與轉出完整操作流程

前言：把「轉入 / 轉出」當成工程而不是操作

很多人處理域名時，習慣把它當成一次性的「把 A 記錄填進去」。但在實際工作裡，域名轉入（從原註冊商或既有 DNS 服務商轉到 GCP）與域名轉出（反向遷回或改由其他 DNS 托管）往往牽涉多個環節：註冊商設定、權威 DNS、解析記錄、憑證驗證、TTL 生效時間、快取與監控。任何一個環節只要疏忽，就可能導致網站閃斷、郵件異常或憑證續期失敗。

因此我更建議把這件事當成一個可驗證的工程流程：每一步都要有「輸入是什麼、做了什麼、怎麼驗證、失敗怎麼回退」。下文會用完整操作視角，把你從開始準備到最後驗證、再到轉出遷移的風險控制，一次串起來。

第一章：轉入前的盤點與準備（不做這一步，後面會很痛）

1.1 確認你的域名類型：網站、API、郵件、還是混合

不同用途決定你要轉入哪些 DNS 記錄，以及你最怕什麼。例如：

• 網站與 API：通常關心 A / AAAA、CNAME、（可能還有）CAA、ALIAS（取決於提供商）、以及用於負載或網域驗證的 TXT。
• 郵件：通常更敏感的是 MX、SPF（TXT）、DKIM（TXT/CNAME）、DMARC（TXT）、反向解析則取決於郵件服務提供商。
• 證書：如果用的是 ACME/Let’s Encrypt 或 Google Cloud 相關驗證方式，TXT 記錄或其他機制可能是必需的。

你需要先知道自己目前「哪些記錄在起作用」，才能確保轉入後不漏。

1.2 找出現有 DNS 的權威來源與解析鏈路

轉入 DNS 時，很多人只看得到某個管理頁的記錄，但你真正要轉的是「權威 DNS」（authoritative nameserver）。常見狀況如下：

• 域名註冊商同時提供 DNS：你把名字伺服器切過去即可。
• 你使用第三方 DNS（例如 Cloudflare、AWS Route 53、其他商家）：你要確認目前域名的 NS 指向哪邊，並了解 TTL 與快取。
• 使用多子域：主域名與子域可能分別委派（delegation）到不同 DNS。

簡單說：先確定「今天解析到底去哪裡問」。如果你連這一步都沒釐清，轉入時很難判斷問題出在 GCP 記錄，還是切換尚未生效。

1.3 把現有記錄完整抄下來（建議用可核對的格式）

開始轉入前，請把以下內容按「類型 + 主機名/層級 + 值 + TTL」整理好：

• A、AAAA、CNAME
• MX、TXT（含 SPF、DMARC、驗證用 TXT）
• CAA（若有）
• NS（若你也做了子域委派，請一併記下）
• 任何特殊記錄（例如 SRV）

這一步會直接影響你是否能在轉入失敗時快速回滾。

1.4 觀察 TTL 與快取策略：把風險壓到最小

DNS 變更需要時間，因為解析器可能快取。轉入前可以做的風險控制：

• 在切換前至少 24–48 小時把關鍵記錄 TTL 降低（如果你可以控制）。
• 保留現有設定不動，直到你在 GCP 端完成並驗證所有記錄。
• 安排切換時段：低流量時段、以及你有足夠時間做回查。

如果你無法降低 TTL，那就更要確保你在切換時已經準備好所有記錄，避免「切了才填，填了才查」。

第二章：GCP 端建立 DNS 架構（Cloud DNS 為核心）

2.1 準備：Cloud DNS 的專案、權限與域名策略

在 GCP 使用 Cloud DNS，前提是你有正確的權限並且清楚你要把哪個 zone 代表哪個域名：

• 通常會建立一個 public zone，對應你的公開網域（例如 example.com）。
• 若是只要管理某個子域（例如 api.example.com），也可能建立 delegated zone 或另設 zone（取決於你的 NS/委派策略）。
• 確保你不會把不同環境（prod/stage）混在同一個 zone，避免誤切。

2.2 建立 Public Managed Zone

在 Cloud DNS 端建立一個 Managed Zone，輸入：

• DNS 名稱（顯示用途，不影響解析）
• DNS 域名（例如 example.com）
• GCP認證帳號購買 Zone 類型：public

建立完成後，Cloud DNS 會給你一組 name server（NS），這就是後面你要在註冊商切換的關鍵。

2.3 將現有記錄逐一映射到 Cloud DNS

你要把「現有記錄清單」照搬進 Cloud DNS。常見映射如下：

• A / AAAA：填入對應 IP。
• CNAME：填入目標主機名（注意不要把根域做 CNAME；根域通常用 A 或 AAAA）。
• MX：輸入郵件服務的交換主機名與優先權（priority）。
• TXT：SPF、DMARC、DKIM 憑證、驗證用 TXT 都在這裡。
• CAA（若有）：填入允許的憑證發行者。

如果你曾在其他 DNS 服務商使用自動化模板，記得核對 Cloud DNS 是否要求完全一致的格式（例如 TXT 的引號、特殊字元、或多段字串）。

2.4 檢查「根域 vs 子域」的常見坑

不少錯誤不是記錄填錯值，而是填錯主機名位置：

• GCP認證帳號購買 根域（example.com）通常在介面上會用特定欄位表示（例如留空或使用 @，依介面而定）。
• 子域（www.example.com、mail.example.com）必須精準填入。
• 如果你有從舊系統搬來的「看起來一樣」記錄，仍要確認主機名是否完全一致。

建議做一個小測試：每個類型至少抽查一筆（例如抽查 www 的 CNAME、mail 的 MX、根域的 TXT）。

第三章：轉入切換（先驗證再切 NS）

3.1 先在 GCP 端驗證解析結果（在切 NS 前）

切換 NS 之前，你仍然可以驗證 GCP zone 裡的記錄是否正確。方法取決於你工具習慣，核心目標是「用 GCP 的權威來源查得到你剛填的記錄」。

你要看到的現象是：

• 權威查詢能回傳你期望的 A/CNAME/MX/TXT 值。
• 不要看到舊服務商的值（如果你用權威查詢，應該只看 Cloud DNS）。

如果你看到返回不一致，先不要急著切 NS。回頭檢查 zone、記錄類型、以及主機名是否填對。

3.2 在註冊商切換 NS：把權威 DNS 指向 Cloud DNS

切換 NS 的動作通常在域名註冊商管理頁完成。你會把當前的 NS 集合替換為 Cloud DNS 提供的那組。

• 注意：NS 切換有可能是「全域替換」，確保你不是只想切子域卻誤切主域。
• 切換後等待：通常數十分鐘到數小時，視快取而定；有時也需要更久。
• 不要同時做其他變更：降低變因，方便追查。

3.3 切換後的觀察節點：分段驗證網站、郵件與憑證

NS 切換後，你應該按優先順序檢查：

1. 網站/服務：確認前端可訪問、API 回應正常（這取決於你用 A/CNAME 指到什麼目標）。
2. 郵件：確認 MX 生效、SPF/DMARC 是否能驗證（不要只看是否能收信，還要看是否被判定為垃圾或被拒信）。
3. 憑證/驗證：若有到期續簽，先觀察是否仍能完成域名驗證流程。

GCP認證帳號購買 如果你做了很多 A 記錄或多個服務，建議你用一張簡單的表記錄「檢查結果（成功/失敗/延遲）」並標註時間點，方便你回看問題是否與 TTL 相關。

第四章：轉入後的排查與修正（讓問題在生效期內被抓到）

4.1 常見現象：解析延遲但仍在「正常區間」

有時候你會看到：

• 有些地區解析到新 IP，有些還在用舊 IP。
• 同一個查詢工具顯示不一致結果。

這通常是快取造成。你可以採取的策略是：

• 用權威查詢確認 Cloud DNS 端記錄沒有問題。
• 觀察一段時間，尤其在 TTL 還未完全過去時。
• 若網站仍是關鍵業務，避免在解析混合期間再動手改動多個記錄。

4.2 記錄類型錯配：最容易被忽略的錯

常見狀況包括：

• 把需要 A 記錄的地方填成了 CNAME，或反過來。
• 根域誤用 CNAME，導致某些解析器行為異常。
• TXT 記錄格式不一致，導致 SPF/DMARC 判定失敗。

這類問題通常不是「慢」，而是「一直錯」。一旦確認權威回應符合你的預期，下一步才是看應用端或證書端是否仍依賴其他設定。

4.3 郵件問題的排查順序（不要亂猜）

郵件最怕「部分生效」，所以要按順序檢查：

1. MX 指向是否正確（主機名與優先權）
2. SPF TXT 是否能在新 DNS 上查到
3. DKIM 記錄是否完整（有些服務需要多條 TXT）
4. GCP認證帳號購買 DMARC 是否正確（策略會影響是否隔離或拒收）

如果你在舊 DNS 有做子域委派（例如讓 mail.example.com 指到另一套 DNS），轉入時要特別確保委派沒有被打斷。

第五章：轉出前的策略（你要的是可控遷移，不是臨時修補）

5.1 轉出原因不同，流程細節不同

轉出可能是：

• 更換 DNS 服務商或整併管理。
• 出於成本/管理偏好。
• 需要用特定功能（例如更靈活的流量切換或特定郵件安全設定）。

不論原因，你都應該把轉出看成：把現有設定「重建」到新 DNS，同時控制切換節奏。

5.2 把 Cloud DNS 視為「來源」，建立完整遷移清單

轉出前的核心工作是建立「你在 Cloud DNS 上目前的最終版記錄清單」。理由是：轉入期間可能做過修正，你要確保轉出的版本是最新且正確的。

• 導出或逐項核對：A/AAAA/CNAME、MX、TXT（含 SPF/DMARC/DKIM）、CAA、任何你自訂的記錄。
• 確認 TTL 設定（或至少知道你現在的 TTL 值）。

如果轉出後你想快點回滾，這份清單會是你的救命稻草。

5.3 降低中斷風險：先在目標 DNS 建好，再切 NS

通用策略是「先建後切」。也就是：

1. GCP認證帳號購買 在新 DNS 服務商建立對應 zone 並填好所有記錄。
2. 用權威查詢或工具驗證解析結果符合預期。
3. 確認所有外部依賴（郵件、憑證、應用）可以正常工作。
4. 最後再切 NS，讓權威來源切到新服務商。

GCP認證帳號購買 這能最大程度避免「一切換就壞」的情況。

第六章：轉出操作流程（從 Cloud DNS 切走到新權威生效）

6.1 在新 DNS 建立 zone 與記錄

在目標 DNS（可能是另一個 Cloud、另一家商家，甚至可能是你回到註冊商內建 DNS）完成以下工作：

• 建立與你域名對應的 public zone。
• 將 Cloud DNS 中的記錄逐一填入。
• 檢查格式是否一致，特別是 TXT、MX、以及 CNAME 的指向。

如果新 DNS 對記錄欄位的表示方式不同（例如根域用的符號），要小心映射錯誤。

GCP認證帳號購買 6.2 驗證新 DNS 的權威解析（切 NS 前完成）

驗證方式依工具而定，但你要達到的結果是：用權威方式能查到正確值，且網站/郵件/憑證驗證流程至少不會因 DNS 出錯。

這一步你做得越嚴謹，轉出越穩。

6.3 切換註冊商 NS：把權威來源指向新 DNS

當新 DNS 記錄驗證完成後，在註冊商管理頁把 NS 切到新 DNS 提供的那組。

• 同樣建議避免在切 NS 的同時做其他重大改動。
• 切換後密切觀察網站、郵件與憑證。

GCP認證帳號購買 6.4 Cloud DNS 的處置：保留多久才刪除？

切 NS 後，不代表 Cloud DNS 立刻失效。實務上建議：

• 在觀察完成（例如至少覆蓋一個關鍵 TTL 週期）之前，不要立刻刪除所有 zone。
• 保留回滾能力：若新 DNS 出現問題，你可能需要快速把 NS 切回 Cloud DNS。
• 確認郵件與憑證：郵件可能有排隊或重試機制，憑證續期則是時間敏感。

你可以把 Cloud DNS 當成「備援 DNS」，不是切完就清空。

第七章：常見坑與對應解法（把時間花在對的地方）

7.1 切 NS 後網站還是舊：你可能忽略了應用端快取或 CDN

即使 DNS 已切換，若你的網站背後有 CDN 或應用端快取，你仍可能看到舊流量指向或舊證書。解法是同步檢查：

• CDN 是否有自己的快取鍵與 TTL（通常要等或手動刷新）。
• 應用是否有固定上游解析（例如某些服務在啟動後才解析一次）。
• 證書是否已更新（若用 SNI / 憑證驗證與 DNS 變動同時發生）。

7.2 TXT 記錄轉移失敗：SPF / DMARC 會讓你以為是別的問題

TXT 記錄常見問題包括：

• 格式不一致（例如多段字串的分割方式）。
• 遺漏了某些子域（例如只有主域，卻需要 mail 子域特定記錄）。
• 多條 TXT 在新 DNS 沒有以相同方式合併，導致判定結果改變。

解法是：不要只測「能不能查到 TXT」，要測「郵件安全策略是否符合預期」。

7.3 CNAME 與根域：不是每個地方都能這樣寫

根域（apex domain）的 CNAME 寫法在某些環境可能被限制或需要特殊支援。若你在舊 DNS 使用了某種 alias 功能，在新 DNS 未必能等價配置。

最保守的解法通常是：

• 根域用 A/AAAA（對應你實際 IP 或負載服務輸出的固定地址）。
• 或在新 DNS 使用其提供的 alias/ANAME 功能（若存在且行為等價）。

第八章：實用檢查清單（照著做，你就能把成功率拉起來）

GCP認證帳號購買 8.1 轉入檢查清單

• 已盤點現有 DNS 記錄（A/AAAA/CNAME/MX/TXT/CAA/其他）。
• 了解當前 NS 指向哪個權威服務商。
• 在 Cloud DNS 建好 public zone，並逐項填入記錄。
• 切 NS 前已完成權威解析驗證。
• GCP認證帳號購買 切 NS 後按順序檢查：網站 → 郵件 → 憑證。
• 保留切換前的舊設定，具備回滾可能。

8.2 轉出檢查清單

• 從 Cloud DNS 匯出/核對最新記錄清單（確保是最終版）。
• 在新 DNS 建好 zone 並填入全部記錄。
• 切 NS 前完成新 DNS 權威解析驗證。
• 切 NS 時避免同時更改其他系統。
• 切換後觀察足夠時間，再決定是否刪除 Cloud DNS。
• 郵件與憑證的驗證時間點已納入計畫。

結語：把轉入轉出做成「可重複的流程」

域名轉入與轉出看似只是切換權威 DNS，但本質上牽涉整條鏈路：記錄是否正確、權威是否切對、快取是否可控、以及郵件與憑證等外部依賴是否能在新解析下正常工作。當你把每一步都做成「準備—建立—驗證—切換—觀察—回退」的流程，成功率會明顯提升，也能把事故影響縮到最低。

如果你願意，下一步我可以根據你的實際情境（例如你的域名用途、目前 NS 指向哪裡、是否涉及郵件與憑證、以及你要轉入/轉出到哪個服務）把這份流程再細化成「逐記錄對照表」與「檢查時間表」，讓你可以直接照著跑。