通配符 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 的警报被发现的，警报通知作者有多个子域的新所有者已通过验证。经调查，作者发现这些子域在搜索结果中排名，甚至有时超过了合法站点。

我希望没有人受害于那些毫无疑问的劣质老虎机诈骗站点，这些站点托管在我的域名上。

这是一种经典的“子域接管”案例，攻击者利用悬挂的 DNS 记录或宽松的配置来托管恶意内容，损害域名声誉，并可能诱骗用户访问钓鱼或诈骗站点。

争论：谁该负责？

此事件在 Hacker News 引发了激烈讨论，观点在用户配置错误与平台缺乏防护之间分歧。

“用户错误”视角

多位评论者认为责任完全在域名所有者。将通配符记录指向第三方平台，从定义上讲，就是将任何未分配的子域的控制权交给该平台。

你让你的 NS 将任何请求转发到 GitHub——一个你并不拥有的平台。我认为这是预期的结果。

“平台责任”视角

另一些人认为 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 等工具可以提前发现未经授权的更改或新“所有者”声明你的子域。定期审计 DNS 记录和搜索引擎索引，可在造成重大损害之前识别接管行为。

最后思考

此事件凸显了现代网络基础设施中反复出现的主题：“易用性”与“默认安全”之间的鸿沟。虽然通配符 DNS 方便，但它会产生一个漏洞，任何拥有 GitHub 账户的人都可能利用。通过采用明确的验证并避免宽松的 DNS 记录，开发者可以保护其数字身份，防止成为下一波老虎机诈骗的托管平台。