Unbound, stubby or dnscrypt-proxy

It's still available. You have to enter the port in the custom fields now.

24

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 :wink:

I'll have to wait until my test ends. As you now, I'm currently running dnsmasq with 6 resolvers (3x IPv4 and 3x IPv6), stubby, unbound and dnscrypt-proxy, this to determine dnsmasq's favorite (fastest resolver). The test has started on Tuesday (15/05/18) and I will not touch my pi until next Tuesday, this to get an impartial result.

As you also know, I've indicated the unbound solution is doing very well, and is rapidly becoming my favorite, especially since it handles the DNSSEC algorithms better than dnsmasq.

This is why I've asked @gecko, who seems to be running stubby+DNSSEC to publish his findings. More results, will lead to a better evaluation.

But you're right, I can, and probably will...

@jpgpi250

I got stubby working by also following that guide, with a few tweaks. On the stubby github the devs have been fixing some DNSSEC trust-anchor issues that stubby was having when run as a systemd service (out of the box it didn't have the necessary permissions to download the trust anchor files into the correct directory).

Annoyingly, the stubby config uses yml, which is a pain to use, as even an erroneous space in the wrong place can cause the config file to not work at all. However, with the latest stubby release, the new example config has much of the work done for you regarding DNSSEC, so you just have to un-comment the dnssec_return_status: and appdata_dir: lines, and also, if you're on raspbian, delete the DynamicUser=yes line from the example systemd stubby.service file, as DynamicUser needs systemd package 235 and raspbian stretch is only on systemd 232.

Also, interesting to note, with the latest getdns and stubby releases, a lot of work was put in to fixing DNSSEC bugs. So it seems it isn't just dnsmasq that has had DNSSEC issues.

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 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.

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 :wink:
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?