This is not the privacy concern, check out the https://tools.ietf.org/html/rfc7871#section-11.1 discussing it. Yes, if you open a connection to the target IP, then all transit networks between client and the target IP (including the target itself) know who is talking. These are on-path parties. The main (privacy) issue with ECS is not this, but that it shares client's subnet with potentially every nameserver on the referral path (including transit networks between the recursive and nameserver), for every name client looks up (even when it might not support ECS). The client is also not in control of the prefix length. /24 for IPv4 is a recommended default, but the recursive may use however much it wants and there's no way to prove to the client that it didn't. Opt-out is also difficult (afaik only getdns and Firefox clients support an opt-out).
Disclaimer: I work on 1.1.1.1. You might not consider your /24 as personally identifying, but others might. The original RFC discusses these problems fairly well (https://tools.ietf.org/html/rfc7871, Privacy notice and privacy considerations). Frank Denis also wrote a good summary on ECS (https://00f.net/2013/08/07/edns-client-subnet/). There's a multitude of ways to fix this - use a whitelist of nameservers to send ECS to to avoid spraying the source prefix everywhere, encrypt the whitelisted connections, or aggregate the source prefix into a largest covering server scope (e.g. if the client is in /24 but nameserver serves the same answer for /16, then using any address in the /16 would do). We're evaluating all of them as there's different trade-offs (see https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-...).
This is interesting as a lighter alternative to DNS over Tor. Where is the padding going to be? Basic clients won't add EDNS padding by default, but intuitively there has to be padding somewhere. It reminds me of https://odns.cs.princeton.edu (I haven't seen a working implementation of that one yet). The most difficult challenge is how to present the ultimate choice - use the relay and maybe get slower Internet, or don't use the relay and maybe get tracked. What hasn't been much explored yet is using resolvers just to obtain the delegation (nobody needs to know who the client is for that), but that itself is not without problems.
From operational perspective, it may be easier to maintain a certificate (after all, that's what you already do for an HTTPS service) than a DNSSEC signed zone. It is also easier if you have a multiple DNS providers, since you don't have to coordinate zone resigning. On the other hand, DoT doesn't provide the same properties (like client-side revalidation) as record level DNSSEC. It is undoubtedly an imperfect solution, but better than a perfect solution that isn't deployed. I see the two technologies as complementary, a fairly good DNSSEC deployment at the TLD level can provide a safe way for key discovery at SLD level. There are many facets to this, and it is still fairly early in resolver-to-authoritative DoT standardization process, this is just one of the first steps to show that it's feasible in real world.
I wrote a not very well known LuaJIT to BPF compiler as a part of bcc precisely because of this. It doesn't depend on anything besides LuaJIT (no LLVM, no C, no libbpf, etc). Caveats: it's Lua, it doesn't fast track all the latest from bcc as it's a "for fun" project.
DNSSEC is orthogonal to this. Its goal is to prove integrity of records between authoritatives and the closest validator. The validator is most often the resolver doing the recursion, not the client. The client can either revalidate all the answers and/or establish a secure channel between the itself and the resolver (with the added privacy bonus). The reason why many clients don't revalidate is because it's time consuming (basically same complexity as recursor), and fragile (recursive operators can work around DNSSEC screwups by adding negative trust anchors), so it's a tradeoff between convenience and risk.
There's an ongoing work to make revalidation easier - the client would basically ask the recursive to not only provide answer, but also a whole trust chain from a known trust anchor (so it would revalidate the answer without additional queries) https://tools.ietf.org/html/rfc7901
It's worth mentioning that encrypted DNS is not just about privacy, but also integrity. It's more difficult to intercept or spoof in hostile networks.
ISP can still see the target IP address and SNI. The IP address is sometimes meaningful (single website), but not if it's a CDN or a multi-tenant server. The SNI is being worked on (encrypted SNI, ORIGIN frame, CERTIFICATE frame). The point is none of that matters without encrypted DNS.
This is a great comment. The ping time is so much less meaningful for recursive service than for authoritative. The latency difference between cached answer and uncached answer is in several orders of magnitude. The cache hit ratio also plummets without some sort of cache sharing, which many recursive services don't implement. So you may end up with great ping time, but something like:
I ran a full recursor on my laptop for about two years. It's not a great choice, especially if you're not stationary. A lot as a lot of environments intercept DNS and poison your cache, the answers for lb'd names also change depending on your geolocation (so you have to flush it every time you move). Your queries are also not really private as you the resolver has to talk to multiple authoritatives to get you your name in a plain text. The performance is also not as great even with prefetching, as you don't benefit from a shared cache.
Probably the best thing you can do is to run something like https://github.com/jedisct1/dnscrypt-proxy which at least retains privacy between you and the resolver, and use public resolvers you trust.
If you don't trust any of them, you could start a resolver on a VM somewhere, but then again that can be traced back to you, so it depends on your threat model.
Both of these options are better than running a full resolver on localhost (unless you expect the recursive DNS infrastructure to fail, while authoritative remains operational).
QNAME minimization just minimizes the name to one label under a delegation, there's no randomization. So root zone would only get 'com.' (and type NS). It's unfortunately easy for authoritative servers (below TLD level) to bypass it by returning NXDOMAIN. Resolver has to fall back on using a full name. The main reason is that a lot of authoritative DNS servers (notably Akamai) return NXDOMAIN when there's nothing under the minimized name, but there is something below it (aka empty non-terminal). So without workarounds the resolver would return NXDOMAIN early instead of retrying with the full name.
Yes, there's a cap on both negative and positive cache lifetime. The reason is reducing the blast radius as accidents happen, and it hurts especially on long infrastructure records (mistake during repointing NSs, bad glue, expired DS etc.)
We're going to be looking into making the cap more dynamic over time.