把 DNS 設定打開，多數人只看過 A 記錄與 CNAME，把網域指向主機就收工。但 DNS 不只是「網址對應 IP」的對照表，它同時是網站安全的第一道門。一旦這道門被攻擊者撬開，使用者輸入正確網址卻被導去釣魚站、憑證被冒名簽發、流量被攔截，這些都不需要先攻破你的主機就能發生。

DNSSEC 設定正是補上這道門鎖的關鍵。它讓 DNS 的查詢結果「可以被驗證」，不再是任何人都能偽造的明文回應。但 DNSSEC 不是孤立的開關，它和 TTL（記錄存活時間）、CAA（憑證簽發授權）這兩項設定彼此牽動：TTL 沒調好，切換 DNSSEC 時可能讓網站短暫解析失敗；CAA 沒設，等於放任全球上百間憑證機構都能替你的網域簽憑證。這三項合起來，才是一套完整的進階 DNS 安全配置。

這篇會把 TTL、DNSSEC、CAA 三者拆開講原理，再講它們怎麼互相影響，最後給出在台灣常見的註冊商與 DNS 代管環境下，該怎麼按順序安全地設定，避免中途讓網站斷線。

TTL 是什麼，數值該設多少才不會切換時出包

TTL（Time To Live）是一筆 DNS 記錄在各地快取伺服器裡可以被保存的秒數。當使用者的電信業者 DNS 伺服器查到你的記錄後，會依這個秒數把結果存起來，期間內所有查詢都直接回傳快取，不再回頭問你的權威伺服器。秒數一到，快取失效，下次查詢才會重新拉一次最新值。

這個機制帶來一個取捨。TTL 設得長，快取命中率高、解析速度快、權威伺服器負載低，但你改了記錄之後，全球快取要等舊秒數跑完才會更新，生效時間就拉長。TTL 設得短，改動能很快擴散出去，但每次快取過期都要重新查詢一次，查詢量與延遲都上升。

實務上常見的配置方式是分情境設定。穩定不動的記錄，例如指向固定主機的 A 記錄、MX 記錄，可以設 3600 秒（1 小時）到 86400 秒（1 天），享受快取的效率。預期要搬家或調整的記錄，則在動工前先把 TTL 壓低。

搬遷或切換前先降 TTL，是最容易被忽略卻最關鍵的一步。假設你目前的 A 記錄 TTL 是 86400 秒，現在要換主機。如果直接改 IP，全球部分快取會抱著舊 IP 整整一天，這段時間有人連得到新站、有人還連舊站。正確做法是搬家前一天，先把 TTL 降到 300 秒（5 分鐘），等舊的長 TTL 快取自然過期、新的短 TTL 擴散開來，再實際改 IP，這樣切換時的不一致視窗就縮到 5 分鐘內。切換確認穩定後，再把 TTL 調回較長的值。

這個「先降 TTL」的習慣，在後面要切換 DNS 代管商或啟用 DNSSEC 時同樣適用，是貫穿這整篇的安全前提。

DNSSEC 設定在防什麼，為什麼傳統 DNS 擋不住

DNSSEC 防的是 DNS 回應被竄改或偽造。傳統 DNS 查詢全程是明文、沒有任何簽章，快取伺服器收到一筆「這個網域對應這個 IP」的回應時，根本無法判斷這筆資料是不是真的由該網域的權威伺服器發出。

攻擊者利用的就是這個信任漏洞。常見手法是快取汙染（cache poisoning）與 DNS 偽造（spoofing）：攻擊者搶在正牌回應之前，餵給快取伺服器一筆假的對應，把某個網域指向自己控制的惡意 IP。之後所有向這台被汙染伺服器查詢的使用者，輸入完全正確的網址，仍會被導到釣魚站。這個過程不需要攻破你的網站主機，只要汙染中途的 DNS 快取就成立。

DNSSEC 用公開金鑰加密替每一筆 DNS 記錄加上數位簽章來堵住這個洞。權威伺服器用私鑰簽署記錄，產生對應的 RRSIG 簽章記錄；支援驗證的解析器收到回應後，用公開金鑰檢查簽章是否吻合。簽章對不上，就代表資料在路上被動過手腳，解析器直接拒絕這筆回應。攻擊者沒有私鑰，就偽造不出有效簽章。

要讓「公開金鑰本身可信」，DNSSEC 建立了一條信任鏈（chain of trust）。這裡牽涉兩種金鑰，先把角色分清楚，後面的設定步驟才看得懂。

ZSK（Zone Signing Key，區域簽署金鑰）負責簽署你網域內一筆筆的實際記錄。KSK（Key Signing Key，金鑰簽署金鑰）只負責簽署 ZSK 那組金鑰，等於是「替金鑰背書的金鑰」。最後，KSK 的公開金鑰會被算出一段雜湊值，做成 DS 記錄（Delegation Signer，委派簽署），交給上一層的網域（你的網域註冊商或上層 TLD，例如 .tw 由 TWNIC 管理）。

信任就這樣一層接一層：根區域信任 TLD、TLD 透過 DS 記錄信任你的 KSK、KSK 簽過的 ZSK 可信、ZSK 簽過的每筆記錄可信。任何一環的簽章對不上，整條鏈就斷，解析器會判定驗證失敗。這也是 DNSSEC 設定最容易出包的地方，後面會專門講。

DNSSEC 設定的實際步驟，從產金鑰到提交 DS 記錄

DNSSEC 設定的核心流程只有三件事：在 DNS 代管端產金鑰並簽署區域、把 DS 記錄交給網域註冊商、驗證整條信任鏈是否接通。差別只在於你用的是哪一種環境。

現在多數人是「一鍵式」環境，也就是 DNS 代管商已經把產金鑰、簽署、輪替全部自動化，你幾乎不用碰底層金鑰。Cloudflare、Google Cloud DNS、AWS Route 53 都屬於這類。以最常見的 Cloudflare 搭配註冊商情境為例，流程如下。

第一步、確認 DNS 代管端與註冊商都支援 DNSSEC。不是每家都支援，尤其是上層 TLD 必須接受 DS 記錄才有意義。.tw 網域可透過 TWNIC 體系的註冊商提交 DS。

第二步、在 DNS 代管後台啟用 DNSSEC。在 Cloudflare 的 DNS 設定頁往下找到 DNSSEC 區塊，按下啟用，系統會自動產生金鑰並簽署整個區域，接著給你一組 DS 記錄資訊，內容通常包含 Key Tag、演算法（Algorithm）、摘要類型（Digest Type）與摘要值（Digest），或是直接給一筆 DNSKEY 供註冊商換算。

第三步、把 DS 記錄填回網域註冊商後台。登入你註冊網域的地方（TWNIC 平台、HiNet、GoDaddy、Gandi 等），找到 DNSSEC 欄位，把上一步那組 Key Tag、演算法、摘要類型、摘要值逐欄填入。演算法欄位現行常見值是 13（ECDSA P-256），這是目前推薦、金鑰短且效率好的選擇。這一步是把你的 KSK 雜湊交給上層，信任鏈才接得上。

第四步、等待生效並驗證。DS 記錄提交後要等上層區域更新，可能幾分鐘到數小時。生效後用線上工具檢查，例如 DNSSEC Analyzer 或 Verisign 的 DNSSEC Debugger，輸入純網域（拿掉 https:// 與路徑，只留最單純的網域名稱），看每一個檢查項目是否都通過、信任鏈是否從根一路接到你的網域。全綠才算成功。

如果你是自管權威伺服器（例如自己跑 BIND），則要自己用工具產生 KSK 與 ZSK、對區域檔簽署產生 DNSKEY 與 RRSIG 記錄、設定自動重新簽署的排程，最後一樣是把 DS 交給註冊商。這條路彈性最大但維護成本也最高，金鑰過期沒重簽會直接讓網域解析失敗，自管前要先確認有能力處理金鑰輪替。

DNSSEC 設定最容易出包的環節，金鑰輪替與停用順序

DNSSEC 一旦設錯，後果比沒設更嚴重：驗證失敗的網域，對開啟驗證的解析器來說是「完全解析不到」，不是降級顯示而是整站連不上。最容易踩雷的有兩處。

第一處是金鑰輪替（key rollover）。金鑰不該永久不換，定期更換可降低私鑰外洩的風險。但換金鑰時，舊金鑰簽過、還在各地快取裡的記錄，必須等它們的 RRSIG 簽章與 DNSKEY 的 TTL 自然過期，新舊金鑰要有一段重疊期同時有效，不能直接拔掉舊的換新的。如果你用的是一鍵式代管，輪替通常由系統自動處理重疊期，你不用操心；但若自管，這裡的 TTL 計算就是前面那套「先降 TTL、等快取過期再切換」邏輯的延伸，急著切會讓抱著舊簽章的解析器驗證失敗。

第二處更常見，是停用 DNSSEC 或更換 DNS 代管商時的順序。很多人想換 DNS 服務商，直接把網域的名稱伺服器（NS）改去新家，卻忘了舊家的 DS 記錄還掛在註冊商那裡。這時上層仍要求用舊 KSK 驗證，但新家根本沒有那把金鑰，信任鏈當場斷裂，網域對所有開啟驗證的使用者瞬間消失。

正確順序是反過來的。要停用 DNSSEC 或搬家，先到註冊商把 DS 記錄移除，等這筆 DS 的移除在上層生效、信任鏈安全地「解除」之後，再去動 DNS 代管端的設定或改 NS。換句話說，啟用時是「先簽好再交 DS」，停用與搬家時是「先撤 DS 再拆簽署」，方向相反，順序錯了就斷線。動工前同樣建議先把相關記錄的 TTL 降低，縮短萬一出錯時的影響時間。

CAA 記錄怎麼設，限制誰能替你的網域簽憑證

CAA（Certification Authority Authorization，憑證機構授權）記錄解決的是另一個層面的問題：誰有資格替你的網域簽發 SSL/TLS 憑證。它和 DNSSEC 都掛在 DNS 上，但管的事不同，一個防 DNS 回應被偽造，一個防憑證被亂簽。

問題的背景是，全球受信任的憑證機構超過上百間。在沒有 CAA 記錄的情況下，任何一間都可以替你的網域簽出有效憑證。萬一某間機構流程出包或被攻破而錯誤簽發，攻擊者就能拿到一張瀏覽器認可的合法憑證來假冒你的網站。CAA 記錄定義於 RFC 6844，作用就是用一筆 DNS 記錄白名單，明確宣告「只有我授權的這幾間機構可以替我簽憑證」。自 2017 年 9 月起，CA/Browser 論壇規定所有憑證機構在簽發前都必須先檢查網域的 CAA 記錄，這項機制因此具備實質約束力。

一筆 CAA 記錄由三個部分組成：旗標（flag）、標籤（tag）、值（value）。最常用的三種標籤如下。

• issue：授權某機構簽發單一網域憑證。值填該機構的識別網域，例如 letsencrypt.org、digicert.com、sectigo.com。
• issuewild：授權某機構簽發萬用字元（wildcard，例如 *.example.com）憑證，規則與 issue 分開管理。
• iodef：指定一個通報聯絡方式（通常是 mailto: 信箱或回報網址），當有機構嘗試簽發不被授權的憑證時，可往這裡送出違規通報。

舉例來說，若你只用 Let’s Encrypt 簽憑證，一組合理的 CAA 設定會是授權 letsencrypt.org 進行 issue 與 issuewild，並設一個 iodef 信箱接收違規通報。要特別留意一個反直覺的規則：如果你完全沒設任何 CAA 記錄，等於對所有機構開放；但只要設了哪怕一筆 issue，沒被列進去的機構就全部被擋在外面。所以設定前務必把你實際在用、未來可能會用的所有憑證機構都列齊，漏掉一間，那間就簽不出來，續簽憑證時才會踩到。

設定方式依環境而定。用 DNS 代管商的人，現在多數後台都能直接新增 CAA 記錄類型，照欄位填旗標、標籤、值即可；若後台沒有 CAA 選項，得聯繫代管商協助。自管 BIND 等伺服器的人，則在 zone 檔裡寫入 CAA 記錄後重新載入。內容不確定怎麼寫時，SSLMate 提供的 CAA Record Helper 能依你網域當前使用中的憑證自動產生對應語法，並涵蓋 BIND、PowerDNS、NSD、Knot DNS 等多種伺服器格式，設定後也能用它回查目前的政策是否生效。

三項設定如何串成一套安全配置，該照什麼順序動手

把 TTL、DNSSEC、CAA 放在一起看，三者的分工其實很清楚：TTL 管「改動多快生效、切換多平順」，DNSSEC 管「DNS 回應是不是真的」，CAA 管「誰能替你簽憑證」。它們不衝突，反而互補，缺一塊安全配置就有缺口。

實際動手時，建議照風險由低到高的順序進行，把最會搞斷線的留到最後、最熟練時再做。

第一、先設 CAA。它風險最低，設錯頂多是某張憑證簽不出來、不會讓整站解析失敗，而且立即就有縮小憑證濫發面的效果。先把現用憑證機構列齊、加上 iodef 通報信箱。

第二、檢視並規劃 TTL。在動 DNSSEC 之前，先把預計會變動的記錄 TTL 降到 300 至 600 秒，替後面的切換預留安全的快取過期窗口。

第三、最後啟用 DNSSEC，並嚴守順序：啟用時先在代管端簽好區域、再把 DS 交給註冊商；日後若要停用或換 DNS 商，務必先撤 DS、再拆簽署。每次動完都用 DNSSEC Analyzer 之類的工具驗證整條信任鏈，確認全綠再收工。

DNS 是使用者連上你網站前必經的第一站，把這一站守好，等於在攻擊者還沒碰到主機前就先擋下大半威脅。先從風險最低的 CAA 設起，養成切換前降 TTL 的習慣，再穩穩地把 DNSSEC 的信任鏈接通，這套配置就能長期替你的網域守住這道最前線的門。