Strange DNS resolving behaviour - Cloudflare in the way?

Issue:
We’re in the process of moving a client’s online store from Selz to Shopify. The DNS records required for both are just A and CNAME records (the setups look pretty similar for both platforms). Both appear to use Cloudflare to issue SSL certificates.

Having changed the A and CNAME records over around 20 hours ago, Shopify is still failing to issue its SSL certificate, and all browser traffic resolves to the old store IP address.

DIG and TRACEROUTE both indicate that the correct A and CNAME records for Shopify are present.

I’m not a network engineer and this is at the limits of my understanding.

I’ve tried to create the domain in my Cloudflare account which it would let me do, implying to my simple brain that there can’t already be an old record of it in CF. There are no records returned which indicate it’s on CF, and the diagnostics don’t throw anything strange up either.

Why would dig and traceroute both give the correct end IPs for the domain, but when I put the domain in my browser I end up at the old store? What network magic is going on that I don’t see here? (requested public cache clearance from Google and CF, cleared local DNS cache, cleared Chrome DNS, tried incognito window/different browser).

Help…?

The bare domain is growurban.uk

NGINX settings on the server perhaps? Proxying that’s taking place in the host files.

I’d assume this nginx routing mechanism has certs loaded and they need updating and the routing URL changed. Try running the server’s SFTP and checking that through I believe it’s here for most…
/etc/nginx/sites-available/

No access to servers - both are ecommerce platforms.

I am afraid, for the Shopify you have to have :grey: cloud on your CNAME record to make it work regarding the SSL certificate.

As Shopify uses Cloudflare, so any DNS records that point to them need to be :grey: DNS Only. You cannot keep Cloudflare :orange: cloud for that DNS entry at Cloudflare dashboard for your domain/sub-domain which uses Shopify.

Meaning, you would need to click on that DNS entry at Cloudflare dashboard to Edit it.
After that, click on the :orange: cloud so it would become :grey: DNS Only.

Well you assumption on most things are right but looking at this question specifically.

Why would dig and traceroute both give the correct end IPs for the domain, but when I put the domain in my browser I end up at the old store? What network magic is going on that I don’t see here?

If it’s giving correct IP, you routed fine–yes?
The old-store would show up cause of a redirection, and that could be inside the code, or a setting in server through nginx like suggested or maybe cpanel, but if this is a raw site-front build would maybe guess it’s in the code or maybe one of the .htaccess files for errors?

Not sure about running proxy-less never have issues there but worth a shot and one should always test both ways! :slight_smile:

Ok, but the domain isn’t, I believe, using cloudflare - only the platform (selz) using it as CDN and for SSL issuing…

No. Let’s strip this down to basics.

DNS records point to Shopify. Both dig and traceroute confirm this to be the case.

If you enter domain into browser, you land at the old website.

What behaviour causes this?

Redirection within code, so server see’s you want /accesspage
It suggests a 301 redirect to /pursue

This can happen on server-level code or its simple engine ran or hard-code in “Javascript”.
So in my experience the server or javascript you are accessing is suggested the redirect and beyond solving this you can sort your SSL further.

If you have SSH access, I would check nginx host files, if not, I’d check the main site script for a common redirect link in JS, or see what “error” pages throw and direct you too.

Let’s say if SSL wasn’t setup on the other domain and you directed correctly, you would get a prompting message from all latest browsers (since ever) over HTTPS SSL. The site would forward right but this prompt would suggest bypass, given the credentials didn’t match with what you generated and used for the site. CF offers a nice universal SSL for all servers you deploy to use.

I’d ask Selz to deprovision your account if you haven’t already. It is possible there’s a conflict.

This makes no sense though: at a fundamental level the request should never reach the old server given the DNS setup.

In fact, on further probing we’ve uncovered something else odd: the request for url is getting to the Shopify server, and is then served the old Selz site from Cloudflare! How on earth do we get the Cloudflare cache cleared so that it no longer serves the old site?

Thanks for that - it’s looking increasingly like this is the issue, and Selz are not playing ball. Is there any way to have all references deleted by CF instead?

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