Defaults.Exposed › 修復 › DNSSEC

如何修復 DNSSEC

DNSSEC 是給你網域通訊錄蓋的一枚數位封印。它讓網際網路能證明這個網域住在哪裡這個問題的答案確實來自你、且在途中未被篡改。少了它，答案可被偽造——你的訪客就被悄悄送往別處。

對您業務的關鍵影響： 沒有 DNSSEC，一個能投毒 DNS 答覆的攻擊者可以把你的客戶引向一個你網站的完美副本，而他們瀏覽器裡仍顯示著你真實的網域。登入資訊、卡號和個人資料被收割，你直到退款和投訴時才知道。一個半成品、做壞了的 DNSSEC 設定更糟：它會讓你的網站對越來越大一部分訪客無法訪問，而你永遠不會察覺到任何錯誤。

這會讓您付出什麼代價

• 輸入你真實網域的訪客被悄悄重定向到一個仿冒站點，它截走他們的密碼和卡號——而因為網址列全程顯示你的網域，誰都不會起疑，直到欺詐舉報到來。
• 你的郵件被悄悄改道：攻擊者偽造你郵件伺服器的答覆，讀取或攔截訊息，並在那些會給你發驗證碼的帳戶上重置密碼——全程都不碰你的收件匣。
• 一個半設定的 DNSSEC（公開封印存在、但對應的金鑰缺失）會讓你的網站和信箱對大型 ISP 和企業網路上的客戶時靈時不靈——你無法重現的間歇性你的網站對我打不開的報告。
• 潛在客戶的安全團隊做一次簽約前檢查，發現沒有 DNSSEC，便把你記為基礎薄弱——一份免費的設定卻讓一筆交易陷入風險。
• 公共部門和較大的 B2B 買家越來越把 DNSSEC 當作基線期望（它被寫進了 NIS2 等法規）；它的缺失會在談話還沒開始前就悄悄把你擋在招標門外。

為什麼它重要。 DNS 是網際網路的通訊錄，而它的答案預設是未簽名地傳輸的——任何能塞進一個偽造答覆的人，都能把你的客戶和郵件隨意引向任何地方，而你真實的網域仍顯示在瀏覽器裡。DNSSEC 給這些答案蓋上一枚防篡改的封印，使其能被驗證為確實來自你。在大多數提供商那裡修復是免費的；唯一真實的代價是做錯了——這正是我們要把兩半都仔細走一遍的原因。

一句話說清 DNSSEC

每當有人訪問你的網站或給你發郵件，他們的電腦都會先向網際網路問一個簡單的問題：這個網域到底住在哪裡？答案——你網站和郵件伺服器的那組地址——由 DNS（網際網路的通訊錄）返回。

令人不安的部分是這樣的：預設情況下，那些答案是未簽名地傳輸的。沒有任何東西附在上面證明這個答案是真的。如果有人能在那場對話裡塞進一個偽造的答覆——而確實存在眾所周知、已被驗證的方式做到這一點——你訪客的電腦就會欣然接受它。從那一刻起，訪客可能正在與一台攻擊者的伺服器對話，而他們的瀏覽器裡仍顯示著你的網域。

DNSSEC 就是修復辦法。它給你的 DNS 答案加上一枚防篡改的數位封印。開啟 DNSSEC 後，網際網路能用數學方法驗證一個答案確實來自你、且在途中未被改動。一個偽造的答覆通不過驗證、被丟棄。這就是一本任何人都能亂塗的通訊錄，和一本每個條目都有簽名、有見證的通訊錄之間的區別。

本頁涵蓋我們的檢查一並查看的兩個部分：封印是否已發布（DS 記錄），以及它背後對應的金鑰是否真的存在（DNSKEY 記錄）。你很快會看到為什麼兩者都重要——因為只有其一而無其二，本身就是一種麻煩。

這會讓你付出什麼代價

這些是真實、聚合的模式——不指任何一家具名企業。

• **隱形的重定向。**攻擊者投毒你網域的 DNS 答覆。客戶輸入你真實的網址，在網址列看到你真實的網域，卻落到一個由攻擊者託管的、你登入頁或結帳頁的完美副本上。他們輸入的每個密碼和卡號都直接進了犯罪分子手裡。你只在退款和我是被你網站駭的電話開始時才聽說——而線索通向的是你的品牌，不是攻擊者的。
• **悄無聲息的郵件攔截。**DNS 不只指向你的網站；它也指向你的郵件伺服器。偽造那個答覆，入站郵件就能被先改道經過一個攻擊者。他們讀取敏感訊息、收割那些為驗證是你本人而由服務發送的一次性驗證碼，並在與你網域相關的帳戶上重置密碼——全程從不登入你的信箱。
• **你無法重現的故障。**這一種來自半成品的 DNSSEC 設定。公開封印（DS）擺在你的註冊商處，但對應的金鑰（DNSKEY）缺失或不對。在那些會校驗 DNSSEC 的 ISP 和企業網路上的訪客——而且這類網路逐年增多——乾脆完全無法解析你的網域。對你和你的技術人員來說，網站和信箱都好好的，但一部分真實客戶卻收到此站點無法訪問，而你看不到任何錯誤。它恰恰因為從內部看不見，才是最難診斷的問題之一。
• **丟掉的交易。**潛在客戶的安全或採購團隊對你的網域做一次例行的簽約前掃描。無 DNSSEC 在 DNS 安全基礎上顯示為一個紅點。對一個免費、被充分理解的控制項來說，它的缺失讀作疏忽——足以悄悄讓你丟掉一份你都不知道已陷入危機的合約。
• **你連資格都沒有的招標。**法規和買家清單越來越把 DNSSEC 列為期望的基線安全衛生（它在 NIS2 的 DNS 安全條款下被提及）。較大的 B2B 和公共部門買家可能在銷售對話開始前就把你篩掉，僅僅因為這個框沒打勾。

它實際上是什麼

DNSSEC 以一條信任鏈的方式工作，它有兩個必須彼此吻合的活動部件。這正是我們的檢查要查兩樣東西的核心原因。

**DNSKEY——你的金鑰。**你的 DNS 提供商持有一把加密金鑰，並用它給你的 DNS 記錄簽名。那把金鑰的公開半被發布為一條 DNSKEY 記錄。把它想成握在你這一端的封印圖章。

**DS 記錄——為金鑰背書的指紋。**那把金鑰的一段簡短指紋，叫 DS（委派簽名，Delegation Signer）記錄，被發布在上一級——在你網域的註冊局處，經由你的註冊商。這正是讓網際網路其餘部分信任你金鑰的東西：每一級為下一級背書，一路向上直到網際網路的根。DS 就是那枚封印被正式登記，好讓其他所有人都能認出它。

要讓 DNSSEC 真正保護你，兩者都必須存在、且必須匹配：

• **DS 存在 + DNSKEY 存在且匹配 → 良好。**信任鏈完整。偽造的答覆被拒，正當的被驗證通過。這是通過狀態。
• **無 DS（也無 DNSKEY）→ DNSSEC 乾脆就沒開。**你沒有防護，但什麼也沒壞。這是最常見的尚未做狀態。（在我們的評分裡，這是 DS 檢查記你不利的地方；而組合金鑰檢查把一個乾淨、完全關閉的狀態當作提示性、而非硬性失敗，因為沒有任何東西正在主動壞掉。）
• **DS 存在，但 DNSKEY 缺失或不匹配 → 壞了，比關著更糟。**網際網路看到一枚已發布的封印，卻指向一把並不存在的金鑰。會校驗的解析器據此判定你的網域已被篡改，並拒絕解析它——造成上面描述的間歇性故障。這是最緊急要修的狀態，我們的檢查把它標為高嚴重級。
• **DNSKEY 存在，但註冊商處無 DS → 已開啟但未啟動。**你的記錄已簽名，但因為指紋從未在上一級登記，網際網路其餘部分無從信任它們。你做了功、卻沒有防護。修復辦法是在你的註冊商處添加 DS 記錄。

一句話概括良好的狀態：你註冊商處有一條 DS 記錄，其指紋與你 DNS 提供商處一把在線的 DNSKEY 匹配，兩者都經一次快速查詢確認。

如何修復（免費，約 10–30 分鐘）

**把這一節交給管理你網域或網站的人。**在大多數提供商那裡修復本身免費——唯一的代價是仔細操作，讓兩半保持同步。只有當你之後想讓我們監控它是否一直正確開啟時，我們才收費。

黃金法則：**先啟用簽名（這會建立 DNSKEY），再在註冊商處發布 DS 記錄——絕不反過來，也絕不只做其一而缺另一。**在金鑰存在之前就發布 DS，正是導致故障的原因。

簡單路徑（推薦——Cloudflare）：

1. 在 Cloudflare 裡，確認確實由 Cloudflare 運行你的 DNS（你的網域名稱伺服器指向 Cloudflare）。
2. 進入 DNS → Settings → DNSSEC → Enable DNSSEC。Cloudflare 替你產生並管理金鑰（這會自動建立 DNSKEY 那一半）。
3. Cloudflare 會向你顯示要在註冊商處發布的 DS 記錄詳情。
4. 登入你的網域註冊商（如 GoDaddy、Namecheap、OVH），找到 DNSSEC 區域。把 Cloudflare 給你的 DS 值貼進去。
5. 等待 24–48 小時完全傳播。你的網站和信箱全程照常工作。

其他 DNS 提供商（AWS Route 53、你的 Web 主機等）：

1. 在你 DNS 提供商的控制台裡，啟用 DNSSEC / 給此區域簽名。這會產生簽名金鑰並發布 DNSKEY 記錄。
2. 複製提供商產生的 DS 記錄。
3. 在你的註冊商的 DNSSEC 設定下，添加那條 DS 記錄。
4. 確認註冊商已接受它，並等待傳播。

平台說明：

• Cloudflare——一鍵啟用，再在註冊商處貼上一次 DS。迄今最簡單的路子。
• AWS Route 53——在託管區域上啟用 DNSSEC 簽名，然後在你網域的註冊商處添加 DS 記錄（如果網域註冊在 Route 53，AWS 可以替你關聯）。
• Microsoft 365 / Google Workspace——這些運行的是你的信箱，通常不是你的 DNS 區域。DNSSEC 在你 DNS 記錄實際所在的地方啟用（往往是你的註冊商、主機或 Cloudflare），而不是在 365/Workspace 的管理中心。
• **你的 DNS 提供商根本不支援 DNSSEC？**這在較老或低價的主機上很常見。乾淨的修復辦法是把 DNS 管理遷到一個支援它的提供商（Cloudflare 免費），然後按上面的簡單路徑走。遷移 DNS 不需要遷移你的網站或信箱。

驗證它確實生效：

• 執行 dig DS yourdomain.com 和 dig DNSKEY yourdomain.com——兩者都應返回記錄。
• 或用任意免費的線上 DNSSEC 檢查器，確認一條綠色/有效的信任鏈。
• 在兩者都返回匹配記錄之前，別當它做完了。有 DS 而無 DNSKEY 正是那個壞掉的狀態——立即修復或移除它。

常見錯誤

• **在金鑰存在之前就發布 DS。**最具破壞力的單一錯誤：在 DNS 提供商處簽名真正生效之前，就在註冊商處添加了 DS 記錄。這造成了已發布封印、缺失金鑰的狀態，使你的網域對會校驗 DNSSEC 的訪客無法解析。永遠先啟用簽名，再發布 DS。
• **換提供商後留下一條過時的 DS。**如果你遷移 DNS 提供商（或關閉簽名）卻忘了在註冊商處移除或更新舊的 DS 記錄，你就指向了一把不再存在的金鑰——同樣的壞結果。當你關閉或遷移 DNSSEC 時，在同一次改動中把註冊商處的 DS 一並更新。
• **做完第一步就停。**在 DNS 提供商處啟用簽名（建立了 DNSKEY），卻從未在註冊商處添加 DS。在 DNS 儀表板裡一切看上去都開著，但沒有 DS，防護永遠不啟動。你做了功，卻一點好處都沒拿到。
• **以為 HTTPS 或郵件認證已經涵蓋了它。**小鎖和郵件認證（SPF / DKIM / DMARC）很有價值，但解決的是不同的問題。它們都阻止不了一個偽造的 DNS 答覆一開始就把訪客送往錯誤的地方。
• **啟用後不監控。**金鑰會輪換，提供商會變更，記錄會被編輯。今天完美的設定，幾個月後可能悄悄壞掉。如果 DNSSEC 重要到值得啟用，就值得定期檢查它是否仍然有效。

它在你評分中的位置

這兩項檢查都計入你的 DNS 安全得分。DS 記錄檢查被當作兩者中優先級更高的那個：缺失的 DS 是一個真實的漏洞，被算作失敗。DNSKEY檢查確認信任鏈的其餘部分完好——只有當一條匹配的 DS和 DNSKEY 都存在時它才通過，並把那個危險的有 DS 無金鑰壞掉狀態標為高嚴重級。一個乾淨的 DNSSEC 乾脆還沒啟用結果，是許多企業常見的起點；從那裡走到一對完整、匹配的 DS + DNSKEY，是一次免費、被充分理解的升級，它提升你的 DNS 安全地位，並消除一條真實的冒充與攔截通道。

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

熱門服務商的分步指引：

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

常見問題