Dns not resolving to closest server

Hi,

We having issue that the DNS keep on randomly resolving to overseas servers and not to closest server causing slow response

When do lookup, we get 3 A records, and only 1 is local, rest is > 150ms response time
;; ANSWER SECTION:
www.places.co.za. 289 IN A 172.67.72.211 -->local
www.places.co.za. 289 IN A 104.26.5.128
www.places.co.za. 289 IN A 104.26.4.128

PING places.co.za (104.26.4.128) 56(84) bytes of data.

How do one go about getting this resolved as creating very bad user experience

thanks

It does peer correctley if the DNS resolve to correct IP address of local server
problem is, seeing that it has 3 by A records, the DNS will give every 3rd person only the correct local dns

When ping the 172 address, get 20ms response time
ping the 104 and get >150ms

Wrong
PING places.co.za (104.26.4.128) 56(84) bytes of data.
64 bytes from 104.26.4.128 (104.26.4.128): icmp_seq=1 ttl=57 time=153 ms

Correct
PING 172.67.72.211 (172.67.72.211) 56(84) bytes of data.
64 bytes from 172.67.72.211: icmp_seq=1 ttl=59 time=21.8 ms

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] /]#