Hijacked DNS

I had domain1.tld and domain2.tld with Cloudflare from some years. Then I decided not to use them and deleted from CF console, but their phil/olga ns remained at my registrar.

Recently I decided to use them again, and found out that they resolve to some russian IP on adult sites, despite the fact that my root domains doesn’t contain any file, .htaccess clean.

An interrogation on 8.8.8.8 said that my domains have Cloudflare NS (dina/hugh), resolved to said russian IP.

Reentered now these domains in my CF console with my correct IP, and now they resolve ok.

However, how was that even possible? Can someone “steal” somebody else’s domains in that manner? How can this be prevented?

The domains were removed from the service but your registrar continued to advertise that Cloudflare was providing a service on your behalf.

Either the zones should be left on Cloudflare and entries removed for any unnecessary or unused service or the registrar should be updated to not point at a resource that was incorrect for the domains.

1 Like

Now, that seems logical and I should’ve done that.

However, how come the redirection to some adult sites and not, let’s say, CNN website? Who? How?

Someone has obviously seen your domain NS point to Cloudflare so added the domain themself to a new Cloudflare account and set up a redirect to the adult site. They would have chosen this instead of something else like CCN because they either want o promote the adult site (might be theirs) or it has ad/click revenue for them.

It’s a pretty common ‘scam’ and occurs in many forms - e.g. someone has a domain pointing to a Tumblr account and when deleting the setup they just delete the Tumblr account but leave the DNS for their old domain pointing to it. Some enterprising ne’er-do-well comes along and creates a new, normally dodgy, Tumblr page of the same name and viola, the ‘old’ site is back with new content because the DNS stll points to the Tumblr.

Upshot is that when deleting things it’s important to make sure you do it as ‘upstream’ as possible. So in your case, change your nameservers away from Cloudflare if you’re not using them. Or keep the Cloudflare account and remove all the DNS entries for it to just make it kind of ‘null’.

4 Likes

Thanks Saul for the explanation.
However: the hijacked DNS nameservers got from interrogating 8.8.8.8 were also from Cloudflare (the pair dina.ns.cloudflare.com / hugh.ns.cloudflare.com), DESPITE the fact that my registrar advertised the original pair (phil.ns.cloudflare.com / olga.ns.cloudflare.com)
How can one tell Google different NS than from the registrar? All worldwide servers from whatismydns.net were also returned the hijacked IP

On the other hand, I tried to hijack my own domain, by making a new account in Cloudflare, was fairly easy, and stuck on the step of changing the NS from the current phil/olga pair to some other pair. Which seems a fair amount of proof that I (the new account) might own the domain.

HOWEVER, the old domain holder in Cloudflare was not notified at all that someone else wants to get hold of the domain settings. Given the fact that CF informsme of any connection from a new IP, this seems a unexpected relaxed security from Cloudflare.

Anyways, the original hijacked DNS still puzzles me: how can Google’s resolver can advertise other Cloudflare DNS-es than the original DNSes at my (authoritative) registrar?

Thanks in advance for any clarification, hope that solves other situations, too.

I’m going to reply a bit out of order if that’s ok just because it makes more sense to me to reply this way than going through your reply one by one!

Firstly your main question. Although I’ve not tried for a while I know that when I messed with this in the past, any Cloudflare NS would reply with the records for any domain hosted at Cloudflare regardless of it’s defined authoritative servers. So I could be assigned alice and bob, say, but stick in chas and dave at my domain registrar and things would still hang together. To me, this is a pain but must be to do with the architecture or something. If there absolutely had to be a match of the nameservers defined at the domain registrar and the name servers assigned to the domain within the Cloudflare account it could stop this kind of situation. As I say, not sure if this is the case now but was a problem a few years back when I played with things. You’re spot on with that. Simply the fact that domain is in a Cloudflare account (dina/hugh) means phil/olga will reply so having them still in place at your registrar allowed any CF account to add your domain and own the DNS entries from whatever nameservers they had assigned.

As to why you weren’t notified when the other guy added your domain I guess if you’d deleted the domain it wasn’t tied to your account so logically why would it notify you? I’d be more surprised if you did get a notificaiton seeing as CLoudflare would not have that domain tied to any account once you deleted it.

I am surprised you could re-add the domain yourself whilst the hijacker had it added to his account though. Maybe the behind-the-scenes is now wise enough to know you have the nameservers matching on both sides so you get precedence. That’s a good thing in fixing the issue I referred to in the paragraph above I guess. Are you sure the other guy didn’t get a notification you’d now taken the domain into your account? And do you now really have it wrestled to yourself completely?

Thanks Saul for your answer!

That makes sense :slight_smile:

True also, I suppose this is beyond their care of things.

I do not necessarily see this wrong (there might be some use cases), anyways I didn’t wanted to finish the hijacking (Cloudflare still waits to change NS to another pair), so I do not know if it’s working till the end. The real issue here is why I wasn’t notified on the old account that someone tries to get my domains. This is a good thing to do, similar to any security precautions any registrar takes when changing any information.

Anyways, I did secured DNS entries at my registrar with DNSSEC, hope this will solve future similar problems.

DNSSEC will solve this, for sure. Just be aware many resolvers don’t yet use it!

To anybody encountering DNS hijacking when leaving Cloudflare orphaned NS in your registrar records, pt. 4 in Quick Fix Ideas describes exactly what happened: Community Tip - Best Practices to Address DNS Hijacking

2 Likes

Is there a DNS forwarding for (phil/olga) to (dina/hugh) for example.com so Google returns the latter as NS?

Number 4 (cannot post feedback on tip as it is closed) says if a domain points to CF then any user can claim it while when someone claims a domain CF asks to set NS servers to those provided as an authentication process:

For a while I assumed hijacking was made through brute-force by tying to add/delete the domain multiple time to get the same NS as it is in registrar to pass the authentication but according to your data that step is bypassed.

No, as discovered after my OP, I left phil/olga at my registrar DNS, but deleted domains from Cloudflare, which allowed somebody else to claim my domains in Cloudflare. As said by Saul, all CF NSs are returning whatever is in CF.

However, I still do not understand how Google returned the hijacked DNSes, since CF probably requested, when adding the domains, to either:

  • change my registrar DNS NSs - that did not happen
  • keep the existing NSs - but Google returned different NSs

That seems to be an DNS man-in-the-middle hijacking, I will investigate further.

Yes, I stopped at the final step, just curious why I was not notified (as previous owner of domains). Still think I should have been notified.

If it is the MITM then it should be very limited and affects a few people and not a CF issue. Among all domain hijacking complains I know here, never the owner revealed the domain address, and your investigation shed light on some parts.

That part meant to be a secure way of authenticating the domain owner. It is not acceptable if a domain points to some CF name-servers, even without NS records in place, it could be taken by whom claims it first.
With domain name, server IP and NS records (dina/hugh) CF can investigate which account created the A record and checking logs may lead to how it was possible to bypass the authentication mechanism.
If CF is convinced someone is the domain owner (setting registrar NS records to a highly random combination of provided names in a short period), then notifying someone else who passed the authentication for the same domain before, of NS record changes is meaningless (maybe domain is transferred), so the real issue is how without changing registrar NS records, the authentication is passed.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.