Unbound and Quad9

Got PiHole working . . . finally but I do have several questions but I will limit them one per post.

How can I configure Unbound on PiHole to use Quad9

I like the privacy that installing Unbound on PiHole provides however I would also like to keep Quad9 as my DNS service of choice. I tried to research this but became very confused. Looking on the Unbound wen site I found this:
That I could define in /etc/unbound.conf
forward-zone:
name: "."
forward-addr: 1.1.1.1 # Cloudflare
forward-addr: 1.0.0.1 # Cloudflare
forward-addr: 8.8.4.4 # Google
In other words I can edit the file to choose the IP of whatever DNS downstream severs I choose.
However when I look at the PiHole As an All Around DNS Solution to configure PiHole as a recursive DNS server the scrip that goes here:
/etc/unbound/unbound.conf.d/pi-hole.conf
does not show that I can configure the "forward-zone" so that Unbound will utilize Quad9 or whatever DNS server IPs I wish.

THX

Why not just put Quad 9 as the upstream DNS provider for your Pi-Hole and skip unbound completely?

Unbound is normally installed to communicate directly with the authoritative name servers, bypassing all third party DNS providers (that may be the privacy aspect you seek). If you point unbound to Quad 9, that's not functionally different than pointing Pi-Hole at Quad 9 without involving unbound.

1 Like

THX for the quick reply. As of now my Pi-Hole is pointed to Quad9 so from that standpoint I am good. I guess the real problem is I am confused as to exactly how DNS really works (I thought I knew but obviously I do not) so I do not really understand Unbound vs DNS services like Quad9 etc. Well the only solution to that is for me to go research DNS to gain an understanding
THX again - dazed and confused

All domain names and addresses are maintained by several levels of authoritative name servers, starting with the root servers, then working down to domain name servers, etc. Basically, the official phone book of the internet.

Any of the commercial DNS providers (Google, Cloudflare, Quad9, your ISP, etc) get their IP addresses from these authoritative servers, then cache the replies. When users request IP addresses, they reply out of cache (if they can), or go get the information.

Unbound does exactly what a commercial DNS provider does - it goes directly to the official phone book. The appeal of unbound is that none of your requests go to commercial DNS providers, which means none of them have access to all your DNS request history. The authoritative servers see your information in partial form for the most part, and they have no commercial interest in your data.

Unbound is very easy to set up (about 15 minutes or so), and works nicely. I recommend it.

Here is an excellent description of how unbound works in resolving DNS queries:

https://docs.pi-hole.net/guides/unbound/

THX Much - your explanation is clear and concise and really helps me out. I understood the phone-book concept but what I didn't understand was the DNS hierarchy. I made some incorrect assumptions as to how commercial DNS providers got the phone-book. So you cleared that up. I am still a little hazy on what a recursive DNS server is but I will figure that out soon.

What I like about Quad9 and some of the others for that matter is that they screen out some of the bad actors (malware, spammers, coin miners etc.) not just ads.

THX again for your explanation - I have some reading to do.

I really am enjoying the significant performance hit my Pi-Hole set-up (on a VM on my Linux Mint PC) gives me on my network (two Linux Mint PCs, a linux Mint laptop, two Rokus).

Your Pi-Hole does this as well, with the appropriate block lists. The collection below is very good. You can choose the lists you want to use and add them to your block lists in Pi-Hole.

The advantage of using your Pi-Hole for this is that you have complete control over what is filtered. If something can't be reached through Quad9 and you want to reach it, you don't have any option other than change DNS provider. With Pi-Hole, you just whitelist the domain or add an item to your black list.

WOW ! perfect

Also I think I am going to take this approach:
DNS-Over-HTTPS on Pi-hole which utilities CloudFlare (at some point I guess I just have to trust somebody). I had used DNScrypt in the past and was interested in DoH so this appeals to me . . . . unless there is a way is a to go HTTPS from pi-Hole to the authoritative DNS server using Ubound this an OK compromise privacy wise.

I don't believe this is possible.

If this is the case, the somebody you would trust the most is you. With unbound, you are in complete control of your resolver. Yes, the ISP can see your DNS queries, but they will see all your requests for the IP shortly afterward, so even if you use an encrypted DNS stream, they will know where you are going anyway.

With any connection to Cloudflare (or any other third party DNS), they see your complete DNS search history. Then your ISP sees all the requests for IP, so they effectively know where you are going on the web. That's two parties you need to trust.

With unbound setup per the guide, only your ISP sees all your DNS requests and requests for traffic (basically the same data), so you only have to trust one party other than yourself.

How about if I use Ubound through my VPN ? No commercial DNS server which I really want and my DNS queries are encrypted at least as far as my VPN server - right? No Man in the Middle or DNS spoofing vulnerabilities.

This may provide a DNS leak - your DNS may appear to be coming from your real IP and not from the VPN service. However, if you put the VPN tunnel on your router and both your PI and clients are using the same tunnel, this may work. I've not tried it.

When I run through a VPN, I just use the VPN service DNS without Pi-Hole. The VPN provider is already seeing my traffic so seeing my DNS requests is nothing extra. And, no DNS leak.

Well right now my VPN is on my client PCs - when I do a DNSleak test it is showing my VPN IP and Quad9 which I am using from pi_hole. My clients DNS network config is to the Pi-Hole IP and routers have no DNS configured so I know I am getting my DNS from Pi-hole. So that looks pretty good . . . no?

I think it does.

OK that is how I am going to roll - Unbound through my VPN and add some some blocklists that I like.

THX a whole bunch - great forum - donated $2/month because Pi-Hole has been a great experience and in no small part to your kind help and patients (sp?) help - so THX again.

1 Like

After you set this up, run the DNS leak check again.

Ran into problems installing unbound here:

majpooper@PiHole ~ $ dig pi-hole.net @127.0.0.1 -p 5353

; <<>> DiG 9.10.3-P4-Ubuntu <<>> pi-hole.net @127.0.0.1 -p 5353
;; global options: +cmd
;; connection timed out; no servers could be reached

This went OK . . . I think
majpooper@PiHole ~ $ sudo service unbound start

I had to create this file with the text editor (I use Leafpad) and made it exacutable
majpooper@PiHole ~ $ /etc/unbound/unbound.conf.d/pi-hole.conf

not sure what went wrong - still looking at it though

Trying to figure out how to fix this:
PiHole unbound[17166]: [1538339392] unbound[17179:0] error: can't bind socket: Address already in use for ::1

OK - the good news is I got unbound installed and working - although dnsmasq was not installed dnsmasq-util (something like that) still was and that somehow was using either 127.0.0.1 or socket 5353. Once I removed that everything worked.

The bad news I have DNS leak - even without my VPN I am still using the ISP's DNS servers not the authoritative DNS servers that I can tell.

What are the outputs from the following commands on the Pi terminal and the first command from one of the connected clients (client may need to use nslookup).

dig cnn.com

dig cnn.com @127.0.0.1 -p 5353

It doesn't matter if I use my VPN or not when I do a DNS leak test it shows my ISP as the DNS server. My location (IP) changes when I use the VPN but not the ISP DNS server.

Here is the out put from the two commands executed from my pi-hole
majpooper@pihole:~$ dig cnn.com

; <<>> DiG 9.10.3-P4-Debian <<>> cnn.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62227
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1

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

;; ANSWER SECTION:
cnn.com.		3600	IN	A	151.101.129.67
cnn.com.		3600	IN	A	151.101.65.67
cnn.com.		3600	IN	A	151.101.193.67
cnn.com.		3600	IN	A	151.101.1.67

;; AUTHORITY SECTION:
cnn.com.		3600	IN	NS	ns-1086.awsdns-07.org.
cnn.com.		3600	IN	NS	ns-1630.awsdns-11.co.uk.
cnn.com.		3600	IN	NS	ns-47.awsdns-05.com.
cnn.com.		3600	IN	NS	ns-576.awsdns-08.net.

;; Query time: 76 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 01 20:58:18 EDT 2018
;; MSG SIZE  rcvd: 236

majpooper@pihole:~$ dig cnn.com @127.0.0.1 -p 5353

; <<>> DiG 9.10.3-P4-Debian <<>> cnn.com @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49481
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1

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

;; ANSWER SECTION:
cnn.com.		3487	IN	A	151.101.129.67
cnn.com.		3487	IN	A	151.101.65.67
cnn.com.		3487	IN	A	151.101.193.67
cnn.com.		3487	IN	A	151.101.1.67

;; AUTHORITY SECTION:
cnn.com.		3487	IN	NS	ns-1086.awsdns-07.org.
cnn.com.		3487	IN	NS	ns-1630.awsdns-11.co.uk.
cnn.com.		3487	IN	NS	ns-47.awsdns-05.com.
cnn.com.		3487	IN	NS	ns-576.awsdns-08.net.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Mon Oct 01 21:00:11 EDT 2018
;; MSG SIZE  rcvd: 236

majpooper@pihole:~$

And from one of the connected clients
majpooper@1150z ~ $ dig cnn.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> cnn.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13444
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
cnn.com.		3546	IN	A	151.101.1.67
cnn.com.		3546	IN	A	151.101.193.67
cnn.com.		3546	IN	A	151.101.65.67
cnn.com.		3546	IN	A	151.101.129.67

;; Query time: 1 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Mon Oct 01 20:59:12 EDT 2018
;; MSG SIZE  rcvd: 100