Simon Kelley, the developer of dnsmasq, has been looking at (duplicated) my configuration, e.g. dnsmasq2.80test2 + DNSSEC + dnscrypt-proxy v2.0.11
A test, he made me perform:
in dnscrypt-proxy, use only the following servers (don't use any 'd0wn' servers):
server_names = ['dnscrypt.eu-dk', 'dnscrypt.eu-nl']
and indeed, the number of false BOGUS records has significantly decreased, so far, I ran into one problem only:
May 4 19:15:07 dnsmasq[544]: 1983 192.168.2.228/62185 validation ocsp2.globalsign.com is BOGUS
This may actually be a BOGUS record, since it doesn’t validate here.
Please, report back, if you're willing to test this...
The developers explanation:
'quote'
The fundamental problem is: missing RRSIG data in the AUTHORITY section validating NSEC records which prove that a DS record does not exist. The insight is that these are only missing when the answer comes via UDP: they are present when the answer comes via TCP.
Getting the answer via UDP or TCP depends on the state of the dnsmasq cache. This is because the answer to query for the root key is too long to fit in a UDP packet via dnscrypt. If dnsmasq queries the root key during its attempt to validate the query above, then the answer will be truncated, and dnsmasq will restart the whole process, using TCP. Since when using TCP, the RRSIG are not omitted, everything works.
If, on the other hand, dnsmasq has the root key cached (or more generally, doesn't trip over anything that requires a move to TCP) then the missing RRSIGs in the answer via UDP now matter, and the validation fails.
'/quote'
Even with a different configuration (FTLDNS), since some DNSSEC capable DNS servers seem to have a problem, and others don't, it might be wise / helpful, to test your system with other DNS servers.
To be continued...