I’ve been reading about the choices on this and other forums, but found no convincing answer to this question, so I decided to test them all myself (ongoing). After a while, I figured out how to run them all together, thus getting DNS privacy by obscurity.

Here is my setup:
I’m still only using ipv4, my provider refuses to exchange the docsis cable modem to a v3 modem.
I’m still running the production version of pihole, so no FTLDNS yet, because dnsmasq2.80test2 has a fix for DNSSEC. FTLDNS, based on dnsmasq2.79, doesn’t have that fix.
DNSSEC is handled by dnsmasq, this to be able to identify (false) BOGUS dns entries, using the pihole admin page and the dnsmasq log. Also, it is recommended to keep DNSSEC evaluation as close to the client as possible, dnsmasq is the entry point for clients.

I’m still in the process of optimizing the configs, but here is what I got so far:

the dnsmasq config (/etc/dnsmasq.d/04-servers.conf) . As you know, you can add multiple configuration files to this folder, so I removed all server settings from /etc/dnsmasq.d/01-pihole.conf and created a separate file for servers:

in the source, (/dnsmasq-2.80test2/src/config.h) before compiling dnsmasq. You cannot change these settings, once compiled.
This implies, dnsmasq will test all specified resolvers every 50 queries OR every 20 seconds. Notice the entries in the log:

That’s the speed test. The domain name will be different, It’s just the domain name you are trying to resolve when the (timer) conditions are met.

Another thing you can change, before compiling dnsmasq, is the maximum cache size, by changing:

if (size < 0)
size = 0;
else if (size > 10000)
size = 10000;

in the source (/dnsmasq-2.80test2/src/option.c). Change the value to, for example 65535 (twice). Once everything is up and running, including pihole, you can than increase the cache size by changing the value in /etc/dnsmasq.d/01-pihole.conf and restart dnsmasq. Remember, 01-pihole.conf reverts to default (10000) whenever you run ‘pihole -r’ or pihole -up’. The result (in the dnsmasq log):

dnsmasq[29727]: started, version 2.80test2 cachesize 65535

I try to keep all my configuration files intact, including comments. for the sake of keeping things small, I ran

sed '/^[[:blank:]]*#/d;s/#.*//' <filename>

before pasting them in this topic. This implies, the configurations also lists the default (original) settings.

The unbound setup and config:
I followed this wiki to setup unbound, and modified the configuration (/etc/unbound/unbound.conf.d/pi-hole.conf) as follows:

Here, I’ve done some research. I want, as you can see in the configuration, servers with the following options: ‘no filter’, ‘no logging’ and ‘DNSSEC’.
A lot of the servers, listed here, seem to match the criteria, however, a lot of these servers also have a problem with DNSSEC. I found 2 ipv4 servers that don’t seem to have this problem: ‘scaleway-fr’ and ‘de.dnsmaschine.net’

Q: Why so many local requests?
A: I’ve added two files to the dnsmasq config, to resolve internal IP addresses.
/etc/localdns.list, don’t forget to change the domain name (localdomain), format (example):

Q: How many dns queries where performed during the test?
A: I use this software to preform load tests, I run them simultaneously on multiple machines. Pihole stats:
Total queries (6 clients): 4169
Queries blocked: 555
Domains on block list: 601791

I’m NOT a Linux savy, I’m just really good at implementing wiki’s and find solutions in duckduckgo. Therefore, I’m willing to answer any question, however, no promises made…

I can confirm the dnscrypt-proxy server ‘dnscrypt.me’, info here , is now behaving as expected.

I’ve asked Simon Kelley, the dnsmasq developer, to comment on the changed unbound settings. His comment:
‘quote’
Increasing the edns buffer size should avoid fallback to TCP, which is good.
‘use-caps-for-id’ may interact badly with some authoritative servers, it’s probably not going to affect dnsmasq.
‘/quote’

Since I’m also using unbound as a recursive dns sever, see wiki, and the implementation description above, I’ve also changed these settings in my unbound config.

I’ve updated/added the settings in the first entry of this topic, this to avoid errors for those who copy/paste them entirely.

I have no objections against just removing use-caps-for-id as it defaults to No. It’s just that the majority of unbound tutorial out there seem to suggest it hence I added it as it didn’t show a negative effect in my use case.

EDIT I already removed it, do you think any further changes are required? @jpgpi250

I would suggest to change the ‘use-caps-for-id: no’, since it may cause problems, ref @mibere’s footnotes.

I also would suggest to add ‘edns-buffer-size: 1472’. Explanation:
When using the command ‘dig @127.10.10.1 -p 5551 +dnssec www.raspberrypi.org’, e.g. talk to dnscrypt-proxy (or any other resolver solution - unbound - stubby) you often see the message ‘;; Truncated, retrying in TCP mode.’

It looks like adding ‘edns-buffer-size: 1472’ to the unbound configuration eliminates this. This appears to be the conclusion of Simon Kelley
‘quote’Increasing the edns buffer size should avoid fallback to TCP, which is good.
‘/quote’

Well, I consider it more as “our” wiki, so I’m happy to optimize it as much as possible with the help of the community.

mibere:

You should use use-caps-for-id: no in your own tutorials and configuration.

I already removed this before the two of you replied, I guess you just have missed by edit message. Do you think it is a good idea to include it with the option explicitly set to “no”?

jpgpi250:

I also would suggest to add ‘edns-buffer-size: 1472’.

Okay, I see your point, but why 1472? So far I don’t see an explanation for this seemingly random number. Having said that, I’m happy to include it as well, and I know that a number like 2048 may be arbitrary as well, but at least we’re more used to power-of-two numbers.

edns-buffer-size: <number>
Number of bytes size to advertise as the EDNS reassembly buffer
size. This is the value put into datagrams over UDP towards
peers. The actual buffer size is determined by msg-buffer-size
(both for TCP and UDP). Do not set higher than that value.
Default is 4096 which is RFC recommended. If you have fragmen-
tation reassembly problems, usually seen as timeouts, then a
value of 1472 can fix it. Setting to 512 bypasses even the most
stringent path MTU problems, but is seen as extreme, since the
amount of TCP fallback generated is excessive (probably also for
this resolver, consider tuning the outgoing tcp number).

replace the IP with the ip you used, and the port with the port you used. This should give a result. If you configured multiple resolvers, run the test again for instance I have (example IP’s and ports - you need to change them to match your config!!!):

change the dnsmasq configuration (file in /etc/dnsmasq.d), so that you’re only using one (1) resolver. so start with only 127.10.10.1#5551, comment out (#) the rest, and restart dnsmasq (sudo service dnsmasq restart). once dnsmasq has restarted, you should verify that (sudo systemctl status dnsmasq) try to ‘sudo apt-get update’. If the resolver is working, that should get you a proper result. If the result is bad, there is something wrong with the resolver.

If you’re first resolver is already ‘bad’, test the second one first, before starting to search for the error with the first one, there may be something else that’s failing (not a resolver), as indicated by your dig results…

I hope you’re sure there aren’t any other ‘server=’ settings active in any configuration file.
You can verify this by looking at the /var/log/pihole.log content. the number of resolvers is mentioned at the bottom, that is at the bottom immediately after dnsmasq restart.

I don’t really know very much about stubby, still learning myself, I can only say you should verify the configuration files.

For dnscrypt-proxy, there is something else you can do. In my example I use only two (2) dnscrypt servers (‘scaleway-fr’ and ‘de.dnsmaschine.net’) I’ve learned there are many dnscrypt resolvers out there that don’t handle DNSSEC very well.
The test I perform:
First ensure dnsmasq only uses the dnscrypt resolver (the dnscrypt-proxy example above is server=127.10.10.1#5551, make sure you enable the correct resolver!). Now ensure dnscrypt-proxy is only using one (1) server (edit this in /opt/dnscrypt-proxy/dnscrypt-proxy.toml) so for example server_names = [‘scaleway-fr’]