The operator of the resolver cache is supposed to be the user, not some third party (e.g., OpenDNS/Cisco, etc.).
IOW, the cache is meant to be running on the user's computer not some third party computer (e.g., OpenDNS/Cisco, etc.).
Using remote (i.e. third party) recursive resolver caches has never been recommended. If anyone is recommending that then they are ignoring the advice of the original author.
(There are other reasons to use a local cache, even if not to encrypt outgoing queries, e.g., it reduces/eliminates the risk of cache poisoning.)
If you look, you may find there are implementations that did follow the author's advice, e.g., a resolver that only accepts queries from 127.x.x.x.
What is missing to have a complete encrypted DNS solution? Authoritative nameservers that implement the system.
The recursive part of the system already works. It is controlled locally by users.
Authoritative nameservers for www sites however are run by third parties. Cooperation is needed.
As for TLS, there may be an alternative encryption solution forthcoming. Similar to encrypted DNS, it will be a small program running on the user's computer that encrypts outgoing packets. An ssl wrapper sort of like stunnel but better. It will not rely on establishing an "encrypted tunnel" like TLS. It will encrypt each packet separately.
I run a private root and a private nameserver that serves encrypted DNS packets from a datacenter. "Pseudo authoritative": the zone contains the third party addresses I need. All DNS queries are encrypted. Sent from localhost resolver to private nameserver. Nothing in the clear. That is how it works.
There will always be metadata gathering on the internet (access logs). But there does not have to be unencrypted (DNS) packets or third party DNS resolvers.
But it can be obfuscated enough to be, in practice, virtually useless. A single VPN service provides no anonymity. Tor provides some anonymity, using onion routing. There are three relays in normal circuits. Each of them knows where data comes from, and where it's going to. But with at least three, the entry and exit relays don't know each other.
But there are vulnerabilities. The relay early bug allowed CMU researchers to communicate between their malicious entry and exit relays, and so de-anonymize users and onion services. That bug is fixed, but of course there may be others.
However, onion routing can also be applied to VPN services. I'm typing this through a nested chain of VPNs. And one can readily use Tor via nested VPN chains. So adversaries would need to compromise multiple servers in different jurisdictions, walking through Tor and VPNs, in order to identify me. Or they could exploit intercepts from network edges with traffic analysis. But it wouldn't be easy.
With 10 Mbps, you should be able to get 3-5 Mbps through nested VPNs. I use UDP for all of them, so there's no retransmission chaos. As you add VPNs to the chain, bandwidth doesn't necessarily go down. But rtt increases, of course.
Yes, but I suppose you could decrease the signal-to-noise ratio by doing random DNS searches.
And once you set up the router, the cost of configuration is zero.
DNSSEC does NOT encrypt requests nor responses.
Suppose you encrypt all your SMTP/SUBMIT traffic. If your upstream is a commercial provider, then they will be subject to subpoenas. If you run your own upstream, then watching who it connects to will often be sufficient to gather metadata of interest.
Consider TLS. Before you can use it you must have used DNS. Today all DNS resolution goes in the clear. So game over right there. Eventually your client's DNS communication with a shared recursive resolver will not be in the clear, but the operator of that resolver will be subject to subpoenas, so game still over. Let's say we did deploy DJB's encrypted DNS solution. Well, you can still see which domains people are talking to, roughly, at least as long as they don't share nameservers, and if they do... You can see where this is going. Now let's say you did get DNS resolution securely anyways, well, now you have to connect to some IP address, and if it's not hosting many services, then game over, and if it is hosting many services, then SNI will be game over anyways (TLS 1.3 requires SNI). SNI cannot be encrypted.
The problem really is that metadata can't really be encrypted.
Mind you, criminals are defeated by data encryption -- mostly anyways.
And forcing governments to use subpoenas does mean increasing the cost of metadata gathering. Plus there won't be infinite retention requirements, perhaps. So, encryption does help somewhat, which means we must do it -- it's just not a complete solution.