Btw, why is actually a pharmacy online shop need to be blocked?

now u jinxed it. :-)

Anyway:
Cleanbrowsing-Family kena kaw kaw.
Cleanbrowsing-Adult only 1 of 2 IPs kena.
Cleanbrowsing-Security not affected.

Heads up for anyone using free NextDNS accounts for ad/tracker blocking. Remember to tick the 3 boxes in the Performance sub-section under the Settings tab. Especially the Cache Boost option, because without that you will likely reach your 300k query limit sooner than you realize. Also, the anexia-kul and premiumdrp-kul are (historically) the best local servers for us wrt latency.


Pharmianaga cartel. Go check the prices of your basic vitamin supplements on iHerb and compare with the daylight robbery you’re charged at your local pharmacy. Of course, their excuse “for your safety”. Just like how all this DNS blocking/redirecting is “for your safety. Topkek, first time you hear that bareback DNS is safer. Next they’ll ask you to fuck without condoms.

This post has been edited by dev/numb: Sep 3 2024, 10:46 PM

It's not blocked for me.

Using naked non-DOH plain jane 8.8.8.8 can still access iherb no problem.

At the moment, I'm just looking at the answers, if 175.139.142.25, the IP that TM returns for blocked sites then confirm the DNS has been hijacked.

For CleanBrowsing-Adult, the DNS IPs are 185.228.168.10 & 185.228.168.11. 10 is hijacked and 11 is not. (Of course, don't test with adult sites since they are blocked by this DNS)

10 has a ping of 4ms while 11 has a ping of 70ms. I bet a traceroute will show that 10 never goes out of TM's network. 11 goes to SG, I think.

This post has been edited by soonwai: Sep 3 2024, 10:52 PM

They just don’t deem it “evil” enough to hijack/redirect 8.8.8.8 queries. Not “evil” like Uncle Murray who they deem enemy of the state for some reason.. You can try turning off 8.8.8.8 and using ISP DNS and see if it loads. I know during the height of Covid it wouldn’t load under TM’s own DNS. But after iHerb created a ml.iherb domain for us I’m not sure if any alternative DNS was ever truly needed.

This post has been edited by dev/numb: Sep 3 2024, 10:57 PM

Are you in a location other Klang Valley? TNG55 in Penang not affected. Seems like only certain regions for now.

Anyway for me, Kajang:
dig ml.iherb.com @8.8.8.8
returns
175.139.142.25

Legit IPs should be:
172.64.149.245
104.18.38.11

TM not just hijacking DNS queries though. They're rerouting & NATting 8.8.8.8 to their own server. Go to https://8.8.8.8 and you can see their dns.tm.net.my SSL cert.

This post has been edited by soonwai: Sep 3 2024, 11:21 PM

anyone facing severe lag in games, particularly at night?

No problems with DoH here, on Chrome.

Ya, PJ, Klang Valley.

104.18.38.11

just know got another DNS, so far i tested now, before this all the time using 1.1.1.1 DNS, cannot load murray site, DNS leak test all show TM
i change to quad9 DNS, can load murray site and above iherb, and DNS leak test



yes i using windows 11, ON auto template DNS over HTTPS (this what you all say DoH right?)

Yup, same as me. I use Q9. I suspect Quad9 also will be gone soon.

sadly cannot set on router, using tp link ax20

the authority is just dealing with non sophisticated internet users . if you are not using any of these dns , you are probably OK. the sophisticated internet users use other DNS not seen in the image.



This post has been edited by issac99289928: Sep 3 2024, 11:56 PM

Another way to check is to go to https://dns.google. Nothing to do with DNS queries here.

If All your 8888s are belongs to TM, you'll see this:

You can also click Advanced to look at the SSL cert.

If A-OK then:


*Using Firefox.

This post has been edited by soonwai: Sep 3 2024, 11:59 PM

Let's hope they employ the 80/20 rule

Block 80% with only 20% effort 👍 😉


Q9 seems fine. ~10ms.

So far we got:

Kajang ❌❌
Kuching ✅
Penang ✅
PJ ✅✅

This post has been edited by soonwai: Sep 4 2024, 01:18 AM

Uh, quick question
Do i run dig on a DoH or non-DoH enviroment?

Adguard's https://dns.adguard-dns.com/dns-query

So given what they are doing blocks even DoH, will that Amazon AWS wall climbing method still work even when using cloudflare-dns.com or dns.google as the origin?