# Unbound, stubby or dnscrypt-proxy
**URL:** https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378
**Category:** General
**Created:** [May 8, 2018, 8:16am UTC](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 "2018-05-08T08:16:39Z")
**Posts on this page:** 14
**Page:** 3
### Author:  [@gecko](https://discourse.pi-hole.net/u/gecko)
#### Post date: [May 18, 2018, 4:15pm UTC](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378/41 "2018-05-18T16:15:21Z")
> [@jpgpi250](#):
>
> This is why I’ve asked [@gecko](https://discourse.pi-hole.net/u/gecko), who seems to be running stubby+DNSSEC to publish his findings. More results, will lead to a better evaluation.
I've added the results from that page using pihole with stubby+DNSSEC [here](https://discourse.pi-hole.net/t/dnssec-test-fails/9586/3)
---
### Author:  [@jpgpi250](https://discourse.pi-hole.net/u/jpgpi250)
#### Post date: [May 18, 2018, 4:26pm UTC](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378/42 "2018-05-18T16:26:29Z")
@gecko Thanks for this.
@DL6ER If you would be so kind to publish the unbound results in the [same topic](https://discourse.pi-hole.net/t/dnssec-test-fails/9586), this would be great, usefull, a contribution to an impartial evaluation.
Thanks.
---
### Author:  [@gecko](https://discourse.pi-hole.net/u/gecko)
#### Post date: [May 18, 2018, 4:31pm UTC](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378/43 "2018-05-18T16:31:43Z")
> [@DL6ER](#):
>
> Oh, you can. When you use `unbound` as your resolver under the hood and disable all DNSSEC validation in `dnsmasq` resp. `pihole-FTL` then there is in fact no bug and you’re still protected by DNSSEC as BOGUS domains will not be resolved by `unbound` 😉
For anyone else wanting DNSSEC and reading tbis, that's the setup I went with in the end using stubby, but it applies equally to unbound etc. I was tired of all the DNSSEC bugs I had in dnsmasq/FTLDNS, so ended up just disabling DNSSEC on the pihole and only enabling it on stubby. DNSSEC works fine, and is reported as working in all the tests. The only downside is that you don't get the information in the pihole web interface.
---
### Author:  [@jpgpi250](https://discourse.pi-hole.net/u/jpgpi250)
#### Post date: [May 18, 2018, 4:36pm UTC](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378/44 "2018-05-18T16:36:54Z")
> [@gecko](#):
>
> The only downside is that you don’t get the information in the pihole web interface.
If I've understood @DL6ER correctly, future versions of pihole FTLDNS will report SERVFAIL in the pihole web interface.
---
### Author:  [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)
#### Post date: [May 18, 2018, 5:26pm UTC](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378/45 "2018-05-18T17:26:00Z")
Yes, there is a small inconsistency with how such responses are handled within dnsmasq and this will be resolved with 2.80 as well. From this point on, we can show SERVFAIL in the query log.
---
### Author:  [@jpgpi250](https://discourse.pi-hole.net/u/jpgpi250)
#### Post date: [May 23, 2018, 8:11am UTC](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378/46 "2018-05-23T08:11:28Z")
The result, after running my pi + pihole, untouched, for 8 days:
local: 53.3%
dnscrypt-ipv6: 13.6%
dnscrypt-ipv4: 10%
unbound-ipv6: 7.4%
stubby-ipv6: 6.6%
unbound-ipv4: 5.6%
stubby-ipv4: 3.5%
As you can see, the IPv6 solutions are always doing better than the IPv4 solution
DNScrypt-proxy seems to be doing better than the other solutions
Stubby doesn't seem to be a very fast solution.
Remember, the key to reading the results, is the fact that dnsmasq attempts to find the fastest resolver by sending a DNS request to all of the resolvers every 20 seconds OR 50 queries.
I was expecting the cache of unbound to have a greater impact on the result, it does have an impact, but not as high as I hoped.
My interpretation (open for discussion):
Despite the fact dnscrypt-proxy seems to be the fastest solution, there are other things to consider in choosing a solution:
- DNSSEC: as you can read in [this topic](https://discourse.pi-hole.net/t/dnssec-test-fails/9586), unbound has the best implementation.
- privacy: as explained by @DL6ER, [here](https://docs.pi-hole.net/guides/unbound/), using unbound eliminates the risk a single resolver knows everything about you (the DNS requests you performed). dnscrypt-proxy claims to have several non-logging resolvers, but can you be really sure.
- availability: all solutions, except unbound, are dependent on one or more resolvers, running the solution. Unbound doesn't rely on resolvers, but talks directly to the DNS server(s), holding the actual DNS records. You will nearly always get a result using this solution.
After considering the pro's and con's, even despite the speed test, the [unbound solution](https://docs.pi-hole.net/guides/unbound/) seems to provide the most privacy and reliability, therefore, it is my preferred solution
---
### Author:  [@Thanos\_L](https://discourse.pi-hole.net/u/Thanos_L)
#### Post date: [May 23, 2018, 8:37am UTC](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378/47 "2018-05-23T08:37:39Z")
privacy: as explained by @DL6ER, here 1, using unbound eliminates the risk a single resolver knows everything about you
Do they logging?
---
### Author:  [@mibere](https://discourse.pi-hole.net/u/mibere)
#### Post date: [May 23, 2018, 8:49am UTC](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378/48 "2018-05-23T08:49:22Z")
Google does.
> What does Quad9 log/store about the DNS queries?
>
> We store details of the DNS records queried, timestamp, and the city, state, and country from where the query came. We do not store source IP information of end-user queries.
> Cloudflare will collect only the following anonymized DNS query data that is sent to the Cloudflare Resolver:
>
> ```
> Timestamp
> IP Version (IPv4 vs IPv6)
> Cloudflare Resolver IP address + Destination Port
> Protocol (TCP, UDP, TLS or HTTPS)
> Query Name
> Query Type
> Query Class
> Query Rd bit set
> Query Do bit set
> Query Size
> Query EDNS enabled
> EDNS Version
> EDNS Requested Max Buffer Size
> EDNS Nsid
> Response Type (normal, timeout, blocked)
> Response Code
> Response Size
> Records in Response
> Response Time in Milliseconds
> Response served from Cache
> DNSSEC Validation State (secure, insecure, bogus, indeterminate)
> PoP ID
> Server ID
> Autonomous System Number
>
> ```
>
> Except for the three DNS query types discussed below, all of the log information above will be deleted within 24 hours of Cloudflare’s receipt of such information.
---
### Author:  [@Thanos\_L](https://discourse.pi-hole.net/u/Thanos_L)
#### Post date: [May 23, 2018, 8:52am UTC](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378/49 "2018-05-23T08:52:33Z")
I mean the root servers when your resolver is the unbound.
---
### Author:  [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)
#### Post date: [May 24, 2018, 9:28am UTC](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378/50 "2018-05-24T09:28:06Z")
> [@Thanos\_L](#):
>
> Do they logging?
Albeit being maybe possible, it would be totally insane. They process billions of queries every day and I doubt that it would be feasible to log things. Also, there currently are 12 organisations providing root name service at 13 unique IPv4 addresses. They are:
A - VeriSign Global Registry Services
B - University of Southern California - Information Sciences Institute
C - Cogent Communications
D - University of Maryland
E - NASA Ames Research Center
F - Internet Systems Consortium, Inc.
G - U.S. DOD Network Information Center
H - U.S. Army Research Lab
I - Autonomica/NORDUnet
J - VeriSign Global Registry Services
K - RIPE NCC
L - ICANN
M - WIDE Project
Information about most operators can be found via www.root-servers.org, or specifically via [http://X.root-servers.org](http://X.root-servers.org) where X stands for one of the letters listed above.
Behind each of the root server IPs there are hundreds of individual servers reachable via `ANYCAST`.
So your question will go (more or less randomly) to one of the thousand root servers. I haven't tried to find a definite answer to your question, but I think it would be totally not feasible for them (and, in contrast to Google, etc. the operators are also not data harvesters earning their money from someone else's data).
All root name server operator are organisations that acknowledge the obligation to provide this service.
---
### Author:  [@Thanos\_L](https://discourse.pi-hole.net/u/Thanos_L)
#### Post date: [May 24, 2018, 9:35am UTC](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378/51 "2018-05-24T09:35:24Z")
Τhank you so much for the enlightening answer.
this is my results after 7 days.
127.0.0.2 unbound 12.3%
127.0.0.3 stuby 15.4%
127.0.0.4 dnscrypt 26.5%
blocklist 26.4
cache 19.5
\*stuby and dnscrypt using ONLY cloudflare
---
### Author:  [@jpgpi250](https://discourse.pi-hole.net/u/jpgpi250)
#### Post date: [May 24, 2018, 9:39am UTC](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378/52 "2018-05-24T09:39:10Z")
> [@Thanos\_L](#):
>
> I mean the root servers when your resolver is the unbound.
They must be doing some sort of logging, in order to be able to generate [statistics](http://a.root-servers.org/metrics/index.html).
---
### Author:  [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)
#### Post date: [May 24, 2018, 9:43am UTC](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378/53 "2018-05-24T09:43:49Z")
> [@jpgpi250](#):
>
> They must be doing some sort of logging
It could be debated if adding one to a counter on each query can already be called logging 😉
Without wanting to defend anything they're doing, they will have to use IDs for being able to reply correctly to the incoming query and at the end of the day they may simply do `queries_today = index_yesterday - index_now` and sum this up on all of their servers.
---
### Author:  [@p1r473](https://discourse.pi-hole.net/u/p1r473)
#### Post date: [April 21, 2020, 2:11pm UTC](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378/54 "2020-04-21T14:11:48Z")
> A: I’ve added two files to the dnsmasq config, to resolve internal IP addresses.
Are you able to show these files so I can replicate this?
[Previous page](https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378.md?page=2)