When Your Domain Becomes a Sandbox for Strangers: DNS Wildcards and GitHub Pages Gone Wrong

You're traveling through Africa with spotty internet. Life is good. Then your inbox delivers a surprise: Google Search Console is alerting you that someone else now "owns" a subdomain on your domain.

Panic sets in.

This isn't a hypothetical scenario—it's exactly what happened to one developer running a static site for a 3D point cloud visualizer on GitHub Pages. While they were offline, someone had quietly hijacked kafka.immersivepoints.com and was hosting content on their domain. They didn't even know until weeks later.

The Setup: Convenience Over Security

GitHub Pages is fantastic. It's one of the best ways to host static sites, portfolios, documentation, and project showcases without touching server administration. You configure DNS records, point them to GitHub's servers, and boom—your site is live.

This developer did exactly that. They set up a wildcard DNS record (*.immersivepoints.com) pointing to GitHub's IP addresses. Simple. Elegant. Vulnerable.

The assumption was reasonable: "Only I can create subdomains because only I own the domain."

Turns out, that's not how GitHub Pages works.

The Vulnerability: GitHub's Lenient CNAME Resolution

Here's the problem that nobody tells you about: GitHub will serve content for any CNAME file in any repository, as long as the DNS records point to GitHub's servers. There's no ownership verification at the repository level.

So when another GitHub user created a repository with a CNAME file pointing to kafka.immersivepoints.com, GitHub happily served their content from that subdomain. No verification. No notification. No permission slip required.

Even worse? They did it from a private repository, so there was no way for the domain owner to discover and report it directly.

The Real Problem: Wildcard DNS Without Verification

This is a classic DNS configuration issue that extends beyond GitHub Pages. When you use a wildcard record like *.yourdomain.com, you're essentially saying, "Route everything under this domain to this service." It's efficient, but it removes granular control.

Combined with GitHub's approach of accepting any CNAME file without domain ownership verification, you've created a perfect storm. Anyone with a GitHub account can potentially claim a subdomain under your wildcard DNS record.

In this case, malicious actors didn't waste the opportunity. The hijacked subdomain was hosting slot machine scam sites—the kind of garbage that makes your domain reputation tank with search engines.

Why Nobody Noticed (Until Now)

The developer was saved by one thing: they'd set up Google Search Console. That's the only reason they discovered the abuse. Without it, the scam sites could have been merrily indexing under their domain indefinitely.

This highlights a critical lesson: monitoring is a security tool, not just a performance metric.

The Aftermath: GitHub's Half-Solution

After digging deeper, the developer discovered GitHub does have a domain verification feature—but it's buried in account settings, not repository settings. Few users find it or understand they need it.

This is a UX problem. GitHub should:

1. Show aggressive warnings in repository settings when a custom domain isn't verified
2. Require domain verification before allowing CNAME files to be served
3. Implement a challenge mechanism (like DNS TXT records) to confirm ownership

The developer reported the malicious repositories to GitHub but received no confirmation. The response time and transparency here is... lacking.

How to Protect Yourself

If you're using GitHub Pages with a custom domain, here's your checklist:

✓ Avoid wildcard DNS records unless absolutely necessary. Use specific A records or CNAME records for the exact subdomains you need.

✓ Verify your domain through GitHub's account settings, not just the repository settings.

✓ Use DNS TXT records to prove ownership. This adds friction for attackers.

✓ Monitor your domain with Google Search Console, Bing Webmaster Tools, or similar services. Set up alerts for new pages indexed under your domain.

✓ Regularly audit your GitHub Pages configuration. Check which repositories have CNAME files and verify they're legitimate.

✓ Consider not using GitHub Pages for production critical projects that require strict domain control. Self-hosting or using a dedicated hosting provider gives you more security options.

The Broader Lesson

This incident illustrates why developers need to understand their DNS configuration—not just how to set it up, but why it matters. A wildcard DNS record is like giving GitHub a master key to your entire subdomain structure. It's convenient until it isn't.

It also shows why platform companies need better security defaults. GitHub Pages is fantastic, but feature discoverability and security warnings need improvement. Burying domain verification in account settings rather than making it front-and-center in the repository setup flow is a UX failure with real consequences.

The good news? This is all preventable. With proper DNS configuration and domain verification, your GitHub Pages projects can stay secure while maintaining the simplicity that makes them great.

Just don't forget to set up monitoring.

Have you experienced domain hijacking or subdomain abuse? Share your story in the comments—and double-check your DNS records while you're at it. Your future self will thank you.