You are misdiagnosing the issue. It has nothing to do with DNS or IPv6.

lowyat.net:


lazada.com.my:


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:


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/cache
Cloudflare: https://1.1.1.1/purge-cache/



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:


Notice we are back to square one? This must be pbebank.com authoritative DNS problem.


It might be Imperva problem, or more likely Public Bank configure Geo IP resolver incorrectly.
EDIT:


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.

You mean pbebank? One prefix is so much faster than the other.
I am sure many people don't mind as long as it works.

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/+100

I 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.

some servers are ipv4-only.
some servers are ipv6-only.
some servers are hybrid.

you'll need both.

DNS by right should be able to resolve either IPv4 (A records) and IPv6 (AAAA records).

What i wrote is, your destination servers that a DNS is pointing towards can either be IPv4-only, IPv6-only, or hybrid.
While there is translation layer available - without which IPv4 and IPv6 will not be able to interconnect to each other -, that is not the point i am trying to deliver.

On my part, I do not enable IPv6 at all on all the servers I am taking care of. Strictly IPv4-only.
I don't want the pain of having to administer and decipher the long long IPv6 addresses whenever there is hosting trouble.
The world should have just elongated the IPv4 addresses and otherwise stick to how IPv4 works instead of introducing a whole new worm called IPv6.
Don't have to stunble upon new firewall quirks, don't have to use translator, don't have to come out with mathwiz calculations, ....

Aiya, he prefer pro, me prefer real-life experience.
In the end, it is his lose, because I still switch my DNS based on network condition.

Google DNS give MY server lag?
go one.one.one.one! SG directly!

IP failed?
Seek new IP address using global server ping!(for those not using Anycast IP for CDN la)

I always being to that, lol.
As I used to TM bad routing, no choice la.

Unless I gonna burn money buying VPN as solution, that is another case la.
Yes, as fallback.
I think you never stay at location that have IPv6 broken, and fallback to IPv4 only?
It is a fallback la.

Even it don't happen anymore, I was doing it because it happen before TM change equipment during midnight.
Also found out interesting bug on Google Play app, which taken 30s to fallback IPv4, lol.
Fun fact, until today, most China website still using IPv4.

So yes, even China internal network is a mess when coming to IPv6.

Finish liao, just bug.

Here is your last popcorn for router bug.
Riger1
Riger2
Riger3

---

SHORTEST: Enable Secure DNS at all cost, it is safe and fast.

A bit long: Enable Secure DNS and change your TM DNS on your router, as many IoT device not supporting Security DNS.
Longer:
1. NETIS router's DNS relay drop DNS result that's "status: SERVFAIL", when it shouldn't
2. TM DNS respond every DNS request as status: NOERROR, when it shouldn't
3. PBE forget to list AAAA as EMPTY/NULL on their DNSSEC, when it is allowed, it is still not recommended.
As it may open attack for IPv6 customer, unsure on this part got more vulnerability to combo as an attack or not, lol

Combine 3 together, it works based on bug, but not based on safety.
---
So, just do whatever you need to be done la.
1. Secure DNS at all cost
2. Don't use DNS relay on your old router, setup your DHCP and DHCPv6 or SLAAC DNS,  bypass it and connect directly to internet's GOOGLE or 1.1.1.1 DNS SERVER by client.

Unless it is latest router with DNS relay that supported DoT, then use it!

Done.

It is not IPv6 code, it is DNS relay code.

For example, you might have TuneTalk, instead of sending the SMS delivery report to you, TuneTalk choose to drop it.
But if you testing sms on TuneTalk shortcode, you will receiving it.

It is like I disabled "Call Forward Unanswered/No Answer" on my TuneTalk to prevent extra charge on other telcos that calling me(yes, TuneTalk's voicebox also bite money, lol), old TuneTalk honor it, but now it is enforced redirect to voicebox or "The person you call is not available, pls try again"...
-----
So, your browser expect to receive A Record and AAAA record, but A received, only AAAA error message not received.
Because your router's DNS relay seeing AAAA as a Error message, dropped it instead of telling your browser, while it should not do that.

If there is any application works based on DNS's error message, including A record for IPv4, they will facing the same issues.

For example, I gonna dig this issues, I ran "dig a dnssec-failed.org".

The application tell you, it is your DNS server or connection failed, timeout, which is wrong, right?

It should be

And hei, now, this application know it is DNS error on server side, with the EDE: 9 (DNSKEY Missing)!!!

So it happen to A and AAAA record.
----
Disable IPv6 will solve it?
Nope, it will workaround it, it is like closing your eyes, pretending there is no error.
And how about when it happen to A record?
Still ignore it?

Anyways,
Will it works?
Yes it works.

Is it safe?
Nope, no one need something that modify your result as MITM!!!!
Lucky it just drop it, not modify it....