If you are that worried then you could make your own and advertise it, as security is enhanced in numbers. If you are that concerned pick a resolver operating out of a country that has strict laws and does not operate with in the various “eyes” countries. Same concerns go for any dns resolver no matter if it is operates via dns over tls or dnscrypt.
It is important to do your research prior to if you really care about your security, or use your own; and if you implement it loglessly there is no privacy issue; the problem with only one or two persons using a dnscrypt server, is those results can potentially monitored by an adversary monitoring request from an upstream server; security is in numbers, unless there are secure methods of downloading the entire authoritative global list of DNS domain names in total at regular intervals over a secure connection. Otherwise if tens of thousands of people are using a dnscrypt server, and an attack was successful between the recursive resolver and the dnscrypt server, only random attacks would be possible against the clients, not targeted attacks. Meaning one in 10,000 people would be randomly affected or something as such, just as one example. Dnscrypt prevents any identifying information that could reveal the identity of the client from reaching upstream resolvers.
As for dnscrypt security vs the competition, look here:
https://dnscrypt.info/faq
it outdoes the competition by a long shot, its faster as it functions over the udp protocol & does not have to parse and modify dns parameters
jedisct1, the programmer behind dnscrypt explains the performance & security benefits of dnscrypt over tls/https here:
https://news.ycombinator.com/item?id=17200932
Here is a few important snippets from dnscrypt programmer to consider from the second link just for convenience sake “TLS session tickets allow DNS operators to track devices no matter what their IP are. TCP sessions allow DNS operators to fingerprint devices sharing the same external IP. From a privacy perspective, this is effectively a regression over plain DNS. So for people who care about this, you need to add the ability to disable these. Performance will be terrible, but that’s what you get for using a transport protocol that was never designed for DNS. This can be partially mitigated with DoH using forthcoming HTTP/2 extensions. But for raw TLS that doesn’t allow much except send() and receive() packets, there’s no hope without reinventing HTTP.”