QUOTE(BenYeeHua @ Nov 26 2023, 05:17 PM)
I guess some ISP is special?
Unsure, can be their tech setup it wrongly?
Based on this thread, UniFi
https://forum.lowyat.net/topic/5073652/+100I think If you feel slow down, then try disable IPv6 la, but the issues is mostly caused by the throttling of UniFi on SG, like the rerouting of HK to SG CloudFlare now....
---
For your info, I performed testing on www.lazada.com.my with IPv4 and IPv6 of Google DNS and CloudFlare DNS.
Here is the result.
2606:4700:4700::1111, MY
2606:4700:4700::1001, MY
1.1.1.1, SG Akamai for IPv4/IPv6
1.0.0.1, SG Akamai for IPv4/IPv6
2001:4860:4860::8888, MY
2001:4860:4860::8844, MY
8.8.8.8, MY for both
8.8.4.4, MY for both
This is why I prefer Google DNS, lol.
For the extra, both IPv6 DNS got reaching issues for Public Bank's DNS server, lol.
https://www2.pbebank.com/Yes, there is 10s timeout for public bank.(old is 30s)
This might be caused by the caching time TTL is 30s, but strange that if I check via Android network tools, it is fine....

---
More testing on PBe, it works well also on DNS over HTTPS, both IPv4/IPv6, so...
Seem like only happen on DNS over UDP for IPv6 la.
You are misdiagnosing the issue. It has nothing to do with DNS or IPv6.
lowyat.net:
CODE
$ dig +short lowyat.net a lowyat.net aaaa @1.1.1.1
104.26.7.73
172.67.74.89
104.26.6.73
2606:4700:20::ac43:4a59
2606:4700:20::681a:749
2606:4700:20::681a:649
$ dig +short lowyat.net a lowyat.net aaaa @8.8.8.8
172.67.74.89
104.26.7.73
104.26.6.73
2606:4700:20::681a:649
2606:4700:20::681a:749
2606:4700:20::ac43:4a59
lazada.com.my:
CODE
$ dig +short lazada.com.my a lazada.com.my aaaa @1.1.1.1
47.246.167.7
47.246.165.39
47.246.165.72
47.246.165.182
47.246.165.115
47.246.167.210
47.246.167.252
47.246.167.254
$ dig +short lazada.com.my a lazada.com.my aaaa @8.8.8.8
47.246.167.7
47.246.165.39
47.246.165.72
47.246.165.182
47.246.165.115
47.246.167.210
47.246.167.252
47.246.167.254
As you can clearly see, both Cloudflare DNS and Google DNS return the same result. So changing what DNS server you use doesn't affect the result one bit.
For lowyat.net, all IPv4 go to HK directly. all IPv6 go to SG directly.
lowyat.net uses Cloudflare DNS as their authoritative DNS and also CDN.
Simply using IPv6 cut latency in half!
Trying a few other Cloudflare fronted domain, not all of them have this problem, which I suspect is how Cloudflare distribute traffic between HK and SG datacenter.
For lazada.com.my, all IPv4 go to HK > SG. No IPv6 support.
lazada.com.my uses Alibaba Cloud as their authoritative DNS.
To further diagnose this issue, TM need to provide public access to their BGP Looking Glass. Alternatively anyone who has peering with TM BGP + full internet routing table should be able to diagnose it properly.
pbebank.com:
CODE
$ dig +short pbebank.com a pbebank.com aaaa @1.1.1.1
203.115.208.218
$ dig +short pbebank.com a pbebank.com aaaa @8.8.8.8
43.241.40.218
$ dig +short www.pbebank.com a www.pbebank.com aaaa @1.1.1.1
203.115.208.218
$ dig +short www.pbebank.com a www.pbebank.com aaaa @8.8.8.8
203.115.208.218
$ dig +short www2.pbebank.com a www2.pbebank.com aaaa @1.1.1.1
43.241.40.253
$ dig +short www2.pbebank.com a www2.pbebank.com aaaa @8.8.8.8
43.241.40.253
Here we can see the apex domain return a different IP address: 203.115.208.218 (Cloudflare), 43.241.40.218 (Google)
43.241.40.218 and 43.241.40.253 (AS6453 TATA COMMUNICATIONS (AMERICA) INC) go to Singapore and come back to Kuala Lumpur.
203.115.208.218 (AS10204 Arcnet NTT MSC ISP) route directly via MyIX.
Let's flush the DNS resolver cache:
Google:
https://dns.google/cacheCloudflare:
https://1.1.1.1/purge-cache/CODE
$ dig +short pbebank.com a pbebank.com aaaa @8.8.8.8
43.241.40.218
$ dig +short pbebank.com a pbebank.com aaaa @1.1.1.1
58.26.83.218
You can see Cloudflare DNS now gets a new IP address while Google DNS gets the same IP address.
58.26.83.218 (AS4788 TM TECHNOLOGY SERVICES SDN. BHD.) is super fast since it is inside TM network and I am using TM.
Let's flush the cache for a second time:
CODE
$ dig +short pbebank.com a pbebank.com aaaa @8.8.8.8
43.241.40.218
$ dig +short pbebank.com a pbebank.com aaaa @1.1.1.1
203.115.208.218
Notice we are back to square one? This must be pbebank.com authoritative DNS problem.
CODE
$ dig +short ns pbebank.com
ns1.a1.impervasecuredns.net.
ns1.a0.impervasecuredns.net.
ns1.a2.impervasecuredns.net.
It might be Imperva problem, or more likely Public Bank configure Geo IP resolver incorrectly.
EDIT:
CODE
$ wget -O - -4 https://cloudflare.com/cdn-cgi/trace
--2023-11-27 04:42:50-- https://cloudflare.com/cdn-cgi/trace
Resolving cloudflare.com (cloudflare.com)... 104.16.132.229, 104.16.133.229
Connecting to cloudflare.com (cloudflare.com)|104.16.132.229|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘STDOUT’
- [<=> ] 0 --.-KB/s fl=632f34
h=cloudflare.com
ip=115.134.178.XXX
ts=1701031371.005
visit_scheme=https
uag=Wget/1.21.3
colo=SIN
sliver=010-tier1
http=http/1.1
loc=MY
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off
rbi=off
kex=X25519
$ wget -O - -6 https://cloudflare.com/cdn-cgi/trace
--2023-11-27 04:42:57-- https://cloudflare.com/cdn-cgi/trace
Resolving cloudflare.com (cloudflare.com)... 2606:4700::6810:84e5, 2606:4700::6810:85e5
Connecting to cloudflare.com (cloudflare.com)|2606:4700::6810:84e5|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘STDOUT’
- [<=> ] 0 --.-KB/s fl=497f454
h=cloudflare.com
ip=2001:e68:5427:A:B:C:D:E
ts=1701031377.522
visit_scheme=https
uag=Wget/1.21.3
colo=SIN
sliver=010-tier1
http=http/1.1
loc=MY
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off
rbi=off
kex=X25519
Looks like Cloudflare is working properly over both IPv4 and IPv6. colo=SIN, loc=MY
A quick look into their community forum shows that this is an intended behavior for customer using Free and Pro plan. Fork out the money for Business or Enterprise plan and the problem will disappear.
Maybe lowyat.net should just pay more.
This post has been edited by kwss: Nov 27 2023, 04:48 AM