I've added the results from that page using pihole with stubby+DNSSEC here
@gecko Thanks for this.
@DL6ER If you would be so kind to publish the unbound results in the same topic, this would be great, usefull, a contribution to an impartial evaluation.
Thanks.
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.
If I've understood @DL6ER correctly, future versions of pihole FTLDNS will report SERVFAIL in the pihole web interface.
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.
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, unbound has the best implementation.
- privacy: as explained by @DL6ER, here, 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 seems to provide the most privacy and reliability, therefore, it is my preferred solution
privacy: as explained by @DL6ER, here 1, using unbound eliminates the risk a single resolver knows everything about you
Do they logging?
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 NumberExcept 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.
I mean the root servers when your resolver is the unbound.
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 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.
1 Like
Ī¤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
They must be doing some sort of logging, in order to be able to generate statistics.
1 Like
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.
1 Like
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?