2.2 購買與託管網域：Cloudflare Registrar 與 DNS 設定實務#

本節目標#

理解 Registrar 在 DNS 生態系中的角色與定價原理
完成網域註冊，或把既有網域的 DNS 託管遷移到 Cloudflare（NS 更換流程）
熟練操作 Cloudflare DNS 面板：新增、代理（橘雲/灰雲）、CNAME Flattening
規劃子網域架構（www / api / cdn），並正確設定 MX/SPF/DKIM/DMARC 等郵件記錄

Registrar 的角色：租約而不是買斷#

2.1 節已說明委派模型。Registrar（註冊商）在生態系中的位置：

  你 ──(每年付費租用)──> Registrar ──(註冊寫入)──> TLD registry (.com 的 Verisign)
                                                   │
                                             在父區寫下 NS 委派
                                                   │
                                                   v
                                   你的權威 DNS（Cloudflare）

嚴格說沒有人「擁有」網域——你取得的是對註冊資料的排他租約，其規範由 ICANN 制定。因此 Registrar 的合理定價應該只有「成本 + 服務費」；Cloudflare Registrar 的賣點正是以批發價（wholesale cost）銷售、零加價、無續約陷阱，用來吸引你把更多流量帶進它的網路。

比較點	傳統 Registrar	Cloudflare Registrar
定價	首年優惠、續約跳價常見	成本價，首年=續約
附加推銷	隱私保護、SSL 額外收費	WHOIS 隱私免費
限制	商用/轉出代碼流程繁瑣	轉入前需先轉 DNS 託管

情境一：直接在 Cloudflare 買新網域#

操作路徑（Dashboard → Domain Registration → Register Domains）：

搜尋想要的網域，Cloudflare 會列出可用的 TLD 與到手年價。
選擇年數、確認 WHOIS 隱私（免費，建議開）。
付款完成後，網域自動加入 Cloudflare 帳號並使用 Cloudflare 名稱伺服器——因為註冊與 DNS 都在同一平台，NS 記錄直接寫好，零遷移成本。

情境二：把既有網域「轉 DNS 託管」到 Cloudflare#

遷移的本質：換 NS 記錄#

先釐清一個常見誤解：把網域「加入 Cloudflare」不會轉移註冊商，只是把權威 DNS 換到 Cloudflare。做法是在 Cloudflare 建立一個 zone，拿到兩個名稱伺服器（例如 amara.ns.cloudflare.com、dan.ns.cloudflare.com），再去舊 Registrar 把 NS 記錄換掉。

時間軸（NS 切換）：

t0  在 Cloudflare 完整複製所有 DNS 記錄（步驟 B）
t1  在舊 Registrar 提交新 NS
t2  註冊商寫入 TLD registry（最快，分鐘級）
t3  .com 權威開始回應新 NS + 新 TTL 期間，救 resolver 快取逐漸過期
t4  全網生效（等於舊 NS 記錄的 TTL，可能長達 24-48 小時）

遷移期三大注意事項#

先複製、後切換：切換前必須在 Cloudflare 建立所有現存記錄，否則上線即斷網（別只靠 Cloudflare 自動掃描，務必逐一人工核對，特別是 MX 與 SPF）。
代理預設開啟與否：Cloudflare 匯入時，跟你網站相關的 A/CNAME 會自動橘雲（代理）。代理後源站真實 IP 被隱藏；但若你的記錄還需要被第三方直連（某些 API webhook、郵件伺服器），要保持灰雲。
先降 TTL 再切換：在舊 DNS 平台把 NS 記錄與關鍵 A 記錄的 TTL 降到 300 秒，等 24 小時，再執行 NS 切換——出錯時能回滾得快。

順手啟用 DNSSEC#

在 Cloudflare DNS 面板點選啟用，取得 DS 記錄（含 digest），貼回舊 Registrar 的 DNSSEC 設定欄。順序很重要：先在 Cloudflare 啟用、再到 Registrar 填 DS，反過來會造成驗證失敗（SERVFAIL）。

進階：連 Registrar 也一起轉進來#

若連註冊都要轉進 Cloudflare（registrar transfer）：先在 Cloudflare 加入 DNS，等新 NS 生效後，再到舊 Registrar 解除鎖定並取得 transfer code（EPP code），於 Cloudflare 發起轉入。轉移過程只搬註冊資料、不會改動已指向 Cloudflare 的 NS，期間網站不受影響。

DNS 記錄面板實務操作#

Dashboard → 選擇 zone → DNS → Records → Add record：

欄位	說明
Type	A / AAAA / CNAME / TXT / MX / NS / CAA ...
Name	子網域（填 `@` 代表根網域）
Content	IP 或目標名稱
Proxy status	橘雲=Cloudflare 代理，灰雲=DNS only
TTL	Auto（代理時固定 300s）

橘雲 vs 灰雲的判斷原則#

橘雲：走 Cloudflare 邊緣，取得 CDN、防護、免費 SSL——本書網站全用橘雲。
灰雲：純 DNS 解析，適合郵件伺服器、不該被代理的服務、或 Cloudflare 不代理的連接埠。

子網域架構規劃#

在本書貫穿的「部落格 + 留言板 + 檔案下載」網站中，建議初始規劃：

子網域	用途	記錄型別	代理	未來對應服務
`example.com`	主站（部落格）	A / CNAME	橘雲	Pages
`www`	主站別名	CNAME → 根	橘雲	301 到主站
`api`	後端 API	CNAME	橘雲	Workers
`cdn`	靜態檔/圖片	CNAME	橘雲	R2 自訂網域

原則：每個子網域對應清楚的單一職責。不要用路徑混雜多服務（例如 example.com/api 一開始方便，但混部署、混快取策略、混憑證範圍）。這不是教條——若未來確定整站都是 Workers + Pages（都是 Cloudflare 自家），同一網域可承載，書中後續章節會依專案規模再討論。

郵件相關記錄：MX / SPF / DKIM / DMARC#

即使網站本身不收發信，你仍需要正確的郵件記錄（例如用 Gmail 寄出密碼信、用 Notion 寄確認信），否我們被判定為垃圾信，甚至你的網域被他人拿來偽造發信。

記錄	Name	目的	範例值
`MX`	`@`	指定收信伺服器	`1 smtp.google.com`
`TXT` (SPF)	`@`	聲明「誰可以替我發信」	`"v=spf1 include:_spf.google.com ~all"`
`TXT` (DKIM)	`google._domainkey`	讓信件帶著公鑰簽章	`v=DKIM1; k=rsa; p=MIIB...`
`TXT` (DMARC)	`_dmarc`	指示收信方驗證政策	`"v=DMARC1; p=quarantine; rua=mailto:dmarc@..."`

三者是分工而非重複：SPF 檢查發信 IP、DKIM 驗證內容未竄改、DMARC 規定「驗證失敗怎麼辦」。常見坑：SPF 是 TXT 型別（不是 SPF 型別）；一個網域只能有一條 SPF（多條即失效）；DKIM 記錄由郵件服務商提供金鑰、你只負責貼進去。

用 CLI 驗證#

dig +short NS  example.com          # 應回 cloudflare 名稱伺服器
dig +short A  @1.1.1.1 example.com  # 透過公共 resolver 驗證
dig +short TXT example.com          # SPF 應出現 v=spf1
dig +short MX  example.com          # 郵件路由

也可以到 dnschecker.org 從全球節點確認 NS/記錄已擴散。

小結與練習#

本節把 DNS 理論落到面板：Registrar 是租約中介；Cloudflare 提供零加價註冊與免費的權威 DNS；遷移的核心是「先複製記錄、降 TTL、再換 NS、補 DS」四步；橘雲/灰雲與子網域規劃決定了後續所有網站架構；郵件三件套（SPF/DKIM/DMARC）保護你的發信信譽。

練習：

用 whois example.com. 查詢你任選網域的註冊資料，找出 Registrar 與 NS 欄位。
若你的舊 DNS 平台在 example.com 上有 A 與 MX 記錄，切換到 Cloudflare 時哪一筆你必須保持灰雲？為什麼？
為什麼 SPF 必須放在根網域的 TXT，而不是 _spf 子網域？
假設你誤把 MX 指向了代理中（橘雲）的主機，會發生什麼？（提示：Cloudflare 不代理哪個連接埠）