Hijacking Traffic with DNS

Hello Everyone
I have a weird problem and I hope you guys can help. We have recently decided to migrate a high-traffic website (setare.com) from an old CMS and old server to a fresh WordPress install on AWS. The Migration went well but after updating the domain DNS and changing the name servers to Cloudflare, we still see that the old website gets a good portion of the traffic. (We have Google Analytics installed on both old and new website)

I checked ns lookup for the domain and seems like the old DNS Server sets a TTL expire of 28 days which is amazingly very long. It has been almost 2 weeks from the migration and we still see 30-40% of the traffic goes to the old server, and unfortunately, the old Server management do not participate to fix the problem.

I tried purging cache from top DNS Servers providers but seems like some local DNS servers in Iran still won’t update the DNS and still route traffic to the old server. This caused a huge loss of traffic as Google also sinking un in the keyword ranking (I assume due to the inconsistency in the traffic). Other Performance and SEO factors are the same and everything else is better in the new CMS.

Can you please show us a way to resolve the DNS servers, or at least make sure that after expiring the TTL this would work normally? Is it possible that they Hijack our traffic for good and we can’t access the traffic?

I appreciate all the notes and leads in advance.

Will always be like that until propper DNS propagation (usually up to 24 hours).
Until that is done, some visitors will still land to your “old server”, that is why you could still see some traffic hitting your “old server”.

I have checked and your Website resolves fine and correctly over Cloudflare:

Before switching the DNS, it is a good way to lower TTL for records - for example to 5 minutes (TTL 300 - seconds).

Moreover, domain is pointed to Cloudflare nameservers, but there is some issue with a CNAME record for your MX (e-mail) which you obviously have at Cloudflare DNS?

Kindly, re-check your MX record and your A (or CNAME) for your mail and re-add them as follows here to me sure your e-mail would continue to work propperly:

1 Like

There’s not much you can do to override a long TTL. My local ISP looked up your domain and got a response with a 28 day TTL, it’s quite likely the only result I’ll get for the next 28 days. But once those 28 days are up. My lookup will result in the latest address.

1 Like

Thanks for the detailed response. The migration went well and I also see the new website from all the DNS servers. However, I still see half of the traffic go through the old server, and Google seems to be unhappy with that, resulting in a huge loss of traffic.

I’ll go ahead and fix the MX record as well. :slight_smile:

That’s right. I didn’t know that lowering the TTL is necessary as a part of CMS and Server Migration.
I hope that after 28 days everything updates.

I was expecting more like a gradual decrease in the traffic going through the old server; but are you saying that the rest of DNS servers are going to update immediately after 28 days? (Migration was 20 days ago)

How likely is the scenario that the ISPs won’t update the DNS server even after 28 days? Is it possible that this is a traffic hijacking due to a malware or misconfiguration?

Thanks for your response in advance!

Hello Again
It has been more than 28 days since the initial migration. So if the DND caching was the issue, it should be already updated. However, we still see 30-40% of the website traffic goes to the old server

Live traffic to the new site:

Live traffic to the old site:

This doesn’t make sense at all. Can anybody help me with any ideas or similar experiences?

All of the traffic appears to be coming from a single Country in the second screenshot… given the language certainly the region makes sense. While TTLs are supposed to tell a DNS resolver how long before it considers a new answer there are a lot of variables… most of those variables push towards looking up more often, but it’s entirely possible in this instance an ISP has gone the other way.

I’d look at the ASN for the requests and contract that network provider to see if they can flush their DNS cache for your zone

1 Like