萬用 DNS 的危險：GitHub Pages 網站遭劫持

想象一下，從旅行歸來時發現您的專業域名正在托管幾個印尼線上賭博網站和老虎機詐騙。這正是開發者 rmeertens 所經歷的事情，他們發現自己的域名 immersivepoints.com 被第三方透過 GitHub Pages 濫用。

此事件在 DNS 配置與平台層級域名驗證的交叉點上，提供了一個關鍵案例研究，說明一種簡單的便利——萬用 DNS 記錄——如何開啟巨大的安全漏洞。

攻擊的解剖

作者使用 GitHub Pages 來托管一個 3D 與 VR 點雲視覺化工具。為了簡化設置，他們將 DNS 記錄設定為萬用 (*.immersivepoints.com) 指向 GitHub 的伺服器。其意圖是確保任何子域名（如 www）都能自動解析到他們的 GitHub Pages 網站。

然而，作者發現 GitHub Pages 處理自訂域名時存在一個根本性缺陷：只要有一個倉庫包含與該域名匹配的 CNAME 檔案，GitHub 就會解析指向其伺服器的任何域名。

由於作者設有萬用 DNS 記錄，對 immersivepoints.com 的 任何 子域名請求都會被路由到 GitHub。攻擊者只需建立一個私人 GitHub 倉庫，並為如 kafka.immersivepoints.com 或 hd.immersivepoints.com 的子域名添加一個 CNAME 檔案。GitHub 的負載平衡器會看到該請求，將其匹配到攻擊者的倉庫，並在作者的域名下提供攻擊者的內容。

影響：SEO 中毒與詐騙

該濫用透過 Google Search Console 警報被發現，通知作者各個子域名的新擁有者已經被驗證。經過調查，作者發現這些子域名在搜尋結果中獲得排名，有時甚至超越合法網站。

我希望沒有人會成為毫無疑問的低劣老虎機詐騙網站的受害者，這些網站被架設在我的域名上。

這是 "subdomain takeover" 的典型例子，攻擊者利用懸空的 DNS 記錄或寬鬆的配置來托管惡意內容，損害域名聲譽，並可能欺騙用戶訪問釣魚或詐騙網站。

辯論：誰應該負責？

此事件在 Hacker News 上引發了重大討論，觀點在使用者的配置錯誤和平台缺乏防護措施之間分歧。

"User Error" 觀點

多位評論者認為責任完全歸屬於域名擁有者。按定義，將萬用記錄指向第三方平台意味著將任何未分配的子域名控制權交給該平台。

您告訴您的 NS 將任何請求轉發到 GitHub，這是一個您不擁有的平台。我認為這是預期的結果。

"Platform Responsibility" 觀點

其他人認為 GitHub 應該實施更嚴格的驗證。如果使用者試圖聲稱一個已被另一個 GitHub 使用者使用的域名，或者該域名指向 GitHub 的 IP 但沒有已驗證的所有權記錄，平台應該阻止此關聯。

一個被提出的解決方案是強制使用 TXT 記錄進行域名驗證，這是 Google Search Console 和其他主要雲端服務提供者常用的做法，以確保請求者實際控制 DNS 設定。

如何防止域名劫持

為了避免成為此類濫用的受害者，開發者和網站擁有者應遵循以下最佳實踐：

1. 避免為第三方托管使用萬用 DNS

除非您有特定原因並了解風險，否則請不要使用萬用 (*) 記錄將您的域名指向如 GitHub Pages、Netlify 或 Vercel 等服務。請明確定義您打算使用的每個子域名（例如 www、blog、app）。

2. 使用域名驗證

GitHub 現在提供一項功能來驗證自訂域名。這允許您透過 DNS TXT 記錄證明您對域名的擁有權，防止其他 GitHub 使用者聲稱您的域名或其子域名。此設定位於帳戶設定而非個別倉庫設定，這可能使人容易忽視。

3. 監控您的域名

使用如 Google Search Console 之類的工具可以提供未經授權變更或新 "owners" 聲稱您的子域名的早期警訊。定期審核您的 DNS 記錄和搜尋引擎索引有助於在造成重大損害之前識別劫持。

最後思考

此事件凸顯了現代網路基礎設施的一個反覆主題：