Avoiding DNS poisoning from the ISP side

Installing and Using OpenWrt
1

The ISP does very advanced stuff with DNS, that you can't reach to some sites. Can we overcome this by encrypting the DNS? I've tried various dns encrypting stuff on wiki, but they didn't work.
For example I try to connect to site here like this:

www.insertadultsitehere.com
Hata kodu: PR_CONNECT_RESET_ERROR

When I trace route:

traceroute xvideos.com
traceroute to xvideos.com (185.88.181.6), 30 hops max, 60 byte packets
 1  _gateway (192.168.1.1)  0.992 ms  1.018 ms  0.945 ms
 2  85.108.97.1.dynamic.ttnet.com.tr (85.108.97.1)  4.672 ms  5.472 ms  5.987 ms
 3  81.212.73.197.static.turktelekom.com.tr (81.212.73.197)  2.218 ms  3.526 ms  3.457 ms
 4  34-esenyurt-sr2s-t3-2---34-kadikoy-sr2s-t3-1.statik.turktelekom.com.tr (81.212.213.153)  3.389 ms  3.320 ms  3.252 ms
 5  * * *
 6  * * *
 7  * * *
 8  buca-b3-link.ip.twelve99.net (62.115.37.72)  43.461 ms  43.585 ms  43.516 ms
 9  ae-7.r20.vienat02.at.bb.gin.ntt.net (129.250.3.62)  35.501 ms  45.117 ms win-bb1-link.ip.twelve99.net (62.115.114.110)  44.071 ms
10  ffm-bb1-link.ip.twelve99.net (62.115.137.202)  42.784 ms ffm-bb2-link.ip.twelve99.net (62.115.138.22)  44.224 ms ae-5.r23.vienat02.at.bb.gin.ntt.net (129.250.7.21)  29.505 ms
11  ae-12.r22.amstnl07.nl.bb.gin.ntt.net (129.250.7.29)  48.843 ms  48.774 ms  48.385 ms
12  digitalocean-ic-378008.ip.twelve99-cust.net (80.239.132.215)  41.731 ms ae-0.a01.amstnl09.nl.bb.gin.ntt.net (129.250.2.253)  49.658 ms ae-0.a00.amstnl09.nl.bb.gin.ntt.net (129.250.2.163)  48.880 ms
13  213.198.92.123 (213.198.92.123)  49.638 ms 143.244.224.104 (143.244.224.104)  42.708 ms 213.198.92.119 (213.198.92.119)  49.250 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
2

Use dns over tls or https as upstream.

Ciao

Luigi

3

are you using custom DNS servers for your lan interface?

Network>Interfaces>edit LAN>advanced settings>Use Custom DNS servers?

If not enter 1.1.1.1 and 1.0.0.1 see if it works. Otherwise you can use this guide to set up DNS over TLS: https://medium.com/@harriebird/implement-dns-over-tls-on-openwrt-20b7026a9b6c

4

Bedt is to set dnsmasq forwarders to encrypted dns proxy, can be tor if those are blocked.

5

So actually, this seems to be some disconnect after attempting to connect to the server.

FYI, actually your DNS resolution seems to be working for that website.

6

No, they are so fixated on this they do weird things to avoid this kind of stuff. Its %100 them preventing it. They somehow make it return not safe error like this. As you can see in traceroute, it goes through their turktelekom servers, and voila, not safe error? Something fishy they are doing.

1 Like
7

Countries that implement the “Great Firewall” such as by using DPI https://en.wikipedia.org/wiki/Deep_packet_inspection#By_governments
Can be bypassed with tools such as https://github.com/bol-van/zapret or Cloudflare WARP.

Yes, I live in such a country.
Cloudflare WARP and zapret can solve that.
I ruled out Tor because it is very slow.

Meanwhile DoT or DoH is useless for strict ISPs.

4 Likes
8

?

I believe you, but it's not DNS in the example you pasted.

I agree.

9

I am curious as to why you believe your issue is DNS related. The resolved IP matches a hosting provider (Server Stack ) in the Netherlands.
Furthermore, if you query the resolved IP on DNSLytics
( https://search.dnslytics.com ) , it shows that the IP exactly matches the domain you traced, as well as apparently hosting other related websites.

image
image1257×367 45.9 KB

Do you have any type of Geo-filtering (or other type of category-based IP filtering ) on your router? The reason I ask is that the last hop in your traceroute shows conflicting location information by several Geo databases. (Canada, Germany, U S )

image
image466×418 41.3 KB

Also, the non-response at hop 14 of your traceroute could just be where it hits layer 2 switching.
If you really think your ISP is the issue, have you tried, or do you have the option to try using VPN on your computer?

2 Likes
10

Vpn s do work, but they are slow. Other ISP s dont even do this. Only this ISP.

1 Like
11

The ISP is firewalling that site. When you try to establish a TCP connection, the ISP firewall blocks the traffic and sends you a reject packet instead.

They can allow pings and traceroutes but block TCP. This could be a simple firewall not necessarily DPI. DPI is based on looking for and stopping VPN usage. It's found in conjunction with a simple firewall to prevent direct access to sites.

2 Likes
12

I've heard of Zapret, I've been trying to make it work. But I think ISP guys just overcome that, probably. I assume you're from China or Russia, does it work for you? This happens:
curl -I <URL to porn site removed by admin>
curl: (35) Recv failure: Bağlantı karşıdan kesildi(Connection cut from the other side)

13

Maybe you can work around by connecting through a proxy server?

2 Likes
14

Checking "drop invalid" in firewall sometimes prevents on-path resets.

15

The TCP connection error reset is due to some Deep Packet Inspection from the ISP. You need GoodbyeDPI or similar tools to bypass it. It sends the TCP reset request to your browser before TLS is established to fool your browser. It has nothing to do with DNS.

3 Likes
16

Dnscrypt-proxy2 might also be another option via Anonymized DNS.

1 Like
17

Does not seem very deep, dns is not manipulated, and a simple tcpdump --w + wireshark can tell if it is sni or ip based bñovking. DPI would be killing openvpn over domain fronting after one meg.

18

I live in Indonesia.
Yes, it works fine.
But I don't need zapret anymore coz I've moved to a better ISP.
Now I only use https-dns-proxy.
I also configured Cloudflare WARP (WireGuard) on OpenWrt to be enabled only in certain situations (when I need to hide my IP). :smile:

19

More like a provider block
If you have a passive dpi, you can add this
enter these commands through PuTTY

mkdir -p /usr/share/nftables.d/chain-post/raw_prerouting
cat >/usr/share/nftables.d/chain-post/raw_prerouting/01-tcp-rst.nft <<EOF
iifname "eth0.2" tcp sport 80 tcp flags & (rst) == rst counter drop
iifname "eth0.2" tcp sport 443 tcp flags & (rst) == rst counter drop
EOF
/etc/init.d/firewall restart

eth0.2 is the wan interface, if you have another one, then replace the name

If you have a more advanced DPI, you need to master the relevant topics :slight_smile:
If something starts to be blocked in one country, then it will happen in all countries
all this will be under the pretext of your safety :slight_smile:

20

Nope, also didn't work. I used pppoe-wan instead of eth0.2 which is my wan