Defaults.Exposed › 修復 › CAA 記錄

如何修復 CAA 記錄

CAA 記錄是你網域設定裡的一條簡短指令，指定哪些憑證公司被允許為你的網站簽發那張小鎖安全憑證。開啟它之後，再沒有別的公司能悄悄以你的名義建立一張有效憑證。

對您業務的關鍵影響： 沒有 CAA 記錄，全球數百家憑證公司裡幾乎任何一家都能為你的網域簽發一張真實、被完全信任的小鎖憑證——讓騙子能立起一個外觀完美、看上去完全安全的你網站克隆版，去收割你客戶的登入資訊和卡號，而螢幕上沒有任何東西會警示他們。

這會讓您付出什麼代價

• 騙子為你網站的一份副本拿到一張真實憑證，於是它顯示綠色小鎖和 HTTPS——你的客戶看不出任何不對，照樣輸入密碼和卡號，而你直到退款和憤怒來電開始時才知道。
• 你的客戶被一個像素級還原的登入頁仿冒品釣魚；後續的爛攤子——退款、客服負擔、聲譽受損——都落在你的品牌上，哪怕你真實的網站從未被碰過。
• 潛在客戶的安全或採購團隊在簽約前對你的網域做一次快速檢查，發現沒有 CAA 防護，便悄悄把你記為基礎薄弱——一份只要五分鐘就能加上的設定，卻把一筆交易置於風險之中。
• 全球某家憑證公司被攻破（這反覆發生過——DigiNotar、Comodo、Symantec），而因為你從未指明誰有權代表你行事，你的網域就暴露在那個最終成為薄弱環節的公司面前。

為什麼它重要。 眼下大門是敞開的：地球上任何憑證公司都能為一個聲稱是你的網站背書，無論你是否與它打過交道。一條 CAA 記錄鎖上那扇門，只讓你選定的提供商能簽發憑證——它是對抗有人在網路上冒充你這家企業最簡單、最便宜的防禦。

一句話說清 CAA 記錄

每個安全網站都有一張憑證——就是瀏覽器裡小鎖背後、以及你地址前面那個 https 所代表的東西。這些憑證由叫憑證授權機構（CA）的專業機構發放：諸如 Let’s Encrypt、DigiCert、Sectigo、Google Trust Services 這些名字。當你的瀏覽器看到一張有效憑證時，它會顯示小鎖，並告訴你的客戶這個連線真實且安全。

下面這一點，大多數業主從沒被告知過：預設情況下，全球數百家這樣的憑證授權機構，每一家都被允許為你的網域簽發憑證——無論你是否聽說過它們。一條 CAA 記錄（憑證授權機構授權，Certification Authority Authorization）是你加進網域 DNS 設定裡的一行說明，大意是只有這些提供商被允許為我簽發憑證。按行業規則，每一家正規的憑證授權機構在簽發前都必須查驗那行說明——若它不在你的名單上，就必須拒絕。

這就是一扇任何人都能走進來的沒上鎖的前門，和一扇只有你選定的人持有鑰匙的門之間的區別。而加上它不花一分錢。

這會讓你付出什麼代價

CAA 記錄所封堵的風險，是足以亂真的冒充。當騙子能為你網站的一份副本拿到一張真實憑證時，通常的警示信號就消失了——沒有破損的小鎖，沒有不安全的橫幅，沒有憑證錯誤。一切看上去都對，而這正是它危險的原因。

• **完美的仿冒品。**騙子註冊一個相似的地址（或攻破一條通往你客戶的路徑），拿到一張真實憑證，立起一個你登入頁或結帳頁的完美克隆——連小鎖都有。客戶照常輸入密碼和卡號。你聽到的第一個動靜，是一波退款、欺詐舉報和憤怒的電話。
• **以你之名的網路釣魚活動。**攻擊者發送請確認你的帳戶的郵件，連結到他們帶憑證的你網站克隆版。因為那個頁面看上去完全安全，上當的人更多。善後——通知客戶、退款、客服工時、那場尷尬的公開說明——全都落在你頭上，哪怕你真實的伺服器從未被碰過。
• **卡在清單上的交易。**一個較大客戶的安全或採購團隊在簽約前掃描你的網域。無 CAA 記錄會在你名字旁顯示為一個紅色或橙色條目。技術上是小事，但它讀作連基礎都不做，足以拖慢或拖垮一份你本來能拿下的合約。
• **被別人的事故連累。**一家你從沒打過交道的憑證授權機構被攻破——這不是假想；DigiNotar、Comodo 和 Symantec 都出過嚴重事件。因為你從未限制誰能代表你行事，攻擊者就能透過那家薄弱的 CA 為你的網域拿到一張有效憑證。一條 CAA 記錄本會拒絕他們。
• **萬用字元盲區。**即使是對主站很謹慎的企業，也常常忘了子網域。沒有 issuewild 規則，一個能拿到萬用字元憑證的攻擊者，實際上就一次拿到了你今後會有的每一個子網域的鑰匙。

這些都不需要對你伺服器發動高深的攻擊。它們利用的是這樣一個事實：沒有 CAA 記錄，更廣泛的憑證系統在替你做事時實在太輕信了。

它實際上是什麼，以及良好的狀態長什麼樣

CAA 記錄存在於你網域的 DNS 裡——就是把你網域指向網站和信箱的那套設定。每條記錄有三部分：一個標誌位、一個標籤和一個值。要緊的標籤有：

• issue——指定被允許為你網域簽發普通憑證的某家憑證授權機構。你可以有好幾條，每個你正當使用的提供商一條。
• issuewild——管控萬用字元憑證（一張涵蓋每個子網域的憑證，如 *.example.com）。如果你不用萬用字元，推薦的設定是把它們完全封禁。
• iodef——一個可選的聯絡地址，當某家憑證授權機構因你的 CAA 策略而拒絕一次請求時，你會在那裡收到通知。這是有人嘗試過的早期預警。

**良好的狀態長什麼樣：**至少存在一條 issue（或 issuewild）記錄，指定了你實際使用的提供商，並且萬用字元要麼被限制給某個指定提供商、要麼被封禁。這就是本檢查衡量的標準——它跨多個獨立的解析器查詢你網域的 CAA 記錄，當發現一條真實的 issue 或 issuewild 策略到位時通過。一個完全沒有 CAA 記錄的網域，被當作它本來的樣子：一扇敞開的門。

這會影響我的評分嗎？會。缺失的 CAA 記錄是一個計分項，標為中等嚴重級——它是一個真實的漏洞，而不只是錦上添花，因為它留著一條真實的冒充通道。加上這條記錄就堵住漏洞、清除該發現項。

如何修復（免費，約 5 分鐘）

**把這一節交給管理你網域或網站的人——修復是免費的。**它是一個小的 DNS 改動，不是重建。只有當你之後想讓我們持續盯著這條記錄是否在位時，我們才收費；加上它不花一分錢。

**第一步——弄清你實際使用的是哪家憑證授權機構。**這是唯一值得做對的一步，因為列錯提供商會擋住你下一次續期。常見情形：

• Let’s Encrypt——許多主機和控制台（cPanel、Plesk）都在用 → letsencrypt.org
• Cloudflare（如果由它簽發你的邊緣憑證）→ letsencrypt.org、digicert.com、comodoca.com、pki.goog 和 ssl.com（Cloudflare 使用多家後端 CA；把它儀表板裡顯示的那些、或它的完整集合都列上，續期才永不中斷）
• Google Workspace / Google Trust Services → pki.goog
• DigiCert → digicert.com
• Sectigo / Comodo → sectigo.com（以及 comodoca.com）
• Microsoft 365 / Azure——微軟的託管憑證通常用 DigiCert → digicert.com（請在你的入口網站裡確認）

如果不確定，在瀏覽器裡查看你當前的憑證（點小鎖 → 憑證詳情 → 頒發者）就能看到是誰簽發的。

**第二步——登入你的 DNS 提供商。**這是你網域記錄所在的地方——通常是你的註冊商、你的 Web 主機，或 Cloudflare。找到 DNS 記錄區域，選擇添加一條類型為 CAA 的新記錄（有些介面把它標為類型 257）。

**第三步——為你使用的每個提供商添加一條 issue 記錄。**以 Let’s Encrypt 為例：

example.com.   CAA   0 issue "letsencrypt.org"

每個正當的提供商加一行 issue。大多數 DNS 儀表板會給你分開的輸入框來填標誌位（0）、標籤（issue）和值（CA 的網域），這樣你就不必手敲整行。

**第四步——管控萬用字元憑證。**如果你不用萬用字元，就乾脆封禁它們，免得有人悄悄弄到一張：

example.com.   CAA   0 issuewild ";"

如果你確實用萬用字元，就改為指定提供商：0 issuewild "letsencrypt.org"。

**第五步——（推薦）添加一個通知地址。**這樣每當一家 CA 拒絕一次嘗試時你都會被告知——這是有人嘗試過的早期預警：

example.com.   CAA   0 iodef "mailto:[email protected]"

**第六步——儲存並驗證。**執行 dig CAA example.com（或用任意線上 DNS 查詢工具），確認你的記錄出現。改動在網際網路上鋪開可能要幾分鐘到幾小時不等。你現有的憑證和所有續期全程照常工作——CAA 只管新的簽發。

平台速記：在 Cloudflare 上，DNS → Records → Add record → 類型 CAA。在 Google Workspace 上，你在註冊商處管理 DNS（如果用了 Cloud DNS 則在那裡）——在那裡添加帶 pki.goog 的 CAA 記錄。在 Microsoft 365 上，CAA 不在 M365 管理中心設定；在你網域 DNS 所託管的地方添加它，並列上你的託管憑證 CA（通常是 DigiCert）。在常見主機（GoDaddy、Namecheap 等）上，它就在你 A 記錄和 MX 記錄所在的同一個 DNS 面板裡。

常見錯誤

• **列錯了 CA——或漏了一個。**現實中最大的風險不是安全，而是擋住你自己的續期。如果你用了不止一家簽發機構（比如主站一家、Cloudflare 後面又一家），就把它們全列上。拿不準時，寧可多列幾家你信任的，也別列得太少。
• **設了 issue 卻忽略萬用字元。**一個限制了普通憑證、卻對萬用字元隻字不提的網域，仍然敞著那條更強大的萬用字元通道。務必把 issuewild 也設上——要麼指向你的提供商，要麼用 ";" 封禁它。
• **把 CAA 放在錯誤的名稱上。**CAA 由憑證授權機構針對正被簽發的確切名稱、沿樹向上讀取。把它設在你網域的頂層（頂點，如 example.com）是正確做法——除非某個子網域設了自己的，否則它預設涵蓋各子網域。
• 以為你的平台已經做了。Cloudflare、Google 和 Microsoft 管理憑證，但不會替你添加 CAA 記錄。除非你加了，你的網域仍是敞開的。
• **當作一勞永逸、不再監控。**日後的一次 DNS 遷移、一次註冊商變更，或一次記錄大掃除，都可能悄悄丟掉你的 CAA 防護。每次 DNS 改動後，值得檢查它是否還在。

技術層（把這一段交給你的 IT 人員）

CAA 定義於 RFC 8659，並在 CA/Browser Forum 基線要求下強制執行——每家公開受信的 CA 都必須在簽發時查驗 CAA。記錄形如 <flags> <tag> <value>，標籤有 issue、issuewild 和 iodef。滿足本檢查的是一條非空的 issue 或 issuewild 策略；僅有 iodef 不行（它是上報，不是授權）。

頂點處一個穩妥的基線：

example.com.   CAA   0 issue "letsencrypt.org"
example.com.   CAA   0 issuewild ";"
example.com.   CAA   0 iodef "mailto:[email protected]"

給實施者的說明：

• **CAA 沿樹向上：**CA 從被請求的 FQDN 向上評估 CAA，直到頂點，並在第一個設有 CAA 記錄的名稱處停止。因此，頂點處的一條記錄會保護所有子網域，除非某個子網域發布了自己的——它可以這樣做，當某個特定子網域使用不同簽發機構時很有用。
• issuewild 中的 ; 值意為任何 CA 都不得簽發萬用字元——一個顯式拒絕。凡是萬用字元不屬於你方案的，都用它。
• 0 標誌位是簽發方關鍵標誌；常規使用下 0（非關鍵）是正確的。除非你完全理解，否則不要設關鍵位，因為一個被誤解的關鍵標籤可能導致合規的 CA 拒絕簽發。
• **多個簽發機構：**允許多條 issue 記錄且是疊加的——把你技術棧中每一個正當的 CA（包括你 CDN/邊緣提供商使用的後端 CA）都列上，以防續期失敗。
• 驗證：dig CAA example.com +short，或透過 CA/Browser Forum 的 CAA 測試工具核對。本檢查本身會跨多個獨立解析器查詢 CAA（先本地 DNS，再以 Google、Cloudflare 和 Quad9 的 DNS-over-HTTPS 作為兜底），並接受第一個權威答覆，因此單個解析器故障不會產生假的無 CAA 結果。
• **與 DNSSEC 搭配：**CAA 告訴 CA 誰可以簽發；DNSSEC 則阻止 CAA 答覆本身在傳輸途中被偽造。它們是互補的——對高價值網域，兩者都跑。

在您的託管服務商上完成設置

熱門服務商的分步指引：

• 在 GoDaddy 上設置 CAA
• 在 Namecheap 上設置 CAA
• 在 Cloudflare 上設置 CAA
• 在 AWS Route 53 上設置 CAA

常見問題