Best DNS for privacy?

Yes, but what does it use?

Authoritative name servers.

Good enough write-up about it here: https://docs.pi-hole.net/guides/dns/unbound/
- The only problem there is that if you are going for privacy all of the traffic between your unbound and the authoritative servers is unencrypted. It us certainly a trade-off involving trusting a 3rd party, but with a busier public DNS server there can be a level of plausible deniability due to the aggregation and shared caching involved.
  
  Kinda. You can always route your traffic over a VPN. Further, from the unbound page:
  
  To help increase online privacy, Unbound supports DNS-over-TLS and DNS-over-HTTPS which allows clients to encrypt their communication. In addition, it supports various modern standards that limit the amount of data exchanged with authoritative servers. These standards do not only improve privacy but also help making the DNS more robust. The most important are Query Name Minimisation, the Aggressive Use of DNSSEC-Validated Cache and support for authority zones, which can be used to load a copy of the root zone.
  
  Edit: to be clear, I run unbound but I don't recall how much I hardened it. The config file is fairly large and I was mostly focusing on speed and efficiency since it's running on an already busy raspberry pi.
  
  Sure, which at least increases the burden from observing just your traffic to your ISP to observing your ISP and your VPN provider. That traffic is still unencrypted upon egress from your VPN. If you're going through the effort of using a VPN I think using a public DNS server could make more sense as they can't tie your query to your actual IP. (Also this is all thinking about an upstream for PiHole or similar, so always some sort of local server for your clients to use)
  
  The question was about privacy. Routing your DNS traffic through a VPN puts your unencrypted traffic out of an endpoint with all sorts of other connections. That's a privacy gain.
  
  Further, using DNS-over-TLS or DNS-over-Https encrypts your query end-to-end.
  
  Using both in concert prevents the DNS servers from knowing your IP and anyone along the route from knowing your query.
  
  Sure, but we were talking about using Unbound, or some other recursive resolver, locally. Unbound doesn't use DoH or DoT for its queries, and most/all authoritative servers don't offer DoT/DoH.
  
  You would have to use some local stub resolver, route its traffic over a VPN, and then use public resolver(s) that provide DoH/DoT (and those still use plaintext DNS to do their resolution, the benefit you get there is the shared cache and semi-anonymization due to aggregation). Whether that is good enough is up to you.
  
  You run a local resolver for your household and enable DNS encryption where supported. Using a VPN for everything removes your ISP from the loop. It's a matter of privacy layers and your threat model. If you want to play with TLAs you'll need to try way harder.
  
  If my threat model realistically involved TLAs or other state-sponsored actors I would not be advertising what I do or do not know on a public forum such as Lemmy, haha.
  
  This conversation was in the conext of running Unbound, which is a recursive resolver and AFAIK DNS "encryption" isn't a thing in a way that helps in this scenario... DoH, DoT, and DNSCrypt are all only concerned/deployed by recursive servers, meaning unbound isn't using those. DNSSEC only provides authentication (preventing tampering) of the response, not any sort of encryption/hiding.
  
  I'm also running unbound on my opnsense, configured to use root DNS servers. Don't recall what exactly is enabled.
  
  Yours is a good point why I should run all my traffic through a Wireguard tunnel to my dedicated server, so that my ISP is out of the loop.
- Thanks! Good write-up indeed.

Use your own. That may not always be the best way to go, as it'll make fingerprinting also much easier. The more custom your setup is, the less there are like you, the easier your tracked by fingerprinting techniques.

Not saying it's bad per se, but the idea that trusting no one and setting everything up yourself is always more private isn't true either. Both providers and do-it-yourself have negative sides one should stay critical about.

How using selfhosted DNS makes you easier to be tracked?
- As I said:
  
  as it'll make fingerprinting also much easier.
  
  Fingerprinting is a technique where they look at everything they can grab from received requests and try to use that info to identify people. The things you block (like ads and trackers), the used DNS, your user agent, your IP, etc. It's all used to try to identify you. The more you blend in with others, the harder to identify you are. The more custom stuff you have, the easier to identify you are.
  
  If fingerprinting or not having to trust third parties is more important depends on your threat model. But it's important to know the risks of a trust-no-one do-it-yourself approach when making the decision.
  
  Well, my question was specifically about DNS. I don't think that the sites or services you use have any way to know what DNS are you using.
  
  ISP can capture DNS traffic, but this is where threat model comes into play... Like if you are concerned about some entity to collect you profile based on data from ISP which includes both your DNS queries and your IP
  
  Well, you're right. I was mixing a few things up in my head. My bad. Altrough I did find a few interesting ways that can be used by websites to find client side DNS, it isn't exactly the norm or likely to hit you with custom setups.
  
  I retract my point on DNS, but the general notion that do-it-yourself isn't always better stays. Al be it off-topic here now.
  
  Interesting, can you share any links regarding finding client DNS?
  
  There are quite some results if you search online, but here's one with some specific info: https://security.stackexchange.com/questions/129917/how-does-a-website-know-the-dns-server-a-client-uses

Seconded. Docker with blocky + x2 unbound user here. The speed/snappyness difference is absurd.