In the current version of pihole, you can't. This is a new feature in FTLDNS.
With the current version of pihole, just select a random server and save the settings.
Now edit /etc/dnsmasq.d/01-pihole.conf, remove (or comment out) all lines that begin with server=, and add one line server=127.10.10.3#5553
Make sure you don't have any other files in /etc/dnsmasq.d that contain a server= setting
restart dnsmasq (sudo service dnsmasq restart)
You might clean up /etc/pihole/setupVars.conf, This file contains one or multiple lines, beginning with PIHOLE_DNS_, just comment them out (#) or delete them. I believe these lines are only used to populate the settings page (not sure), but they don't affect dnsmasq, once the sytem is running.
Yes, I noticed it was added after I switched to the FTLDNS branch of pihole. However, do you know why/if it has since been removed? Do you still have it in your web UI?
My pihole version reports as follows:
Pi-hole Version vDev (FTLDNS, v3.3.1-136-ga7e7680) Web Interface Version vDev (FTLDNS, v3.3-130-g4355bde2) FTL Version vDev (FTLDNS, vDev-5ecab0a)
@gecko
I'm NOT using FTLDNS yet. I've tested it once, that's when I noticed, but have since than returned to the current version of pihole. I can't use FTLDNS, since it is based on dnsmasq2.79, witch has a DNSSEC bug. This will be resolved in dnsmasq2.80, so I'm currently running a test (beta) version of it (dnsmasq2.80test2)
Yes we spoke about the DNSSEC bug in another thread. You actually asked me to do some testing, but unfortunately I've been quite busy with school so haven't had a chance. In the end I just used stubby to do the DNSSEC and disabled DNSSEC on the pihole.
Being able to choose a local resolver from the pihole web interface was a nice addition I thought, so I can't really understand why it would been removed (although, it was a bit annoying that you could only choose the port for localhost, and not specify a different localhost address such as 127.0.2.2 or something similar).
If you really are using DNSSEC with stubby, you might want to read this topic, and preferably also reply in that topic, this to keep the results together.
I'm interested in what you need to add to have stubby evaluate DNSSEC, I'm new to stubby, so I'm still learning, I followed this wiki to implement it, but haven't changed the listed configuration yet.
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
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.
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.
@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.
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.
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.
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
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.
