[01acheru]

A tangential issue related to this since Github is involved: Github pages.

If you point a DNS entry to a Github page and then delete the page without deleting the entry on you DNS table someone can create a new page with the same name and hijack your DNS entry for malicious purposes.

I've written to Github already about this, if they want to let you point your DNS to the page they should give you a unique entry to point to, so that if it is recreated in the future your entry will not point to the new page. Not asking you to point to the public page name that can be taken over.

They never replied...

[arccy]

at least they allow you to verify and restrict who can do this now https://docs.github.com/en/pages/configuring-a-custom-domain...

[01acheru]

It is good they finally worked this out, it's been years I wrote them about this (and many many others did the same, I was not the first nor the last to warn them).

I just don't understand why taking so long to fix this, and why they fixed it in such a complicated fashion when it's a really basic use case with a simple and straightforward solution that adds no burden to the end user.

[batch12]

I have found a similar issue affecting thousands of root domains on another service. They still sit there, ripe for the taking.

[pbalau]

If you point a dns entry to an ip and later someone takes control of that ip, guess what happens... This is a YOU problem, not a GitHub problem. Talking about dilettantes in the tech world...

[jffry]

Yes, and what the parent post was suggesting was that GitHub would have you use a CNAME to point your DNS entry to a unique FQDN (that it can tie back to your specific repo) instead of an IP, which would centrally prevent this issue without relying upon every single user to act perfectly.

[bombcar]

A CNAME like the ones AWS load balancers give you would also give GitHub the flexibility to change IPs as necessary.

[RKearney]

They would need a unique IP for every single repo. While this isn't a problem for IPv6, it is completely unrealistic for IPv4.

When github.example.com is configured as a CNAME to my-gh-page.my-repo.github.com, the IP that is returned will have no idea that it's my-gh-page.my-repo.github.com that is being requested as github.example.com will be what is sent in the Host header and part of the TLS SNI.

EDIT: I misunderstood what OP was suggesting. Pointing a CNAME to a repo specific domain name would work only if that name is removed after the repo goes away. As previously mentioned, this should not be Github's responsibility and it is a domain owners responsibility to properly maintain their records.

[01acheru]

> They would need a unique IP for every single repo

I don't think this is true. If your CNAME myghpage.example.com points to <somerandomstuff>.github.com which then routes you appropriately, all Github has to do is remove that <somerandomstuff> subdomain when you delete the page and that's it, myghpage.example.com will fail to resolve and you're safe.

This would work even if Github only had a single public IP address.

edit: The issue with Github pages is that they make you point your CNAME to something.github.io not something.youraccount.github.io, so anyone can recreate something.github.io after you delete it. If they simply created the pages as something.youraccount.github.io you would be safer, unless you lose your account name. That's why the random subdomain is preferable.

[loo]

That's not the case. Generate a unique ID on activation. Ask us to CNAME => <unique-id>.pages.github.tld. Drop the record when page is deactivated. Sorted.

[01acheru]

Did someone pee in your coffee?

All actors should take care of security, you should expect people to make mistakes especially if you're as big as Github. Your take on security is like talking about law and justice with a cowboy.

[cutemonster]

Nevertheless, I wonder, couldn't this be made more secure, by requiring those who publish the page HTML, to sign sth with a private key that [those who control the DNS record prove is their key]? So they prove that they have the same private key