ISP blocks websites at the behest of the government in non standard way, how to bypass this, Pihole unbound unable to bypass

Hello all,
First off I love pihole, it has enabled me to disable tracking and ads for all my devices and the community has enabled even a noobie like me to set it up in no time. So thankful for that.

Now to my issue:
My country's government has started blocking a lot of websites, some malicious and some not so much.
and the ISPs here are kind of blocking the websites in a weird way. let me explain.
I have setup pihole + unbound and routing my router to use the pihole unbound as the Primary DNS provider
My Router DHCP DNS configuration:

pihole running unbound:

But some of the websites are still getting blocked like for example https://raw.githubusercontent.com/
, they do this by routing all DNS for all blocked webpages to DNS address: 202.83.21.15
which is a blank DNS that the isp is using to divert all blocked DNS traffic.
Now with unbound I thought I can bypass this stupidity but it does not work like that I think and the pihole still proceeds to return the DNS address: 202.83.21.15 for all blocked traffic.

for e.g., if I ns lookup a malicious website let's say https://1337x.to which is a torrent site:
this is what pihole returns:

tinymagicbox@pihole:~# nslookup 1337x.to      
Server:         192.168.100.201
Address:        192.168.100.201#53

Non-authoritative answer:
Name:   1337x.to
Address: 202.83.21.15
;; Got SERVFAIL reply from 192.168.100.201, trying next server

tinymagicbox@pihole:~# nslookup raw.githubusercontent.com      
Server:         192.168.100.201
Address:        192.168.100.201#53

Non-authoritative answer:
Name:   raw.githubusercontent.com
Address: 202.83.21.15
;; Got SERVFAIL reply from 192.168.100.201, trying next server

where 192.168.100.201 is the address of my pihole, so it's using the pihole but still failing to resolve to a proper DNS and just accepting the DNS provided by the ISP which is fake.

Now if I uncheck unbound and just use the Cloudflare ipv4 DNS I can reach this website, same for every other blocked website

tinymagicbox@pihole:~# nslookup 1337x.to
Server:         192.168.100.201
Address:        192.168.100.201#53

Non-authoritative answer:
Name:   1337x.to
Address: 104.31.16.118
Name:   1337x.to
Address: 104.31.16.11

tinymagicbox@pihole:~# nslookup raw.githubusercontent.com
Server:         192.168.100.201
Address:        192.168.100.201#53

Name:   raw.githubusercontent.com
Address: 185.199.111.133
Name:   raw.githubusercontent.com
Address: 2606:50c0:8003::154
Name:   raw.githubusercontent.com
Address: 2606:50c0:8000::154
Name:   raw.githubusercontent.com
Address: 2606:50c0:8001::154
Name:   raw.githubusercontent.com
Address: 2606:50c0:8002::154

that means I can use Cloudflare or google DNS to unblock everything, but that defeats the purpose of my setting up the pihole + unbound

My question is how do I resolve this issue?
How do I make the pihole resolve the real DNS, and not the one provided by ISP?

Is Unbound set up as a recursive resolver or is it forwarding to an external DNS? What happens if you try looing up some other non-blocked domains with your Unound setup? Do they work or also give SERVFAIL?

nslookup google.com

tinymagicbox@pihole:~# nslookup google.com      
Server:         192.168.100.201
Address:        192.168.100.201#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.77.174
Name:   google.com
Address: 2404:6800:4007:818::200e

dig google.com

tinymagicbox@pihole:~# dig google.com

; <<>> DiG 9.16.37-Debian <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28788
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             259     IN      A       142.250.77.174

;; Query time: 0 msec
;; SERVER: 192.168.100.201#53(192.168.100.201)
;; WHEN: Thu Feb 09 04:49:47 IST 2023
;; MSG SIZE  rcvd: 55

nslookup discourse.pi-hole.net

tinymagicbox@pihole:~# nslookup discourse.pi-hole.net
Server:         192.168.100.201
Address:        192.168.100.201#53

Non-authoritative answer:
Name:   discourse.pi-hole.net
Address: 52.14.183.198

dig discourse.pi-hole.net

tinymagicbox@pihole:~# dig discourse.pi-hole.net

; <<>> DiG 9.16.37-Debian <<>> discourse.pi-hole.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1738
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;discourse.pi-hole.net.         IN      A

;; ANSWER SECTION:
discourse.pi-hole.net.  3578    IN      A       52.14.183.198

;; Query time: 0 msec
;; SERVER: 192.168.100.201#53(192.168.100.201)
;; WHEN: Thu Feb 09 04:49:55 IST 2023
;; MSG SIZE  rcvd: 66

dig pi-hole.net 127.0.0.1 -p 5335

tinymagicbox@pihole:~# dig pi-hole.net @127.0.0.1 -p 5335

; <<>> DiG 9.16.37-Debian <<>> pi-hole.net @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12970
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pi-hole.net.                   IN      A

;; ANSWER SECTION:
pi-hole.net.            300     IN      A       3.18.136.52

;; Query time: 11 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Thu Feb 09 04:57:53 IST 2023
;; MSG SIZE  rcvd: 56

dig pi-hole.net 127.0.0.1:5335

tinymagicbox@pihole:~# dig pi-hole.net 127.0.0.1:5335

; <<>> DiG 9.16.37-Debian <<>> pi-hole.net 127.0.0.1:5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22521
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pi-hole.net.                   IN      A

;; ANSWER SECTION:
pi-hole.net.            52      IN      A       3.18.136.52

;; Query time: 0 msec
;; SERVER: 192.168.100.201#53(192.168.100.201)
;; WHEN: Thu Feb 09 05:02:01 IST 2023
;; MSG SIZE  rcvd: 56

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65497
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;127.0.0.1:5335.                        IN      A

;; AUTHORITY SECTION:
.                       3564    IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2023020801 1800 900 604800 86400

;; Query time: 11 msec
;; SERVER: 192.168.100.201#53(192.168.100.201)
;; WHEN: Thu Feb 09 05:02:01 IST 2023
;; MSG SIZE  rcvd: 118

any other way i can check, its working fine for every other non blocked website.

I am no expert but if you test your unbound using https://www.dnsleaktest.com/ and it returns more than one DNS server then your unbound is not acting as a recursive dns server. You might want to read WARNING: Raspbian October 2021 release bullseye + unbound

the result of https://www.dnsleaktest.com/
my real IP address I have edited out

IP	                    Hostname	            ISP	             Country
my.real.static.ip	    broadband.actcorp.in	ACT Fibernet	 Bengaluru, India 
172.68.154.70	        None	                Cloudflare	     Bengaluru, India

I have in my router
primary dns = pihole ip
cloudflare dns = 1.0.0.1

so I think these two results make sense?

Yes that makes sense, dnsleaktest will show your own IP as the DNS server if you're running Unbound in recursive mode. Your additional tests above look okay, Unbound looks to be working fine for those other sites.

Is the ISP ACT or Jio in India? News articles report they have both blocked that github domain. A user on a forum says the block is using SNI blocking, not DNS blocking.

You can turn on more verbose logging in Unbound and that will help reveal what it's seeing, but before you do that you can probably get the same info from these commands from the Pi-hole terminal. Also in Pi-hole you can turn on Settings > DNS > Use DNSSEC and that will show the validation in the Query Log that Unbound is already doing.

This command checks the recursion at each step. I suspect you'll see it working all the way until it tries to access the domain's own nameservers, and then fail in some way. You have to use your Pi-hole for this command because you need to be using the standard port so that progressive connections up the chain will work. So check that Pi-hole is using Unbound like in your second screenshot.

dig +trace +nodnssec raw.githubusercontent.com @127.0.0.1

This command checks the DNSSEC validation and lets you see if something is going wrong. If you try it first with Unbound in Pi-hole, then with Unbound off and using Cloudflare, see what the difference is.

delv @127.0.0.1 raw.githubusercontent.com +vtrace +cd

With unbound pihole on:

tinymagicbox@pihole:~# delv @127.0.0.1 1337x.to +vtrace +cd
;; fetch: 1337x.to/A
;; validating 1337x.to/A: starting
;; validating 1337x.to/A: attempting insecurity proof
;; validating 1337x.to/A: checking existence of DS at 'to'
;; fetch: to/DS
;; validating to/DS: starting
;; validating to/DS: attempting negative response validation from message
;;   validating ./SOA: starting
;;   validating ./SOA: attempting positive response validation
;; fetch: ./DNSKEY
;; validating ./DNSKEY: starting
;; validating ./DNSKEY: attempting positive response validation
;; validating ./DNSKEY: verify rdataset (keyid=20326): success
;; validating ./DNSKEY: marking as secure (DS)
;;   validating ./SOA: in fetch_callback_dnskey
;;   validating ./SOA: keyset with trust secure
;;   validating ./SOA: resuming validate
;;   validating ./SOA: verify rdataset (keyid=951): success
;;   validating ./SOA: marking as secure, noqname proof not needed
;; validating to/DS: in validator_callback_nsec
;; validating to/DS: resuming validate_nx
;;   validating to/NSEC: starting
;;   validating to/NSEC: attempting positive response validation
;;   validating to/NSEC: keyset with trust secure
;;   validating to/NSEC: verify rdataset (keyid=951): success
;;   validating to/NSEC: marking as secure, noqname proof not needed
;; validating to/DS: in validator_callback_nsec
;; validating to/DS: looking for relevant NSEC
;; validating to/DS: nsec proves name exists (owner) data=0
;; validating to/DS: resuming validate_nx
;; validating to/DS: nonexistence proof(s) found
;; validating 1337x.to/A: in fetch_callback_ds
;; validating 1337x.to/A: marking as answer (fetch_callback_ds)
; unsigned answer
1337x.to.               10      IN      A       202.83.21.15

with unbound off and switched to cloudflare ipv4:

tinymagicbox@pihole:~# delv @127.0.0.1 1337x.to +vtrace +cd
;; fetch: 1337x.to/A
;; validating 1337x.to/A: starting
;; validating 1337x.to/A: attempting insecurity proof
;; validating 1337x.to/A: checking existence of DS at 'to'
;; fetch: to/DS
;; validating to/DS: starting
;; validating to/DS: attempting negative response validation from message
;;   validating ./SOA: starting
;;   validating ./SOA: attempting positive response validation
;; fetch: ./DNSKEY
;; validating ./DNSKEY: starting
;; validating ./DNSKEY: attempting positive response validation
;; validating ./DNSKEY: verify rdataset (keyid=20326): success
;; validating ./DNSKEY: marking as secure (DS)
;;   validating ./SOA: in fetch_callback_dnskey
;;   validating ./SOA: keyset with trust secure
;;   validating ./SOA: resuming validate
;;   validating ./SOA: verify rdataset (keyid=951): success
;;   validating ./SOA: marking as secure, noqname proof not needed
;; validating to/DS: in validator_callback_nsec
;; validating to/DS: resuming validate_nx
;;   validating to/NSEC: starting
;;   validating to/NSEC: attempting positive response validation
;;   validating to/NSEC: keyset with trust secure
;;   validating to/NSEC: verify rdataset (keyid=951): success
;;   validating to/NSEC: marking as secure, noqname proof not needed
;; validating to/DS: in validator_callback_nsec
;; validating to/DS: looking for relevant NSEC
;; validating to/DS: nsec proves name exists (owner) data=0
;; validating to/DS: resuming validate_nx
;; validating to/DS: nonexistence proof(s) found
;; validating 1337x.to/A: in fetch_callback_ds
;; validating 1337x.to/A: marking as answer (fetch_callback_ds)
; unsigned answer
1337x.to.               300     IN      A       104.31.16.11
1337x.to.               300     IN      A       104.31.16.118

two different replies in both cases, cloudflare one gives the correct result whereas unbound is trusting the ISPs response and is getting fooled.

Curious to see the dig output. Is it one of those ISPs?

yes the ISP is ACT in Bengaluru.

use unbound+stubby(DOT) or unbound+dnscrypt-proxy(DOH) or just dnscrypt-proxy you can unblock all, this won't work if your isp block all ip address from DOT or DOH public resolver.
In my case I use unbound+dnscrypt-proxy to unblock all then block porn,malware etc via pihole.

any other way within pihole, some setting or command?

Also consider if they filter properly, they will also sniff SNI for anything SSL/TLS related:

The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested.

Are you able to run the dig trace command above, first with Unbound as your Pi-hole upstream, and then with Cloudflare as your upstream, to compare the results?

I shared the results of those commands above.

You did the delv commands but not the dig trace commands

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.