域名成陌生人的游乐场：DNS 通配符和 GitHub Pages 的坑

你人在非洲，网不稳。结果突然收到 Google Search Console 的通知：有人在你的域名下建了个子域名。

这可不是吓唬人的故事。真实发生在一个做 3D 点云可视化项目的开发者身上。他用 GitHub Pages 搭静态站，结果离线期间，kafka.immersivepoints.com 就被别人悄无声息地占了，还在上面挂内容。他好几周后才发现。

方便第一，安全第二

GitHub Pages 确实好用。想搭作品集、文档或者项目展示，不用管服务器，直接配置 DNS 就行。

这位开发者当时图省事，设了个通配符记录（*.immersivepoints.com），把所有子域名都指向 GitHub 的 IP。看起来很干净，其实埋了雷。

他以为“域名是我买的，别人就建不了子域名”。结果 GitHub Pages 可不这么认。

GitHub 的漏洞：随便认领子域名

问题出在 GitHub 的处理方式上。只要 DNS 指向 GitHub 的服务器，GitHub 就会解析任何仓库里的 CNAME 文件，不管是谁建的。

别人只要在自己的仓库里写个 CNAME 指向 kafka.immersivepoints.com，GitHub 就直接把内容挂上去了。完全没有验证，也没通知你。

更麻烦的是，对方用的是私有仓库，你根本看不见，也没法举报。

通配符 DNS 带来的麻烦

这其实是个 DNS 配置问题。不光 GitHub 存在。只要用了通配符记录（*.yourdomain.com），相当于你把整个子域名空间都交给服务商去处理了。

再加上 GitHub 不验证域名归属，等于给别人开了个后门。任何人只要有 GitHub 账号，都可能占一个子域名。

这次被占的子域名最后挂了老虎机诈骗站点，严重影响域名信誉。

为什么没人发现

幸好开发者之前设置了 Google Search Console，才及时发现问题。否则这些诈骗站可能一直在他的域名下被搜索引擎收录。

这也提醒我们：监控不只是看流量，它也是安全工具。

GitHub 的半吊子解决办法

后来他发现 GitHub 确实有域名验证功能，但藏在账号设置里，而不是仓库设置里。大部分人根本不知道要验证。

GitHub 应该做得更好：

1. 在仓库设置里弹出明显警告，提醒域名没验证
2. 验证通过前，不允许 CNAME 文件生效
3. 增加验证步骤，比如要求添加 DNS TXT 记录

开发者把恶意仓库举报给 GitHub，但没收到回复。处理速度和透明度都差强人意。

如何保护自己

如果你用 GitHub Pages 挂自定义域名，建议按这个清单来做：

✓ 尽量避免用通配符 DNS。需要用子域名时，直接设具体的 A 记录或 CNAME 记录。

✓ 主动在 GitHub 账号设置里验证域名，而不是只在仓库里填。

✓ 用 DNS TXT 记录证明域名归属。增加攻击者难度。

✓ 开启域名监控，用 Google Search Console 或 Bing Webmaster Tools 之类工具。发现新页面就报警。

✓ 定期检查 GitHub Pages 配置。看哪些仓库有 CNAME 文件，确认是你的。

✓ 核心项目别只靠 GitHub Pages。生产环境最好用自建服务器或专业托管商。

总结经验

这次事件说明，配置 DNS 时不光要会设，还要懂它背后的风险。通配符记录像把整个子域名空间交给 GitHub 一把抓，方便归方便，但安全没保障。

同时也暴露了平台的问题——GitHub Pages 好用归好用，但安全提醒做得不够到位。验证功能藏得太深，最终害的是用户。

好消息是，预防起来并不难。只要 DNS 配置合理、域名验证到位，你就能安全地享受 GitHub Pages 的便利。

别忘了监控你的域名。