GCP認證帳號購買 谷歌云 DNS 導出與導入解析記錄教學

前言：為什麼要做 DNS 的「導出」與「導入」

很多人第一次管理 DNS 時，會把它當成「一次性的設定」。但實際上，DNS 是持續變動的基礎設施：專案改名、主機搬遷、服務拆分、環境（dev/stage/prod）同步、還有年度的公司域名治理……只要事情開始頻繁發生，手動在控制台逐筆修改就會變得昂貴且危險。

尤其當你遇到以下情況，導出與導入就不再是方便，而是必需：

• 你要把某個網域的解析設定從一個 Google Cloud 專案或環境，搬到另一個。
• 你要做版本化管理：例如把 DNS 設定納入 Git，並能回滾。
• 你要批量調整，例如統一 TTL、調整權重、或新增多個子網域。
• GCP認證帳號購買 你要將 DNS 交給團隊協作，避免「只有一個人知道控制台怎麼改」。

GCP認證帳號購買 導出提供「可審核的快照」，導入提供「可重現的設定」。當兩者搭配使用，你就能把 DNS 變成工程流程的一部分，而不是人為操作的副作用。

範圍與前置概念：你導出的到底是什麼

在 Google Cloud DNS 中，解析記錄不是只有一張表。它通常由「管理區域」與多種「資源紀錄集」組成：

• Managed Zone（管理區域）：對應一個 DNS zone（例如 example.com）。
• Record sets（資源紀錄集）：每個子網域或主機名的解析規則。常見類型包含 A、AAAA、CNAME、TXT、MX、SRV 等。
• TTL：每條記錄適用的時間。
• Routing policy（若有使用）：例如加權或地理路由等。

因此，當你提到「導出 DNS 記錄」，實務上就是把某個 managed zone 下的所有 record sets 以可重建的形式輸出。後續你再把它匯回同一個或不同專案/環境的 managed zone。

準備工作：先把風險降下來

在開始操作前，建議先做幾件事，避免匯入後影響線上流量。

1. 明確目標：匯入到同 zone 還是不同 zone

如果你是「同 zone 同專案」只是做備份與恢復，風險相對低。但如果是「不同專案」或「不同網域」，你需要特別注意：

• 匯入時目標 zone 是否已存在。
• 是否有相同名稱的 record sets，會被覆蓋或衝突。
• 某些資源類型在目標環境是否可用（例如指向特定服務的引用）。

2. 權限與身分：至少要能看與改

你需要的權限通常包含：

• 能讀取 managed zone 與 record sets（導出）。
• 能新增、更新或刪除 record sets（匯入）。

如果你只是準備導出供審核，權限可以更保守。但既然文章主題包含「導入」，就代表你至少要具備變更權限。

3. 準備一份「對照清單」

建議你在匯入前先列出：

• 哪些主機名或子網域是關鍵（例如 www、api、mail、_acme-challenge）。
• 是否有特殊格式（TXT、SPF、DKIM、DMARC）。
• 是否使用了多值記錄（例如一個名稱對應多個 A 記錄）。

因為匯入時最常出問題的，不一定是程式流程，而是某些記錄在整理過程中被意外改掉。

GCP認證帳號購買 導出流程：把 managed zone 的解析記錄拿出來

導出可以用控制台或指令完成。控制台適合快速查看與小規模需求；指令適合批次與可重現流程。以下我以「指令工作流」為主，因為它最貼近「能反覆使用」的工程精神。

步驟 1：確認你要導出的 managed zone

先找出目標 zone 的名稱，並確認它對應的 DNS domain。

你可以在 Google Cloud Console 中進入 DNS，查看 Managed zones。

若用指令，常見做法是列出所有 zone，然後挑選目標。

步驟 2：導出 record sets 到檔案

導出的格式通常是可被匯回的結構資料（例如 JSON）。重點是：你導出的內容要包含 record sets 的關鍵欄位，例如：

• 名稱（name）
• 類型（type）
• TTL（ttl）
• 每條 record 的資料（例如 rrdatas）
• routing policy（若有）

導出的檔案在後續你會做「整理與檢查」，所以建議你用明確的命名規則，例如：

• dns-export_prod_2026-07-22.json
• dns-export_stage_2026-07-22.json

步驟 3：檢查導出結果是否完整

很多人只看檔案大小，卻沒有真正確認內容。你應該做三種檢查：

• 記錄數量：匯入前後比對，避免遺漏。
• 關鍵類型：至少確認 A / CNAME / MX / TXT 是否存在。
• TTL：是否跟你預期一致（有些團隊希望統一 TTL）。

如果你使用了「加權或特定路由策略」，更要確認導出的資料是否包含 routing policy 的欄位。

整理資料：導出後不要直接匯入

導出的檔案通常可以直接匯回，但現實中你幾乎一定會做一些整理。整理的目的不只是「格式匹配」，而是讓匯入變得可控。

1. 核對目標區域與命名空間

GCP認證帳號購買 DNS 記錄的 name 欄位常見兩種思路：有的會包含完整網域尾碼，有的會用相對形式（實務上導出通常已很接近可用狀態）。但當你把檔案從一個 zone 搬到另一個 zone，你要確認：

• 是否所有 record 的名稱都仍正確落在目標網域下。
• 如果新舊網域不同，你是否要做替換或映射。

最常見的錯誤是匯入後「成功執行」但解析不到，原因只是名稱落在錯誤的網域。

2. TTL 與策略一致性

GCP認證帳號購買 如果你的目標環境希望統一 TTL，例如：

• 一般記錄 TTL = 300
• 郵件相關記錄 TTL = 3600

那你就應在匯入前把 TTL 統一。否則你會在未來調整時陷入「為什麼某些記錄更新很慢」的排查。

3. 去除不必要欄位或保留必要欄位

不同團隊的流程會不一樣，有人喜歡保留所有欄位做完全還原，有人只保留可匯入所需欄位以減少複雜度。你應該以「能匯入且可理解」為原則：

• 必要欄位一定要保留：type、name、ttl、rrdatas（或等價資料欄位）。
• 若匯入工具不接受額外欄位，你就要精簡。
• 若匯入工具接受完整欄位，你可以保留以利日後追溯。

匯入流程：把解析記錄寫回目標 managed zone

匯入的核心考量只有一件事：你想達到「期望狀態」。而期望狀態可能包含新增、更新、刪除。

方法一：以「更新/新增」為主（較安全）

如果你目標是「把缺失的記錄補上、並更新現有記錄」，通常你就用一種策略：存在就更新，不存在就新增。這種方式比較安全，特別是在目標 zone 已經在運作，且你不確定現況是否跟導出檔一致。

方法二：以「覆蓋」或「同步」為主（風險較高）

若你想讓目標 zone 完全等於導出檔，甚至刪除額外記錄，就需要同步策略。但這種策略要非常小心，因為你可能不小心刪掉某些手動新增但你沒有納入導出的記錄。

GCP認證帳號購買 所以實務上我建議：

• 第一次遷移用更新/新增，先驗證解析是否正確。
• 確認無誤後再考慮同步或清理。

步驟 1：指定目標 zone 與匯入檔案

匯入前再確認一次：

• 你正在操作的專案與 managed zone 是否正確。
• 你選擇的是「哪一種更新策略」（新增/更新 vs 同步）。

這一步的錯誤通常不是小問題，一旦寫錯 zone，你會直接影響對外服務。

步驟 2：執行匯入並觀察結果

GCP認證帳號購買 匯入過程中你應注意兩類回饋：

• 是否有因格式錯誤導致的失敗（例如類型不支援、資料格式不正確）。
• 是否有因衝突導致的部分寫入或覆寫。

如果工具回傳明確的失敗項目，你就先針對失敗項修正資料；如果回傳較概略，你就要用後續的比對檢查把差異找出來。

步驟 3：匯入後比對期望與實際

這一步比你想像更重要。因為「匯入指令成功」不代表「所有記錄都如你所願」。你可以：

• 再次導出目標 zone，跟你原本的檔案做比對（至少比對關鍵類型與記錄數）。
• 針對關鍵主機名進行解析測試，例如查 A/CNAME/TXT/MX。
• 觀察 TTL 與快取效果，避免因為緩存導致你誤判。

常見問題與排查：為什麼匯入後解析不對

GCP認證帳號購買 DNS 的排查常常讓人沮喪，因為錯誤不一定在「寫入」那一步，而是落在「資料整理」與「客戶端快取」。下面是最常見的坑，並附上排查方向。

問題 1：名稱尾碼或相對/完整格式搞錯

表現：匯入後沒有任何解析結果，或解析到錯誤的網域。

排查：

• 檢查 record 的 name 是否符合目標 zone 的網域結構。
• 確認是否出現多打一個網域尾碼（例如 example.com.example.com）。
• 若有自動替換流程，檢查替換是否只針對你預期的部分。

問題 2：TXT 記錄格式不符合，或多值被合併

表現：驗證失敗（常見於 SPF/DKIM/DMARC），或線上服務提供者提示 DNS TXT 不正確。

排查：

• 檢查 TXT 的每條值是否被正確保留（尤其是多值 TXT）。
• 留意引號、空白、或跳脫符號是否在整理時被破壞。
• 確認匯入後 TXT record sets 的多個 rrdata 是否仍存在。

GCP認證帳號購買 問題 3：CNAME 與其他記錄共存

表現：部分 DNS 提供者或解析器會直接拒絕或忽略某些規則。

排查：

• 確認同一個 name 不同 type 是否違反你的預期（例如同名同時存在 CNAME 與 A）。
• 檢查匯入資料是否把你原本以為屬於不同主機名的資料混到一起。

問題 4：TTL 調整造成你以為沒更新，其實只是快取

表現：你確認匯入成功，但測試工具仍顯示舊解析。

排查：

• 觀察 TTL，並在不同時間點再次測試。
• GCP認證帳號購買 盡量使用能反映權威伺服器的查詢方式（或至少理解查到的是哪一側快取）。

問題 5：匯入策略造成覆寫或刪除

表現：某些記錄原本存在但後來不見了。

排查：

• 確認你匯入用的策略是更新/新增還是同步/覆蓋。
• 匯入後導出目標 zone，跟你之前的快照對比，找出差異項。

一套可落地的實作流程（建議你照做）

下面我給一個我在團隊遷移 DNS 時會採用的流程。你可以依你的實際環境簡化或增加步驟。

步驟 0：建立目標狀態清單

先定義你要讓目標 zone 最終達到什麼樣子。至少要包含：

• 關鍵主機名（web、api、mail、驗證用子網域）。
• 記錄類型與預期值（例如 MX 指向的主機）。
• TTL 策略。

步驟 1：從來源 zone 導出快照

把來源 zone 的解析記錄導出成檔案，並以時間戳命名。把檔案納入你團隊的版本庫或至少本機備份。

步驟 2：在本地做格式檢查與必要整理

不要急著匯入。先做：

• 記錄數量檢查。
• 關鍵類型是否都有。
• 若跨網域/跨專案，確認 name 與策略。

步驟 3：在測試/預發環境匯入並驗證

若你有 stage 環境，優先在 stage 完成匯入。等解析測試通過，再到 prod。

驗證項目不要只測一個地址。至少測：

• A 或 AAAA：主站是否可連。
• CNAME：若你使用，確認跳轉正確。
• MX：郵件驗證相關。
• TXT：SPF/DKIM/DMARC 或第三方驗證。

步驟 4：在 prod 匯入前做最小化變更與窗口控制

如果匯入包含覆蓋，建議在維運窗口進行。就算你做的是更新/新增，也要理解 TTL 快取會影響觀測時間。

步驟 5：匯入後再導出一次並比對

匯入後立刻導出目標 zone 的內容，和你「期望檔」做比對。這一步能快速回答：到底有沒有偏差。

工程化建議：讓 DNS 變成「可維護的資產」

導出與導入本質上是在把 DNS 從「人腦操作」轉成「資料驅動」。但要真正穩定，還需要幾個工程習慣。

1. 把匯入行為寫成文件或腳本

你可以把導出與匯入命令記錄在團隊文件中，並固定輸入輸出檔案的位置。未來你換人接手，少掉很多溝通成本。

2. 對關鍵記錄做人工審核

尤其是 MX 與 TXT。這些通常跟商業服務與安全策略直接相關。你可以在匯入前做一次人工審核，確保沒有「值被搬錯」的低級錯誤。

3. 保留回滾材料

DNS 回滾不是刪除重來，而是把快照導入回去。確保你有來源時點的導出檔，並知道怎麼用。

結語：把 DNS 從操作變成流程

谷歌云 DNS 的導出與導入，真正的價值不在於「省時間」，而在於把 DNS 變成能被檢查、能被回滾、能被審核的工程資產。當你用一致的導出快照來定義期望狀態，再用匯入流程把它重現到目標環境，你就能把 DNS 變更的風險降到最低。

如果你打算從今天開始改造流程，我建議你從最小的目標開始：先把來源 zone 導出一次並保存，接著在 stage 環境做一輪完整匯入與比對。跑通後，你再把它擴展成批量管理或版本化工作流。DNS 不再是黑盒，而是你可以掌控的基礎設施。