一條被改寫的 DNS 記錄，先動搖了網址列裡的鎖

2026 年 10 月 8 日，Google 在安全部落格發文，說明多個國家頂級域名遭到劫持。駭客修改了權威 DNS 記錄，並取得了未經授權的 HTTPS 憑證。受影響的後綴包含 .gh（加納）、.sl（塞拉利昂）與 .as（美屬薩摩亞）。Solidot 同日轉述了這則消息。

這則新聞裡最值得停下來看的一個細節，並非攻擊規模，而是攻擊發生的位置。它不在 Google 的伺服器裡，而在域名階層更上遊的註冊管理機構。也就是說，被改寫的是那條告訴瀏覽器「這個名字住在哪裡」的記錄。使用者端看到的畫面可以完全正常：網址列有鎖、有憑證、有正確拼寫的域名。信任的介面一項都沒少，只是底下的地址被換過了。

鎖頭圖示的前提，是一條沒人看的記錄

HTTPS 的鎖頭圖示是網頁信任體系裡最被廣泛理解的視覺符號。它的設計前提是：域名指向正確的主機，憑證由可信的 CA 簽發。這次事件把前提戳破了一半。攻擊者不需要偷憑證，只要能改 DNS 記錄，就能循正常程序向 CA 證明自己「擁有」那個域名，拿到一張完全合法的憑證。

Google 因此明確表示，不認為簽發憑證的 CA 機構有違規。這句話在設計上很有分量：整套憑證系統照著規則運作，規則本身被繞過了。信任被設計成分工的，域名歸註冊機構管，憑證歸 CA 管，瀏覽器只負責驗證兩者是否吻合。任何一環被上遊改寫，下遊的驗證畫面依然成立。

Google 的回應裡另一個可指認的動作，是 Chrome 迅速封鎖了受影響域名的相關憑證。這等於承認：當 DNS 層被動過手腳時，補救不能等系統自癒，必須由瀏覽器這一端直接把特定憑證從信任清單裡拿掉。這與我們先前觀察過的微軟改讀行為、不讀門牌的防禦轉向有相似的邏輯，當門牌本身不可靠，防線就得往行為與例外清單移動。

檢查方式本身就是一種介面設計

Google 給出的建議很具體：使用 .gh、.sl 或 .as 域名的機構，應檢查 Certificate Transparency（CT）日誌，找出意料之外的憑證。這個建議透露了整個體系真正的問責機制在哪裡。

CT 日誌是一份公開、可搜尋、逐筆記錄所有已簽發憑證的帳本。它平常對一般使用者是不可見的，但在這類事件裡，它成了唯一能回答「有沒有人替我的域名簽了我不知道的憑證」的地方。換句話說，系統的透明度被設計成事後可稽核，而非事前可攔截。你要自己去看帳本，系統不會主動告訴你。

這種設計取向有其取捨。事前攔截需要預先定義什麼算異常，而這次攻擊恰恰在每個環節都符合程序。事後稽核則把判讀責任交回域名持有者手上。對資源充足的大型機構，查 CT 日誌是例行工作；對掛在小國頂級域名下的中小單位，這個動作的成本與門檻顯然高得多。

小後綴的信任成本

三個受影響的後綴都屬於規模較小的國家頂級域名。這不是巧合能解釋的。頂級域名的註冊管理涉及各國的在地機構，營運資源與安全投資差異極大。熱門後綴被反覆審視、攻擊、加固；冷門後綴的註冊系統一旦防護薄弱，就成了整條信任鏈上最軟的一段。

從介面設計的角度看，這暴露了一個長期存在的落差：瀏覽器對所有域名顯示同一把鎖，但不同域名後方對應的治理強度並不相同。使用者無法從任何視覺線索分辨 google.com 與某個 .sl 域名背後，登記、變更、驗證程序的嚴謹程度差距。統一的符號掩蓋了不均勻的基礎設施。

Google 在文章裡強調自身系統未受影響，這點可信，因為被劫持的是國家頂級域名層，而非 Google 自家託管的 DNS。但對使用者而言，風險並沒有因為「Google 沒事」而消失。任何掛在這些後綴下的服務，其域名都可能被指向別處，配上合法憑證，構成幾乎無破綻的假冒畫面。

這次事件最終指向一個樸素的結論：網址列裡那把鎖，驗證的是「連線對象持有這個名字的憑證」，而不是「連線對象是你以為的那個人」。當名字本身的登記環節被改寫，最誠實的防禦是那份任何人都能查、但很少人真的去查的 CT 日誌。信任介面設計得再乾淨，也替代不了有人定期翻帳本這件事。