Dns not resolving to closest server

It’s still the same issue. Your ISP appears to apply a different route for that address range. I am afraid you’d need to contact your ISP about that. The linked article has the details on that.

Does your server IP address end in 154?

So why is the one routing correct, other not,?.. cause the one is not local…

Tracing route to www.places.co.za [104.26.4.128]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  core.wonderland.internal [10.0.0.5]
  2     3 ms     3 ms     3 ms  102-182-118-1.ip.afrihost.capetown [102.182.118.1]
  3     3 ms     3 ms     2 ms  169-1-21-1.ip.afrihost.co.za [169.1.21.1]
  4     6 ms     3 ms     3 ms  wdcnw-os-cer-1-wan.osnet.co.za [196.25.26.65]
  5   152 ms   152 ms   153 ms  10.189.30.2
  6   149 ms   158 ms   149 ms  linx-lon1.as13335.net [195.66.225.179]
  7   152 ms   152 ms   153 ms  104.26.4.128

Trace complete.

Tracing route to 172.67.72.211 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms core.wonderland.internal [10.0.0.5]
2 3 ms 2 ms 2 ms 102-182-118-1.ip.afrihost.capetown [102.182.118.1]
3 3 ms 3 ms 3 ms 169-1-21-1.ip.afrihost.co.za [169.1.21.1]
4 21 ms 21 ms 21 ms 100.127.2.172
5 87 ms 35 ms 22 ms cloudflare.ixp.joburg [196.60.8.198]
6 22 ms 21 ms 21 ms 172.67.72.211

Trace complete.

As I mentioned, that something you need to discuss with your ISP. The linked article covers all the details.

Also

Yes , server resolves to 154

If you look at the location of the 104 range, that is USA. Our server is in South africa…

I would have thought that the DNS must resolve to the South african data centers…

The 172 address does go to the South African PoP, but the 104 does not and goes to London instead. But as I mentioned already twice, that will be your ISP’s routing and is something you need to take up with them. That’s all addressed in the article.

Also, you do not seem to have a valid certificate on your server and you’ll also have an insecure encryption mode on Cloudflare. You definitely need to fix this as your site is currently insecure.

Here you can see that DNS test randomly resolves to the wrong servers…

let me ask you this.

Where is the “server” 104.26.5.128 . Is it a SA datacenter IP?

output from the link you sent (cdn-cgi/trace) … Its sending me to LHR … an no, i don’t have vpn’s proxies etc
also, I worked at a ISP , and managed a very large network for years, so my routing skills is ok

fl=21f629
h=www.places.co.za
ip=102.182.118.*
ts=1625561311.083
visit_scheme=http
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0
**colo=LHR**
http=http/1.1
loc=ZA
tls=off
sni=off
warp=off
gateway=off

That’s what I wrote earlier. But you should definitely fix the certificate issue though.

Why is the CGI route resolving to LHR ? is that cloudflare thinking im in london although my LOC says ZA

Precisely what I wrote at Dns not resolving to closest server - #9 by sandro

1 Like

ok
So if this is ISP issue. What must I tell them, cause I just check if I go to places.co.za (without www) it resolves to JHB. when I go to WWW.places it goes to LHR?

places.co.za
fl=45f35
h=places.co.za
ip=102.182.118.24
ts=1625562120.662
visit_scheme=http
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0
colo=JNB
http=http/1.1
loc=ZA
tls=off
sni=off
warp=off
gateway=off

www.places.co.za
fl=21f633
h=www.places.co.za
ip=102.182.118.24
ts=1625562203.317
visit_scheme=http
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0
colo=LHR
http=http/1.1
loc=ZA
tls=off
sni=off
warp=off
gateway=off

This has nothing to do with www or not. This is purely related to the 104.26.5.128 address and that’s what you need to clarify with your ISP.

But the certificate is something you will need to clarify with your host, not your ISP.

you have lost me completley. I’m happy to log the call with my ISP, but have no idea what to ask.

The IP address 104.26.5.128 is a Cloudflare IP in London. My PC is connecting to that IP address as Cloudflare DNS says I have to. (as per below dig on cloudflare dns direcetley).

So must I ask them to route that IP to SA ?

 dig www.places.co.za @jason.ns.cloudflare.com.

; <<>> DiG 9.16.1-Ubuntu <<>> www.places.co.za @jason.ns.cloudflare.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6750
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.places.co.za.              IN      A

;; ANSWER SECTION:
www.places.co.za.       300     IN      A       **104.26.4.128**
www.places.co.za.       300     IN      A       172.67.72.211
www.places.co.za.       300     IN      A       104.26.5.128

;; Query time: 3 msec
;; SERVER: 172.64.33.179#53(172.64.33.179)
;; WHEN: Tue Jul 06 09:10:54 UTC 2021
;; MSG SIZE  rcvd: 93

[email protected]:/var/www/html/OTYellowMetal#

What exactly is unclear about Dns not resolving to closest server - #9 by sandro?

You need to talk to your ISP and clarify with them why that particular address is routed to London instead of to the local PoP. But that’s essentially what I wrote a few times already and what’s already explained in the article. What exactly is unclear about that?

Also, that won’t fix your certificate issue.

So tested from a server that is in Hetzner datacenter in CPT.
Its also resolving to LHR .

curl http://www.places.co.za/cdn-cgi/trace
fl=21f430
h=www.places.co.za
ip=197.221.62.173
ts=1625563066.268
visit_scheme=http
uag=curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
colo=LHR
http=http/1.1
loc=ZA
tls=off
sni=off
warp=off
gateway=off
[[email protected] /]#

I am afraid we are going in circles and it all has been addressed already an hour ago by the first response → Dns not resolving to closest server - #2 by sandro

You can only talk to your host, Cloudflare can’t change the routing and the community here can’t do anything either.

I’d suggest you read the article once more and talk to your ISP.

Also, you did not address my certificate concern at all so far. You currently have an insecure site, you know that?

1 Like

sorry, I was locked out for 24 hrs for replying to much

I tested 3 other clouflare sites … they all work 100% and goes to the closest datacenter (CPT).
its only this one domain that send 1/3 of the traffic to JNB and rest to LHR.

I’ve tested 3 ISP’s … same story, so this is not ISP related.

I also spoke My ISP and they said , its 'n cloudflare config issue and cloudflare must fix it.

Wrong:


Correct

Correct:

The last domain is on the SAME server as the one that is not working

----------------------------------- DNS results for 2 domains on SAME server ----------------------------
;; ANSWER SECTION:
placescarhire.com. 300 IN A 104.21.64.59
placescarhire.com. 300 IN A 172.67.176.168

;; ANSWER SECTION:
www.places.co.za. 300 IN A 104.26.4.128
www.places.co.za. 300 IN A 104.26.5.128
www.places.co.za. 300 IN A 172.67.72.211

Please explain to me why this is a peering issue if its the same ISP same Server hosting both websites?

The server which hosts the sites naturally is irrelevant, it is about the network ranges of the proxies.

I am sorry, but as I already said, we are going in circles. This is a routing issue which your ISP should look into, if they can’t do that, your only option would be to upgrade to a paid plan as there Cloudflare typically tries to ensure “better” routing, but even that is not guaranteed.

This issue has been discussed a million times and if you had used the search (as you were supposed to) we wouldn’t have needed a 20-posting-long thread to rehash something which was addressed more than once.

If you believe Cloudflare has to fix something here you are certainly free to open a support ticket and request that fix, but I can tell you already now you’ll most likely end up with a similar response.

Plus, I addressed the blatant security issue of your site quite a few times but you keep ignoring it. I’d say an insecure site should be of a bigger concern than a few more milliseconds.