I did the same to Shopify about 12 months ago or less and their response was , first please remove the takeover from your panel and then second we are aware but wont fix.<p>It is absolutely bewildering that they wouldn't take this seriously. The owner of my takeover tried to add the domain to their panel and they couldn't. This adds a whole new level of customer service to their backlog which should essentially be mitigated by an automation of sorts via a txt record or cname confirmation. Seems to me that they are more interested in not fixing it but happy to waste hours of their agents trying to fix such takover problems.
I did similar on 123 Reg a few years ago to rescue a client.<p>Their ex IT guy had half transferred their domain from namecheap to 123, changing the IPS tags to 123 but not accepting from 123's end. Then he got fired. The NS's were still pointing to Namechearp so everything continued to work, until the domain expired because neither company felt able to renew it, both referring me to nominet to resolve. Meanwhile the client was hard down.<p>After retiring to the bathroom to have a think I realised that 123 didn't really care who accepted the domain as long as the tags were right. So I created a new account, initiated a transfer and went through the steps, and the domain popped into my account, able to be renewed.<p>I did wonder if there would be a way to mass import domains that people hadn't accepted into their accounts yet but didn't actually try anything.
The article says that Route 53 uses randomly generated name server names, so if at your registrar you are pointing your domain to Route 53 name servers, and then you remove the records for your domain at Route 53 but leave the record at your registrar pointing to Route 53, it is unlikely that another Route 53 customer could add your domain and get your traffic. Their randomly generated Route 53 name server names would probably not match yours.<p>I wonder how effective that actually is? As far as I know there is nothing in the DNS protocol like the "Host" header of HTTP that allows the name server to tell what name the client knows the name server by. Two differently named name servers will actually be distinct only if they have different IP addresses.<p>The question then is how many IP addresses does Route 53 have for name servers?<p>Ideally, you'd want to have a separate IP address for each customer's name server. Do any of the big hosting companies do that?<p>I'd expect that they could do it without needing a lot of extra IP addresses by giving each customer who has a static IP address for the hosts an option to have traffic to port 53 of that IP address transparently sent to the hosting provider's name servers along with tagging to let the name servers identify what IP address it was for so it can serve the right name data.<p>That would allow each customer to have as many apparently dedicated name servers as they have hosts with static IP addresses.
Maybe I'm missing something here, but isn't this only a problem if you migrate your domain DNS away from DO and forget to also change the nameserver with your registrar?<p>So of course, if you tell the world "These guys over there are responsible for resolving my domains" you shouldn't be surprised if they actually do this.
Discussion from 4 years ago: <a href="https://news.ycombinator.com/item?id=12364297" rel="nofollow">https://news.ycombinator.com/item?id=12364297</a>
GitHub pages has the exact same issue right?<p>Nobody seems to complain at that... If I point my domain at GitHub, but then don't complete the setup process in the GitHub UI, I can't really complain if someone else sets it up...
This was posted in 2016, but their process hasn't changed. I'm not sure if it's actually caused any real damage yet (usually you'd add your domain fairly quickly), but it seems crazy that in between declaring DO as your DNS provider and importing the domain on DO, it can be stolen.
DigitalOcean have a HackerOne programme which... is a much better way of getting an issue like this flagged in a reasonable manner. I'm not surprised the account got banned. <a href="https://hackerone.com/digitalocean" rel="nofollow">https://hackerone.com/digitalocean</a>
Clearly this an issue, and clearly AWS has at least mitigated it. How hard is it for other probiders to do the same?<p>If they’re not doing it, I suppose they feel that the reputation hit they take if someone misuses it is better than the lost dollars from a little bit more friction during setup.
2016! why post this?<p>lots of previous discussion: <a href="https://news.ycombinator.com/item?id=12364297" rel="nofollow">https://news.ycombinator.com/item?id=12364297</a>
I don't think there are any solutions to this on a technical level. There's no way for you to prove that you own the domain, besides setting the NS-records.<p>You can partially mitigate the issue the way Amazon does it. But even that isn't foolproof and I suspect they have other reasons than just this for their approach.