Locking down your GitHub-hosted Domains | Hacker News Reader

Locking down your GitHub-hosted Domains

aaron-gustafson.com

108 pointsrobin_reala15 comments

The short version: be careful when pointing wildcard domains at servers you don't control because this allows anyone to set up a subdomain for your domain on that server.

Or: learn the basics of DNS if you decide to own a domain. Don’t blindly follow random instructions online without understanding them. (I’m pretty sure GitHub official docs never recommended setting up a wildcard A record for Pages, so the author must have gotten it from someone who similarly don’t understand the basics of DNS.)

> After a lot of digging around, trying to figure out how the hijack was accomplished, it turns out it was via GitHub Pages.

This is not what responsible domain ownership looks like. It shouldn’t take a lot of digging around to find out why a subdomain of yours resolves.

Don't be so dismissive. Domains are cheap, and not everyone can be a professor of DNS wizardry. Not every project is important, playing around with tech is fun, and "digging around to find out" stuff is what makes a hacker in the first place.

When I was a kid, blog posts like this one helped me understand things.

This form of gatekeeping doesn’t make a lot of sense. DNS isn’t simple to understand, many very knowledgeable people still make mistakes with it. Expecting everyone to have a perfect understanding of DNS before they buy a domain is as unreasonable as not allowing someone to buy a car until they can assemble an engine.

A perfect understanding of DNS is like having a Ph.D. Not having to scramble and read random blog posts on the spot to figure out the DNS record you configured yourself that's causing a subdomain to resolve is like graduating primary school.

I hear, so assume I didn't graduate primary school, where would you suggest I start to avoid needing to google random blog posts on the spot?

> This is not what responsible domain ownership looks like. It shouldn’t take a lot of digging around to find out why a subdomain of yours resolves.

DNS is one of the most notoriously cumbersome systems around, even for advanced engineers. Most people spend very little time (less than 1 hour per year) dealing with it, which isn't not long or often enough to commit learning to long-term memory, and the opacity of the different layers, plus tiers of caching, make it difficult to diagnose and debug problems when they arise.

Even professional network engineers frequently trip over "basic" problems with DNS. It's a system with virtually zero guardrails and so many potential hazards that it's completely understandable for almost anyone to find themselves in these situation.

There's a reason this haiku is so famous:

> It’s not DNS

> There’s no way it’s DNS

> It was DNS

Some of the blame lies with GitHub. Github should have some kind of verification that you actually own the domain before letting you take it over that works even with a wildcard cname. Even if that is just checking that it actually a CNAME to the user or arganizations github.io page

Could you elaborate the problem a bit more?

Does this extend to any cloud provider?

For example if I have a domain pointed to Digital Ocean's servers and manage my records there, could this same issue happen if I have wildcard domains on DO?

> Does this extend to any cloud provider?

If it's a server on your DO account, then that counts as a server you control. They do recycle IPs eventually if you delete something but the solution there is to update your DNS.

So this article suggests not using a CNAME DNS entry and pointing your domain’s APEX entry at GitHub’s IP. You could also use an ALIAS record to point the ‘www’ part to GitHub too, though only a few DNS providers support ALIAS.

You can use CNAME record for a www domain, it's the apex entry that doesn't support CNAME usually. Netlify and Vercel both support ALIAS records and could be a decent free option if you need it.

ALIAS isn’t well supported because it isn't a real record. It’s a pseudo-record i.e. it’s not officially recognized by any RFC afaik. This could have subtle consequences in the situation you’re describing. It adds an extra external lookup to your request, decreasing performance[0].

[0] https://help.ns1.com/hc/en-us/articles/360020248973-About-CN...

> It’s a pseudo-record i.e. it’s not officially recognized by any RFC afaik.

It goes beyond that -- "ALIAS" isn't a DNS record at all; it does not exist as an entity within the DNS protocol. It's a directive used by some DNS servers (primarily at large providers) which causes the DNS server to synthesize A/AAAA records.

At first I saw their preferred method is an A record, but I used a CNAME, thank you very much.

Reply on news.ycombinator.com