DNS 對很多人來說很抽象，因為平常看不到它在運作。但你只要有網站、信箱、Cloudflare 或 VPS，就一定會碰到它。這篇的目標不是講很學術，而是讓你看完之後真的知道每種常見記錄在幹嘛。
你如果不想每次都只是照著別人的畫面一步一步跟著按，卻不知道自己到底改了什麼，這篇會比較適合你。重點不是讓你背流程，而是讓你下次遇到類似情況時，還知道該怎麼自己判斷。
你會學到什麼
- 把 DNS 最核心的幾種紀錄類型一次看懂，包含進階的 SRV、CAA 記錄。
- 知道網域從輸入網址到找到主機，中間大概經過什麼流程。
- 了解 DNSSEC 如何保護你的 DNS 查詢安全。
- 後續改記錄時不再只靠別人說填什麼就填什麼。
什麼情況最適合先看這篇
- 正在處理網域、解析、Cloudflare 或郵件紀錄，想一次把觀念和排錯順好的人
- 你現在正要處理「DNS 基礎觀念解析」這類操作
- 你希望做完之後不只功能能用，連驗證與排錯也有概念
開始前先確認
- 先準備一個你正在使用或打算設定的網域。
- 知道目前 DNS 是交給註冊商、Cloudflare 還是主機商。
- 變更前先把現有紀錄記錄下來。
先提醒你一件事
DNS 問題常常不是設定全錯，而是你同時改了太多地方，最後分不清楚是哪一步造成的。
詳細教學與操作步驟
什麼是 DNS？
DNS（Domain Name System，網域名稱系統）是網際網路的「電話簿」。當你在瀏覽器輸入一個網域名稱（例如 kanrays.net），DNS 會將它轉換為對應的 IP 位址（例如 151.158.27.102），讓你的電腦能找到正確的伺服器。
沒有 DNS，你必須記住每個網站的 IP 位址才能連線，這顯然不切實際。DNS 讓我們可以使用容易記憶的名稱來存取網路資源。
常見 DNS 記錄類型
| 記錄類型 | 用途 | 範例值 |
|---|---|---|
| A | 將網域指向 IPv4 位址 | 203.0.113.10 |
| AAAA | 將網域指向 IPv6 位址 | 2001:db8::1 |
| CNAME | 建立網域別名，指向另一個網域名稱 | www.example.com → example.com |
| MX | 指定處理電子郵件的郵件伺服器 | mail.example.com（優先順序 10） |
| TXT | 存放文字資訊，常用於網域驗證、SPF、DKIM 等 | v=spf1 include:_spf.google.com ~all |
| NS | 指定管理該網域的名稱伺服器 | ns1.cloudflare.com |
| SRV | 指定特定服務的伺服器位址與 port | _sip._tcp.example.com |
| CAA | 指定哪些 CA 可以簽發 SSL 憑證 | 0 issue "letsencrypt.org" |
A 記錄 vs AAAA 記錄
A 記錄和 AAAA 記錄做的事情一樣：把網域對應到 IP 位址。差別在於 IP 的版本：
- A 記錄：對應 IPv4 位址（例如
203.0.113.10），目前最常用。 - AAAA 記錄：對應 IPv6 位址（例如
2001:db8::1），因為 IPv4 位址快用完了，IPv6 是未來趨勢。
如果你的主機有提供 IPv6 位址，建議 A 和 AAAA 都設定。這樣不管訪客用的是哪種網路，都可以順利連上你的網站。目前台灣的行動網路（如中華電信 4G/5G）已經大量使用 IPv6，設定 AAAA 記錄可以讓行動裝置連線更快。
CNAME 記錄使用時機
CNAME（Canonical Name）是「別名」的概念。最常見的用法是讓 www.example.com 指向 example.com：
www CNAME example.com
CNAME 有幾個重要限制：
- 根網域不能用 CNAME：
example.com（根網域）只能用 A 或 AAAA 記錄，不能用 CNAME。 - 同名不能並存：如果某個名稱已經有 CNAME，就不能再有 A、MX 或其他記錄。
- 會多一次查詢：DNS 解析器需要先解析 CNAME 指向的目標，再去查那個目標的 IP，速度比 A 記錄多一個步驟。
什麼時候適合用 CNAME？當目標 IP 可能會變動時（例如指向 CDN 或雲端平台），用 CNAME 比較方便，因為對方改 IP 時你不需要跟著改。
SRV 記錄：指定服務位置
SRV（Service）記錄比較進階，用來告訴 DNS「某個特定服務在哪台伺服器的哪個 port」。格式比其他記錄複雜：
_服務名._協定.example.com. TTL IN SRV 優先順序 權重 port 目標主機
常見用途：
- Microsoft 365：需要 SRV 記錄讓 Teams 和 Skype for Business 正常運作。
- SIP（VoIP 電話）：讓 VoIP 設備自動找到通話伺服器。
- Minecraft 伺服器：讓玩家用自訂網域連線，不用記 port 號碼。
範例（Microsoft 365 Teams）：
_sipfederationtls._tcp.example.com. 3600 IN SRV 100 1 5061 sipfed.online.lync.com.
大多數站長不需要手動設定 SRV 記錄，通常是使用特定雲端服務時，對方會提供需要新增的值。
CAA 記錄：控制誰能簽發 SSL 憑證
CAA（Certificate Authority Authorization）記錄讓你指定哪些憑證機構（CA）可以為你的網域簽發 SSL 憑證。這是一個很實用的安全機制：
# 只允許 Let's Encrypt 簽發憑證
example.com. CAA 0 issue "letsencrypt.org"
# 只允許 Sectigo 簽發憑證
example.com. CAA 0 issue "sectigo.com"
# 只允許 DigiCert 簽發萬用字元憑證
example.com. CAA 0 issuewild "digicert.com"
# 當有未授權的簽發嘗試時，通知你
example.com. CAA 0 iodef "mailto:ssl-alert@example.com"
CAA 記錄的好處：
- 防止誤發：即使有人通過了其他驗證，如果 CA 不在你的 CAA 清單中，憑證不會被簽發。
- 提升安全性：減少憑證被惡意簽發的風險。
- 不設也可以：如果你沒有設定 CAA 記錄，任何 CA 都可以簽發憑證（這是預設行為）。
如果你的網站使用侃瑞科技的 SSL 全程代管服務，我們會根據你的憑證供應商協助設定正確的 CAA 記錄。
什麼是 TTL？
TTL（Time To Live，存活時間）是 DNS 記錄的快取時間，以秒為單位。它告訴 DNS 解析器：「這筆記錄可以快取多久，過期後需要重新查詢。」
- TTL 較高（例如 86400 秒 = 24 小時）：查詢速度快，但修改後生效較慢。
- TTL 較低（例如 300 秒 = 5 分鐘）：修改後很快生效，但會增加查詢次數。
常見 TTL 設定參考：
| 情境 | 建議 TTL | 說明 |
|---|---|---|
| 日常使用 | 3600 秒（1 小時） | 平衡速度與彈性 |
| 準備搬家/切換前 | 300 秒（5 分鐘） | 提前 24 小時調低 |
| 很少變動的記錄 | 86400 秒（24 小時） | 減少查詢次數 |
| CDN / 負載平衡 | 60-300 秒 | 配合動態調度 |
建議： 日常使用設定 3600 秒（1 小時）即可。如果你計畫修改 DNS 記錄，建議先將 TTL 降低至 300 秒，等修改完成並確認生效後，再調回較高的值。
DNS 解析流程
當你在瀏覽器輸入 www.kanrays.net 時，DNS 查詢會經過以下步驟：
- 瀏覽器快取： 瀏覽器先檢查自己是否已經有這個網域的 IP 記錄。
- 作業系統快取： 若瀏覽器沒有，向作業系統的 DNS 快取查詢。
- 遞迴解析器（Recursive Resolver）： 通常是你的 ISP 或公共 DNS（如 Google 的 8.8.8.8、Cloudflare 的 1.1.1.1）提供的伺服器，它會代替你完成後續查詢。
- 根名稱伺服器（Root Server）： 解析器詢問根伺服器：「
.net的管理伺服器在哪裡？」 - TLD 名稱伺服器：
.net的伺服器回應：「kanrays.net由這些名稱伺服器管理。」 - 權威名稱伺服器（Authoritative Server）： 最終查到
www.kanrays.net的 A 記錄，取得 IP 位址。 - 回傳結果： IP 位址沿途回傳並在各層快取，瀏覽器使用該 IP 連線至伺服器。
如果你想看更詳細的圖解流程，可以參考 DNS 解析完整流程圖解。
什麼是 DNS 傳播？
當你修改 DNS 記錄後，新的設定不會立即在全世界生效。由於各地的 DNS 解析器都有快取，需要等待舊快取過期後才會取得新記錄，這個過程稱為「DNS 傳播」。
傳播時間取決於原本設定的 TTL 值，通常在數分鐘到 48 小時之間。在傳播期間，不同地區的使用者可能會看到不同的結果（新舊記錄並存）。
你可以使用 dnschecker.org 檢查全球各地的 DNS 傳播狀態。
DNSSEC：保護 DNS 查詢安全
DNSSEC（DNS Security Extensions）是一套為 DNS 加上數位簽章的安全機制。它的目的是防止 DNS 回應被篡改，確保你查詢到的結果確實來自正確的權威伺服器。
為什麼需要 DNSSEC？
一般的 DNS 查詢是明文傳輸，沒有任何驗證機制。攻擊者可以透過「DNS 劫持」或「DNS 快取汙染」，讓你的查詢結果指向惡意伺服器。例如：
- 你查詢
bank.example.com，攻擊者回傳假的 IP，把你導到釣魚網站。 - ISP 或中間人竄改 DNS 回應，插入廣告或追蹤程式。
DNSSEC 透過在每筆 DNS 記錄上附加數位簽章，讓解析器可以驗證回應的真實性。
DNSSEC 運作方式簡述：
- 權威伺服器用私鑰為每筆 DNS 記錄簽名，產生 RRSIG 記錄。
- 對應的公鑰存放在 DNSKEY 記錄中。
- 上層 DNS（例如
.net的 TLD）用 DS 記錄來建立信任鏈。 - 解析器從根伺服器開始，一層一層往下驗證，確保每個回應都是正確的。
如何啟用 DNSSEC？
- 如果你用 Cloudflare 管理 DNS，到 Dashboard → DNS → DNSSEC 頁面一鍵啟用。
- 啟用後，Cloudflare 會提供 DS 記錄，你需要到網域註冊商那邊把 DS 記錄加上去。
- 兩端都設定好後，DNSSEC 就會生效。
注意事項：
- DNSSEC 不加密 DNS 流量（加密是 DoH / DoT 做的事），它只驗證回應的正確性。
- 啟用 DNSSEC 後如果要轉移網域或更換 DNS 服務商，記得先停用 DNSSEC，否則可能造成解析失敗。
DNS 記錄實際應用對照表
| 你想做什麼 | 需要哪些記錄 |
|---|---|
| 網站上線（基本） | A 記錄（根網域 + www） |
| 網站上線（含 IPv6） | A + AAAA 記錄 |
| 收發 Email | MX + SPF（TXT）+ DKIM（TXT） |
| 防止郵件偽造 | SPF + DKIM + DMARC（TXT） |
| 使用 CDN 服務 | CNAME（指向 CDN 網域） |
| Google Workspace 驗證 | TXT（驗證碼）+ MX + SPF |
| 限制 SSL 簽發權 | CAA 記錄 |
| Microsoft 365 Teams | SRV 記錄 |
常見 DNS 設定錯誤與修正
以下是站長最容易犯的 DNS 設定錯誤，提前知道可以少走很多冤枉路：
錯誤一：根網域設 CNAME
# 錯誤做法
example.com CNAME somewhere.cdn.com
# 正確做法
example.com A 203.0.113.10
www CNAME example.com
根網域（@）不能用 CNAME，因為 CNAME 不能和其他記錄並存，會導致 MX、TXT 等記錄全部失效。
錯誤二：多筆 SPF 記錄
# 錯誤做法（兩筆 SPF）
@ TXT "v=spf1 include:_spf.google.com -all"
@ TXT "v=spf1 +a +mx -all"
# 正確做法（合併成一筆）
@ TXT "v=spf1 +a +mx include:_spf.google.com -all"
一個網域只能有一筆 SPF 記錄。如果有多筆，驗證會直接失敗。
錯誤三：MX 記錄指向 IP
# 錯誤做法
@ MX 10 203.0.113.10
# 正確做法
@ MX 10 mail.example.com
MX 記錄的值必須是網域名稱，不能直接填 IP 位址。
錯誤四：CNAME 和 A 記錄同時存在
# 錯誤做法
www A 203.0.113.10
www CNAME example.com
# 正確做法（擇一）
www A 203.0.113.10
# 或
www CNAME example.com
同一個名稱不能同時有 CNAME 和其他記錄。
做完後怎麼確認自己真的有設對
- 至少用
dig、nslookup或線上工具再驗一次，區分是設定錯、快取，還是 propagation。 - 重新看一次你剛剛改過的設定值、網址、帳號或紀錄，確認沒有填錯對象。
- 如果這篇操作會影響正式網站或正式信箱，建議再從不同網路或不同裝置測一次。
這一題最常踩的坑
- 把 CNAME、A、MX 記錄混成同一件事。
- 不知道 TTL 是什麼，改完就一直刷新等結果。
- 以為 DNS 設對了，網站就一定能正常開。
- 根網域設了 CNAME 導致 MX 記錄失效。
- 沒有設 CAA 記錄，不知道哪些 CA 可以簽發你的憑證。
如果你要往下一步走
如果你想看更直覺的解析過程，接著看 DNS 解析完整流程圖解。 如果你接下來要把網站正式上線，也可以直接銜接侃瑞的 主機方案 或 VPS 方案。