六種你會實際用到的記錄
DNS 記錄類型有數十種，但日常維運會碰到的大約就這六種。它們各自回答一個不同的問題：這個名稱指向哪個 IP、這個名稱是不是另一個名稱的別名、這個網域的信件該送去哪、以及誰有權回答這個網域的查詢。
搞混類型是最常見的錯誤來源，而且症狀往往不直觀——例如把應該用 CNAME 的地方寫成 A 記錄，設定當下完全正常，直到對方換 IP 才突然壞掉，而那可能是幾個月後的事。
| 記錄類型 | 用途 | 常見錯誤 |
|---|---|---|
| A | 把名稱指向 IPv4 位址 | 對方 IP 會變時仍寫死 A 記錄 |
| AAAA | 把名稱指向 IPv6 位址 | 只設 A 沒設 AAAA，IPv6 用戶走不到 |
| CNAME | 讓名稱成為另一個名稱的別名 | 設在根網域——協定不允許 |
| MX | 指定收信伺服器與優先順序 | 填 IP 而非主機名稱；優先值理解顛倒 |
| TXT | 存放驗證字串（SPF、DKIM、ACME） | 多筆 SPF 並存導致驗證失敗 |
| NS | 指定誰有權回答此網域的查詢 | 在註冊商與 DNS 商兩邊各改一次，互相衝突 |
下表列出六種記錄與各自最常見的踩雷點。第三欄值得特別看。
為什麼根網域不能用 CNAME
這是最常被卡住的限制，而且它不是設定問題，是協定規定：
- CNAME 不能與其他記錄共存 DNS 規範要求：一個名稱上如果有 CNAME，就不能同時有任何其他類型的記錄。這個規則本身很單純，問題出在它跟根網域的必要條件衝突。
- 根網域必然帶有 SOA 與 NS 記錄 每個網域的根（例如 `example.com` 本身）一定要有 SOA 與 NS 記錄，這是網域能被解析的前提。既然根網域必定已有這兩種記錄，依前一條規則，就不可能再放 CNAME——兩者無法並存。
- 所以想讓根網域指向一個名稱，要用替代方案 多數 DNS 服務商提供 ALIAS、ANAME 或「CNAME 平坦化」之類的功能：對外看起來是 A 記錄，但服務商在背後自動解析目標名稱並回傳其當下的 IP。效果接近 CNAME，但符合協定。要注意這**不是標準功能**，各家名稱與行為不同，換服務商時要重新確認。
TTL：要在變更之前調整
TTL（Time To Live）是你告訴全世界的解析器「這筆記錄可以快取多久」。設 3600 就是一小時，在那一小時內，已經查過的解析器不會再來問你——它會直接用快取的舊答案。
所以當你改了記錄卻發現沒生效，原因通常不是「傳播需要時間」，而是**舊記錄的 TTL 還沒到期**。而關鍵在於：此刻調低 TTL 已經來不及了，因為解析器手上那份舊快取，帶的是它取得時的舊 TTL 值。
日常維運上，變動不頻繁的記錄（如 MX、NS）可以設較長的 TTL；可能需要臨時切換的記錄（如指向源站的 A 記錄）則值得維持較短的值。這是穩定性與應變速度之間的取捨，沒有單一正確答案。
TXT 記錄的兩個實務陷阱
TXT 是最雜的一種記錄，因為它被拿來塞各種驗證資訊：網域所有權驗證、SPF、DKIM、DMARC，以及憑證自動化用的 ACME DNS-01 挑戰值。內容格式各自不同，全部混在同一個名稱底下。
第一個陷阱是 **SPF 只能有一筆**。如果為了新增一個寄信服務而多加一筆 SPF 記錄，結果不是「兩筆都生效」，而是驗證直接失敗——正確做法是把所有來源合併進同一筆。第二個陷阱是**憑證驗證用的 TXT 需要頻繁變動**，如果您的 DNS 服務商沒有 API，就無法自動化，而在憑證效期縮短之後，這會變成每年多次的手動作業。
三個實務判斷
設定前先想清楚這三件事：
一、目標的 IP 會不會變？
會變就用 CNAME 指向對方的主機名稱，讓對方自己管理 IP；不會變才寫 A 記錄。指向 CDN、雲端負載平衡這類服務時尤其如此——它們的 IP 本來就會浮動，寫死 A 記錄等於埋了一顆不知何時會爆的雷。
二、這筆記錄多久會動一次？
這決定 TTL。幾乎不動的設長一點（3600 以上），可能需要緊急切換的設短一點（300 左右）。重點是**在你需要它短之前就先設短**，而不是出事當下才調。
三、誰是這個網域的權威？
NS 記錄決定由誰回答查詢。常見的混亂是：在註冊商改了一次 NS，又在 DNS 服務商的介面改了一次，結果兩邊不一致。實際生效的是註冊局那一份，也就是您在註冊商設定的那一份——這一點在轉移網域或更換 DNS 服務商時特別容易出錯。
變更前該確認的三件事
動手改之前，這三項可以省下很多排查時間：
- 確認目前的 TTL 是多少 這決定變更後最長要等多久。如果是 86400（一天），而您沒有預先調低，那就得有等一整天的心理準備——這時候反覆重新整理瀏覽器不會有幫助。
- 確認要改的是哪一層 註冊商、DNS 託管商、CDN 都可能有一個「DNS 設定」的介面。先確認 NS 指向誰，那一家的設定才是生效的；在沒有權威的那一邊改，改再多次也不會有反應。
- 改完用權威伺服器直接查證 用 `dig @權威伺服器 名稱 記錄類型` 直接向權威伺服器查詢，可以跳過所有快取，立刻確認記錄本身是否正確。若權威回答是對的、其他地方還是舊的，那就純粹是等 TTL 的問題。
小結
DNS 變更的等待時間不是玄學，是您自己設定的 TTL。理解這一點之後，搬遷的正確順序就變得清楚：**先調低 TTL，等一個舊週期，再執行變更**。事後才調 TTL 對當下這次變更沒有幫助。
另一個值得記住的是根網域不能用 CNAME——這是協定層面的限制，各家提供的 ALIAS 或平坦化功能只是各自的變通做法，不是標準。選擇 DNS 服務商時，這項功能以及是否提供 API（憑證自動化的前提）都值得一併確認。