Seems like GitHub could solve this by making users verify they own a domain name by adding a value to a txt record rather than just seeing the domain points to github and letting any repo use it.
I’ve set up two static pages with custom domains using GH Pages in the past couple of months, and both times I had to go digging in the docs before I found the verification page as part of trying to figure out why https wasn’t working. Fucking inexplicably poor UX design from GH. If I add a custom domain, just ask me to verify it.
Practically, it's not limited to GitHub Pages, though.
By the way, even while a custom domain is still pending verification, the GitHub Pages LB will route the request based on the Host header, allowing for the following:
Another fun trick: You can also use wildcard DNS services like nip.io/sslip.io for alias domains, such as `my-page.185.199.108.153.sslip.io`. (Not sure of any practical use cases, though.)
Something similar once happened to me with an old domain with nameservers I had pointed to DigitalOcean from my registrar.
Managing DNS through DigitalOcean (although, this should be possible with any DNS service) requires both pointing the nameservers to that service and adding the domain to your account. If you delete the domain from your account, like I had, but forget to update the nameservers with your registrar, anyone else can claim the domain. Theoretically, if you redirect the nameservers first and then add the domain to your account, someone could swipe it from you, I guess. Though it would basically have to be pure luck.
I would say probably 10 years, I remember reading about the CNAME github issue around 2015 or so, as before that most used to use jekyll with gh pages, was very popular among indie developers
Why is securely setting up custom domains for github pages so error prone? The `<user>.github.io` CNAME record already contains the username. So why can another user steal it?
edit: apparently CNAME can't be used for TLD+1, only for subdomains, so you have to use a more error prone approach for those.
reply