多數人以為，只要網址列打的是自己熟悉的那串英文字母，連上去的就一定是本尊網站。這個假設，其實在 DNS 這一層隨時可能被推翻。你的電腦問「這個網域該連去哪個 IP」，DNS 負責回答，但這段問答本身沒有天生的驗證機制，答案在半路被人掉包，網址列上照樣是你熟悉的那串網址，畫面照樣正常顯示；攻擊者若再設法取得該網域的有效憑證，連鎖頭都不會示警，帳號密碼就這樣打進那個假登入頁。
DNSSEC（DNS Security Extensions，域名系統安全擴充）要處理的正是這個破口。它不是幫網站內容加密，而是替 DNS 的每一段回應加上數位簽章，讓你的電腦能反過來驗證「這份回應真的來自該網域的權威主機，而且沒被動過手腳」。少了這一層，DNS 查詢有多容易被冒充，網域就有多容易在使用者毫無察覺的情況下被導向別處，輕則內容被置換，重則變成一個真偽難辨的釣魚頁面。
DNSSEC 是什麼？
DNSSEC 全名 DNS Security Extensions，中文常譯為域名系統安全擴充。它的核心手法很單純，用公開金鑰加密的方式，替 DNS 資料加上數位簽章，讓解析端可以驗證收到的回應真的出自該網域的權威主機，而且傳輸途中沒有被竄改。ICANN（網際網路名稱與數字位址分配機構）在說明頁中指出，DNSSEC 是透過以公鑰密碼學為基礎的數位簽章，強化 DNS 的身分認證。
先釐清一點，DNSSEC 處理的是「DNS 回應可不可信」這個問題，跟網站本身安不安全是兩回事。IETF（網際網路工程任務組）在 2023 年發布的 RFC 9364，是把 DNSSEC 核心規格 RFC 4033、4034、4035 整理成一份彙整文件、並列為最佳現行實務（BCP 237）的正式文件。這份文件明確把 DNSSEC 定位成提供「DNS 資料的來源驗證」，也就是確認這份回應真的來自它該來自的地方，而不是替內容加密，也不是替網站本身做資安健檢。
台灣電腦網路危機處理暨協調中心（TWCERT/CC）給過一個好懂的比喻，可以把它想成寄送機密信件時，額外附上一個上了鎖的盒子，收件人打開後不只看得到信件內容，還能驗證這封信確實來自寄件人，而且沒有人半路拆開動過手腳。TWCERT/CC 也指出，DNSSEC 額外確保的是三項資安特性：資料沒有被竄改（資料完整性）、回應確實來自該網域的權威主機（來源可驗證性），以及能夠證明「這個網址真的不存在」而不是被偽造的查無此網域回應（可驗證之不存在性），這項特性要靠 NSEC 紀錄來實現。
DNS 原始查詢缺乏驗證，才是網域被偽造導向的根本破口
DNS 從設計之初就沒有內建身分驗證機制。ICANN 的說明寫得很直白，解析器收到一筆回應時，能做的檢查只有「這筆回應看起來是不是從原本該來的那個 IP 位址送來的」，除此之外沒有其他方法確認對方的真實身分。只要攻擊者能搶在合法回應之前，送出一筆看起來來源正確的假回應，解析器就有可能照單全收，並把這筆錯誤資訊寫進快取，這個過程就是 ICANN 所說的快取污染。
這個弱點在 2008 年被資安研究員 Dan Kaminsky 公開揭露，編號 CVE-2008-1447，業界俗稱 Kaminsky bug。問題出在 DNS 用來配對問答的交易 ID 只有 16 位元，也就是約 6 萬 5,000 種可能，而當時許多實作的來源連接埠又相當容易預測，幾乎沒替攻擊者增加猜測難度，美國國家標準暨技術研究院（NIST）的漏洞資料庫也把成因歸在交易 ID 與來源連接埠的隨機性不足。攻擊者只要在合法權威主機的回應抵達前，搶先送出大量猜測組合，就有機會命中並讓解析器接受偽造結果，之後所有查詢該網域的使用者都會被導向攻擊者指定的位址。Cloudflare 的技術文件談 DNS 快取污染時，也把 Kaminsky attack 舉為知名案例。
這個發現在當時讓業界緊張了一陣子。卡內基美隆大學 CERT/CC 的漏洞公告建議的短期應急做法，是讓每一次查詢都隨機挑選來源連接埠，讓攻擊者更難猜中組合，但公告也說明這類緩解措施無法完全杜絕快取污染，只是拉高了攻擊門檻，沒有真正解決 DNS 回應無法驗證來源這個根本問題。真正的長期解方，是靠數位簽章從架構層面補上這道驗證，也就是 DNSSEC。
DNSKEY、RRSIG 與 DS 紀錄各自扮演的角色
DNSSEC 的簽章具體出現在哪幾種 DNS 紀錄裡，知道這幾個名詞，之後看到自己網域的 DNS 設定才認得出來。Microsoft 的技術文件把這幾種紀錄類型整理得很清楚：RRSIG（資源記錄簽章）是區域簽署時，針對每一筆既有紀錄額外產生的一筆數位簽名；DNSKEY 存放用來驗證這些簽章的公開金鑰，又分成負責簽署一般紀錄的區域簽署金鑰（ZSK），以及負責簽署 DNSKEY 本身、權限層級更高的金鑰簽署金鑰（KSK）。
DS（委派簽署者）紀錄則負責把信任關係往上一層傳遞，它放在父區域（例如網域的註冊管理機構那一層），用來證明子區域（也就是你的網域）的公鑰確實可信。這筆紀錄通常不是設定完 DNSSEC 就自動生效，還需要手動，或透過代管服務商，把它送到上一層才算完成整條驗證鏈。
另外還有 NSEC 與它的改良版 NSEC3，專門處理「查無此網域」這種否定回應的驗證問題。TWCERT/CC 解釋得很具體，如果沒有額外的驗證機制，DNS 遇到不存在的網址時只會單純回覆「不存在」，這類否定回應本身沒有簽章可以核對，攻擊者其實可以偽造一筆「查無此網域」的假回應來誤導使用者。NSEC 的做法是把同一網域底下所有子網域按順序排好，查詢時回傳目標前後各一筆真實存在的紀錄當證據，讓解析端能夠確認這個網域真的不存在，而不是被人半路攔截、偽造成不存在。
信任鏈從根伺服器一路驗證到你的網域
光是自己的網域簽好名還不夠。如果攻擊者能同時偽造整組簽章和公鑰，一樣能騙過驗證，真正讓 DNSSEC 站得住腳的，是一條從你的網域一路往上追溯到全球 DNS 根伺服器的信任鏈。
運作方式是，網域擁有者用自己的私鑰替 DNS 資料簽章，對應的公鑰則公開發布供外界驗證；接著，這把公鑰再由它的上層區域（例如 .tw 或 .com）簽署確認，一層一層往上，直到追到全球共同信任的根伺服器為止。ICANN 把這個機制稱為信任鏈，Cloudflare 的技術文件也用同一套邏輯說明，DNSSEC 透過建立一路連到根 DNS 伺服器的信任鏈，確保使用者請求的 DNS 紀錄在傳輸途中沒有被竄改。換句話說，驗證的不只是這份簽章對不對，還包括簽這份簽章的人，有沒有被更上層的人認證過，一路查到底才能真正排除冒名的可能。
DNSSEC 能擋下快取污染、中間人攻擊與網域挾持三種手法
DNSSEC 真正擋得住的，主要是三類攻擊手法，每一種都對應著攻擊者原本想幹嘛，以及 DNSSEC 怎麼讓這招失效。
第一種是快取污染，也就是前面 Kaminsky bug 那類攻擊的延伸應用，攻擊者搶在合法回應之前，塞一筆偽造的 DNS 紀錄進解析器的快取，讓後續所有查詢這個網域的人都被導去錯的位址。啟用 DNSSEC 之後，解析器在接受任何一筆回應前，都會先核對上面的數位簽章，簽章對不上就直接丟棄，偽造的紀錄再也沒有機會被寫進快取。
第二種是中間人攻擊，攻擊者攔截並竄改傳輸途中的 DNS 回應，讓原本正確的查詢結果在半路被掉包。Cloudflare 的技術文件說得很明白，DNSSEC 讓解析器能夠確認這份資訊確實來自該網域的權威名稱伺服器，而不是來自半路攔截的中間人攻擊者。因為簽章綁定的是原始內容本身，任何竄改都會讓簽章驗證失敗，中間人就算攔得到封包，也無法在不被發現的前提下動手腳。
第三種是網域挾持與嫁接（DNS Hijacking／Pharming），也就是在使用者毫不知情的情況下，把整個連線導向攻擊者控制的伺服器。Cloudflare 指出，這類攻擊常被拿來做釣魚網站、置入未經同意的廣告、監控網路流量，甚至封鎖使用者存取特定網域。Microsoft 的技術文件也補充，啟用 DNSSEC 後的 DNS 通訊協定，明顯比較不會受到這類刻意偽造回應的攻擊影響，尤其是 DNS 詐騙攻擊（DNS spoofing）這個類別。
DNSSEC 保護的是解析過程，加密傳輸仍要靠 HTTPS 負責
一個常見的誤解，是只要網站有 HTTPS 鎖頭，就等於全面安全無虞；另一個相反方向的誤解，則是以為裝了 DNSSEC，連線的內容也會跟著被加密。兩者其實各自守著不同的層級，缺一不可。
ICANN 在《DNSSEC Deployment Guidebook for ccTLDs》這份部署指南裡講得很直接，DNSSEC 不會加密任何 DNS 訊息資料，因此不提供機密性；但它替 DNS 加上了資料來源驗證、資料完整性、驗證能力，以及可驗證之不存在性這幾項能力。也就是說，DNSSEC 能證明你查到的這筆網址對應資訊確實沒被動過手腳，卻不會替這段查詢過程本身遮起來，任何人只要在旁監聽，理論上照樣看得到你查了哪個網域。
要補上這段隱私缺口，得靠另一組協定，也就是 DNS over HTTPS（DoH）或 DNS over TLS（DoT），把查詢與回應的內容整段加密，讓第三方連你在查什麼都看不到。Cloudflare 的技術文件把這個分野講得很清楚，DNSSEC 的用途是驗證權威主機的身分、防範快取污染這類攻擊，本身不加密通訊；DoT、DoH 則會把 DNS 查詢加密。換句話說，DNSSEC 與 HTTPS（或 DoH／DoT）是兩層不同的信任機制，一個負責驗證資料沒被竄改，一個負責確保內容不會被看光，同時具備才算把這段路徑守住，只裝一種都還留著缺口。
DNSSEC 防不到的風險，相似網域偽裝和內容詐騙仍需另外因應
延續上一節「有邊界」的態度，DNSSEC 也不是萬用防護罩。它驗證的，是你查詢的這個網域名稱本身的回應有沒有被竄改，並不會去判斷這個網域是不是山寨、拼字很像的假冒網域，更不會替網站內容把關。
舉例來說，如果攻擊者刻意註冊一個長得很像的網域，像是把字母 o 換成數字 0，或是在品牌名稱中間多插一個不容易察覺的字，並且這個假網域自己也乖乖設定好 DNSSEC，驗證照樣會通過。因為對 DNSSEC 而言，那真的就是該網域自己發出的合法回應，協定本身沒有立場去判斷這個網域是不是刻意用來欺騙人。這不是 DNSSEC 的漏洞，而是它在設計上就只負責這一層，不涉及內容判讀或品牌辨識。
也因為這樣，DNSSEC 該被理解成資安基礎建設裡的一塊拼圖，而不是裝了就能一勞永逸的保險箱。核對網址拼字有沒有細微差異、留意瀏覽器顯示的憑證資訊是不是真的對應你要去的那個網站，這些使用者自己該養成的習慣，DNSSEC 沒辦法幫忙代勞，也仍然值得當成日常動作維持下去。
DNSSEC 普及率仍偏低，TWNIC 改為代管服務預設啟用
DNSSEC 從 2005 年規格公布到現在已經超過二十年，但不論從全球還是台灣來看，實際導入的比例都還處在偏低的水準。APNIC（亞太網路資訊中心，負責亞太區域網路號碼分配的機構）部落格在 2026 年 2 月刊出的文章指出，就算這幾年相關工具已經大幅改善，全球 DNSSEC 的驗證率與安全委派率，在 2025 年也僅分別成長到 36% 與 7%，二十年來的成長速度依然緩慢；文中特別點出，.com 這類通用頂級網域要導入 DNSSEC 自動化，必須先經 ICANN 核可，而依 Verisign 發布的《Domain Name Industry Brief》季報，光是 .com 截至 2025 年 9 月底就有 1.59 億筆註冊，約占全球網域總數 3.785 億筆的 42%，這麼大一塊遲遲無法跟上，全球整體的普及率就很難拉高。
IETF 在 RFC 9364 裡的說法更直白，DNSSEC 規格公布超過 15 年後，至今仍未被廣泛部署，近期估計顯示，用於網站的網域名稱中，簽署比例不到 10%，遞迴解析器收到的查詢裡，也只有大約三分之一會真的被驗證。這份文件同時強調，低部署率不影響 DNSSEC 作為最佳現行實務的地位，只反映出導入 DNSSEC 的價值，常被認為低於它的成本。
在台灣，負責 .tw 與 .台灣網域註冊管理的財團法人台灣網路資訊中心（TWNIC）則是先從技術面主動推一把。TWNIC 公告，自 2026 年 2 月 2 日起，凡是使用該中心 DNS 代管服務的網域名稱，一律預設開啟 DNSSEC 功能，系統會在生效當天自動配置好金鑰，申請人不需要額外操作就能取得這層保護；如果因為特定網路架構或測試需求不想啟用，也可以隨時登入系統自行關閉。這項調整的用意，是把要不要啟用 DNSSEC，從使用者得自己想到、自己動手設定，改成預設就打開、真的不需要才關掉，等於直接降低了整個門檻。
確認網域是否啟用 DNSSEC 的兩種查核方式
知道 DNSSEC 在防什麼、邊界在哪裡之後，下一步很實際，就是怎麼知道自己的網域有沒有開。這裡分兩種管道，一種給一般讀者，一種給想看技術細節的讀者。
對台灣讀者來說，最直接的管道是 TWNIC 提供的免費網站健檢服務。這套線上工具輸入網域名稱後，就能一次檢測包括 DNSSEC 在內、逾 25 項安全指標，同時涵蓋 HTTPS、IPv6、RPKI、Registry Lock（網域安全鎖）等項目，作為 .tw 與 .台灣網域註冊管理機構自己提供的服務，算是台灣讀者最權威、也最不用懂技術細節就能上手的檢測方式。
如果你的背景比較技術、想看得更細，可以改用 Verisign（負責 .com 與 .net 網域註冊管理的公司）提供的 DNSSEC Debugger。這套工具會針對任一網域，逐一檢查 DNSKEY、DS、RRSIG 這幾種紀錄是不是齊全、信任鏈有沒有在某一層斷掉，比較適合想確認問題卡在哪一段的讀者。Cloudflare 的技術文件也把第三方工具 DNSViz 列為推薦的檢測工具，啟用 DNSSEC 之後可以拿它另外驗證一次，確認設定確實生效。
更進一步，也可以直接用指令查詢。在終端機執行以下指令，可以看到該網域的 DNSKEY 紀錄，以及回應裡有沒有帶 RRSIG：
dig +dnssec <網域> DNSKEYCode language: Bash (bash)如果這個網域已經正確啟用 DNSSEC，而且你使用的遞迴解析器有做 DNSSEC 驗證，回應裡會看到 AD（Authenticated Data，已驗證資料）這個旗標；依 IETF 的 RFC 4035 與 RFC 6840，解析器只有在認定回應裡的紀錄都通過驗證時才會設上這個旗標。
檢查結果如果是沒開，下一步該找的是網域的登錄商，或者現在實際負責 DNS 代管的服務商，不少業者已經把這項功能做成後台的一個開關。如果登錄商和 DNS 代管是同一家，開完多半就完成了；兩邊分屬不同業者時，還要把代管商產生的 DS 紀錄填到登錄商那邊送往上一層，Cloudflare 的設定說明也是這樣的兩段式流程，信任鏈要等 DS 紀錄發布後才會接上。至於逐欄位的實際設定步驟，會依代管商後台介面而有落差，實際操作時對照當下畫面上的選項名稱即可。
網址列打得再仔細，也擋不住 DNS 這一層被動過手腳。這也是 DNSSEC 存在的理由——它不負責讓內容變得更好看，只負責確保你收到的每一筆查詢結果，真的來自它該來自的地方。它防不了看起來很像的山寨網域，也不會替網站內容把關，但少了這一層，連網址對不對這件事本身都無法被驗證。
從全球統計來看，實際啟用的比例還有相當大的進步空間，這也代表現在檢查一次自己的網域，多半還能搶在多數人前面把這道防線補上。花幾分鐘跑一次檢測工具，看看結果，剩下的交給你的網域代管商就好。