i use: Dnsmasq Version 2.76 from setup with pihole
That is the problem. I can, if you want to, give you the instructions, to get a working (dnsmasq2.80test2) version of dnsmasq. Let me know.
I've been warned by the forum operators NOT to publish this in a public topic, since I cannot support it, I got the instructions, as is, from the dnsmasq developer. I can execute them, but can't troubleshoot (not smart enough for this), so no support from me if you want the instructions
1 Like
thanks for the info and the offer!!!
But i switch pihole back without DNScrypt or anything else
The solution pihole + unbound is easy to implement, you already have it working'. @DL6ER has documented it well in his wiki.
If you use unbound with pihole, you should disable DNSSEC in pihole (settings) and have DNSSEC records evaluated by unbound.
Why is this currently the preferred solution? see here.
1 Like
Hey, at the moment only stubby works with my pihole settings
unbound have the same errors with sudo apt-get update
First disable DNSSEC in pihole (settings) and check again.
1 Like
Yes i will pihhole works with unbound
but how i can set: 127.10.10.3#5553 or: 127.10.10.3:5553 in the pihole settings? Only numbers are allowed in the settings 
Strangely, I definitely saw this as an option in the pi-hole web UI last week, albeit, only 127.0.0.1, with the option to add the custom port. But now it's disappeared
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.
1 Like
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)
Thanks this settings all works fine!
Thanky so much for your support!!
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.
It's still available. You have to enter the port in the custom fields now.
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.
But you're right, I can, and probably will...
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.